View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2007
Creation of a Build tool on top of the D compiler
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"
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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.
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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.
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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.
January 27, 2007
Re: Creation of a Build tool on top of the D 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
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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)
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home