SCons D support

[Artur Skawina]

On 05/10/12 20:30, H. S. Teoh wrote:
> On Thu, May 10, 2012 at 06:27:20PM +0100, Russel Winder wrote:
>> On Thu, 2012-05-10 at 08:04 -0700, H. S. Teoh wrote:
>> [...]

>>> For D projects that also have C code:
>>>
>>> 	gdc -c src1.d src2.d
>>> 	gcc -c src3.c
>>> 	gdc -o prog src1.o src2.o src3.o
>>
>> This would indicate that gdc and gcc are effectively interchangeable
>> as the linker. But then given gdc is gdc this is sort of not
>> surprising.
> [...]
> 
> Using gcc instead of gdc on the last line will produce reams and reams
> of errors about undefined symbols, unless you explicitly specify
> -lgphobos2 somewhere on the commandline (and perhaps one or two other
> libraries). Using gdc appears to automatically insert the requisite
> arguments to the ld call so that everything Just Works.
> 
> We probably have to get our hands dirty, though, and figure out exactly
> what is being passed to the linker, and how it's decided, so that the
> SCons tool can do the right thing in all situations.

Linking pure D apps is probably best done with GDC, for the same reasons
as C++ apps are linked using g++. If you want to know the exact linker
command line used, just add a '-v' argument to the final gdc invocation.
If you need to eg find out the linker options, in order to merge them
when linking a multi-language project, use '-###' instead of '-v' and
parse the output.

One thing i would not rely on is the installed gdc and gcc/g++ being closely
related; ie the gdc version/release can be different and the tools can
be independently installed, meaning the '-x' option is probably best avoided.
Incremental linking could help (by linking all the C++ objects together with the
language-specific libs, then all D objects, then go/ada/fortran/java etc), but
won't probably magically solve all problems and any build frontend will still
need some knowledge about every language supported.

artur