Creation of a Build tool on top of the D compiler

kris foo at bar.com
Fri Jan 26 20:22:45 PST 2007


BCS wrote:
> Reply to kris,
> 
>> Frank Benoit (keinfarbton) wrote:
>>
>>> Now we have dependency information in the verbose output of DMD. But
>>> one thing is still missing:
>>>
>>> pragma( lib, "mylib.so" );
>>>
>>> Can we have that in the output also?
>>> "pragma<\t>lib<\t>mylib.so"
>>
>> Er, why not just have a compiler option to do a simplistic "build"
>> instead? It already loads and parses /all/ imported modules, but then
>> apparently discards everything not noted on the command line.
>>
>> Wouldn't it be a whole lot more efficient if the compiler simply
>> retained all those parsed modules for subsequent codegen and linking?
>>
>> Sure, a build tool is still really handy for generating libs, and so
>> on. But the basic compilation/linking task really ought to be handled
>> by the compiler itself. I mean, c'mon -- the compiler has an option to
>> /run/ the resultant executable ... should at least be able to /create/
>> it first?
>>
>> - Kris
>>
> 
> what If I have a 200+ module project that take ten minutes to compile 
> (lots of templates say) a build only what's needed strategy is still 
> needed. having bud walk the whole tree and still only build what is 
> needed is still useful. I don't think /that/ functionality should go 
> into the compiler.

Yes, I agree. The compiler should still handle the basic requirement 
though. After all, currently loads /and/ parses every single one of 
those 200+ modules regardless (if they're imported in any fashion)




More information about the Digitalmars-d mailing list