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"

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

kris wrote:
> 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?

Seems like it would.

> 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?

Good point :-)  I guess the run option currently only works for single-module apps, huh?


Sean

Sean Kelly wrote:
> kris wrote:
>> 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?
> 
> Good point :-)  I guess the run option currently only works for single-module apps, huh?


I thought it'd also work if you pass all the file names at the command line, heh.

Hasan Aljudy wrote:
> 
> 
> Sean Kelly wrote:
> 
>> kris wrote:
>>
>>> 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?
>>
>>
>> Good point :-)  I guess the run option currently only works for single-module apps, huh?
> 
> 
> 
> I thought it'd also work if you pass all the file names at the command line, heh.

heh - it will, but that's impractical to do by hand [1]. Especially when you can't successfully utilize certain types of D code from a library -- such as templates.

[1] you can always create make files or whatever, but that requires setting up the makefile and keeping it up-to-date. Thus, Build/Bud is a better solution than makefiles for many people. Yet, there's no need for a build tool for the basic compilation cycle, particularly when the compiler has already parsed /all/ the relevant files.

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.

On Sat, 27 Jan 2007 00:24:09 +0100, 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"

Just a reminder that this sort of thing might be placed into a D compiler but it should not be a part of the D Programming Language specification.

-- 
Derek Parnell

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)

kris wrote:

> Especially when you
> can't successfully utilize certain types of D code from a library -- such as
> templates.

I strongly believe that compiler *should* be able to compile templates to a some intermediate form and put it into libraries. Otherwise you will be forced to create d 'header' files for your template-enabled libraries or even use them as source code only.

-- 
AKhropov

Andrey Khropov wrote:
> kris wrote:
> 
>> Especially when you
>> can't successfully utilize certain types of D code from a library -- such as
>> templates.
> 
> I strongly believe that compiler *should* be able to compile templates to a
> some intermediate form and put it into libraries. Otherwise you will be forced
> to create d 'header' files for your template-enabled libraries or even use them
> as source code only.

C++ tried this with "export" and it's been a bit of a fiasco.  Last I heard, EDG had it implemented (they were the only compiler team to have done so), and the benefit didn't seem all that great.


Sean