[Gambas-user] Form embedding, building devel version

[Michael Isaac]

Benoit Minisini wrote:

>On Wednesday 12 January 2005 17:22, Rob Kendrick wrote:
>  
>
>>Rob Kendrick wrote:
>>    
>>
>>>Benoit Minisini wrote:
>>>      
>>>
>>>>Because Gambas IS an interpreter. But if you like, you can write a
>>>>compiler for Gambas of course :-)
>>>>        
>>>>
>>>You seem to have already done so: gbc.  And such a thing isn't actually
>>>necessary for such a scheme anyway.
>>>      
>>>
>>This thread appears to have died with insuffcient discussion for me to
>>understand the issues at hand.
>>
>>Why is the fact that Gambas is an interpreter stopping it from producing
>>ELF binaries?  My request is as follows:
>>
>>   1. Make the interpreter available as a library as well as an
>>      executable
>>   2. Provide a small "stub" object file built during Gambas's build,
>>      that uses the library version of the interpreter to execute
>>      the application that is stored in some static structure in the
>>      executable
>>   3. Allow building of application via dumping all the bits needed
>>      to run it out to a very simple ELF file that just contains the
>>      data as a static structure, and linking that to the stub and
>>      the interpreter library to generate an executable.
>>
>>This has the advantages that you have the option of statically linking
>>your application if you so wish, so you don't require any other
>>libraries or runtimes to run your application somewhere, as well as
>>independance from system to system about where the gambas interpreter is
>>stored.  It also provides version support between different incompatible
>>interpreters that may (or may not) appear over time via the soname
>>functionality.  And all this with only having to have ld installed, not
>>the whole gcc suite.  (Which is usually packaged seperately anyway.)
>>
>>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 :-)
>
>But I find statically linked executable a very bad idea:
>
>1) They are very hard to produce: gambas component requiring library A and B, 
>that require libraries A1, A2, A3, and so on until glibc and ld.so.
>
>2) They consume a lot of disk space.
>
>3) They are not updated if there is a security update or important bug fix of 
>one of the libraries.
>
>4) They don't work if a statically linked library like glibc depends on the 
>system architecture (/etc/resolv.conf for example) and this architecture 
>change.
>
>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.
>
>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, ...
>
>Last, incompatible interpreters will be renamed: gbx, gbx2, ..., gbxN. This 
>will avoid ambiguities.
>
>Regards,
>
>  
>
I like Robs idea.  I dont think that the target system should be 
required to install Gambas.  Which is basically how it is now.  The 
developer of an application should be responsible for releasing an 
updated or patched program.  This way the developer is the only person 
responsible for downloading, unpacking, configuring and installing new 
Gambas' sources.  which is something alot of "users" dont know how todo 
in the first place.  Thats why we have packaging systems like dpkg and 
rpm.  The Linux community is slowly moving away from do it yourself 
compilation.  I would love to be able to write my application, compile 
it to an executable, zip it and send it out for the world to use.  If I 
was a more adept programmer I would write my own compiler.  Since Im not 
I wish Benoit would.

l0wrd