Re: Additional languages in GNUstep Make

[Nicola Pero]

On 10 Nov 2008, at 13:18, David Chisnall wrote:

> Hi,
>
> I'm just about to commit static compilation support to LanguageKit  
> and edlc, and I'd like to be able to support this cleanly from  
> GNUstep Make.
>
> To compile a Smalltalk file to LLVM bitcode, you need to run:
>
> edlc -c -f {smalltalk file name}
>
> This will give you a .bc file.  All of these should then be linked  
> together, along with the MsgSendSmallInt.bc file, with llvm-ld,  
> which will run link-time optimisations and then emit object code,  
> which should be linked with the program.  Optionally, llvm-ld should  
> be used twice, once to combine all of the bitcode files, then opt  
> should run some additional optimisations, and then llvm-ld should be  
> run again. I will play a bit with the optimiser and see if I can  
> find a sensible set of optimisations to run each time.
>
> My question is, what is the best way of adding support for this to  
> GNUstep Make?

If you send me an example compilation with a couple of files (ie, the  
whole list of commands you'd execute, and the files that get generated  
at each step)
I can easily write the rules for gnustep-make to compile/link your  
xxx_SMALLTALK_FILES into the executable.  I can then send them to you  
and
you experiment with them until you're happy, or we just add them to  
gnustep-make straight away but tell everyone they're experimental in  
case we later
want to change them a bit (which usually naturally happens). ;-)


>  I would like to be able to have a line in my GNUmakefiles like:
>
> PROJECT_SMALLTALK_FILES = foo.st bar.st
>
> Since there are some situations where JIT compilation is preferable,  
> it would also be nice if this could either copy the files to the  
> resources folder in the bundle, or statically compile and link them,  
> depending on the value of some other macro, although that's not  
> essential.

Interesting :-)

How would they files be loaded when JIT is used ?  What if the  
executable does not have an associated bundle (eg, a tool with no  
associated bundle) ?
Anyway, we can certainly work something out, but simpler is better.  ;-)

Thanks