Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Benoit (keinfarbton) | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
January 27, 2007 Re: Creation of a Build tool on top of the D compiler | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly |
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Hasan Aljudy | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Benoit (keinfarbton) | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrey Khropov | 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
|
Copyright © 1999-2021 by the D Language Foundation