[Gambas-user] Form embedding, building devel version

[Rob Kendrick]

Benoit Minisini wrote:

>>I'm not suggesting that this sort of mechinism should *replace* the
>>current, but it might be a handy option to have.
> 
> Do it if you like :-)

Would you accept the patch?

> But I find statically linked executable a very bad idea:

I'm not saying that it should *only* produce static binaries, but that 
doing it that way would allow you to do so in the rare cases having a 
static binary would be advantagous.  What I'm saying is that generating 
a real executable that uses the interpreter as a shared library, rather 
than via the horror that is the #! system is a better solution, in every 
way I can think of.

<snip>

> Making an executable or a script makes no difference for the user. The Gambas 
> archives just require ONE symbolic link in /usr/bin. It is not a nightmare.

Rather than none at all.  Also, what if it's not a perticular OSes 
policy to have such things in /usr/bin ?  What if it's not a Unix at 
all?  (You have to do something else again completely different, where 
generating executables that use the interpreter as a library mean that 
it's essentially the same thing you have to do everywhere, making 
porting easier.)

> Embedding gambas in an executable is not so evident: the gambas interpreter 
> needs a total control of a process: it needs its own signal handlers, it 
> needs to control when dynamic libraries are loaded and freed, ...

I don't see why this is a problem for anything I have suggested, 
considering all the "stub"'s job would be would be to call a function in 
the library along with a pointer to the application's code and data. 
There's nothing stopping the library setting up signal handlers and 
loading .so files at other points.

> Last, incompatible interpreters will be renamed: gbx, gbx2, ..., gbxN. This 
> will avoid ambiguities.

Shared libraries already provide this functionality, except in a much 
more elegant way that doesn't mean you end up with dozens of symlinks in 
/usr/bin/.

-- 
Rob Kendrick
PGP signed or encrypted mail welcome (Key ID: 3651D17A)