www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Creation of a Build tool on top of the D compiler

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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"
Jan 26 2007
next sibling parent reply kris <foo bar.com> writes:
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
Jan 26 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 26 2007
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Jan 26 2007
parent reply kris <foo bar.com> writes:
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.
Jan 26 2007
parent reply "Andrey Khropov" <andkhropov_nosp m_mtu-net.ru> writes:
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
Jan 27 2007
parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 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
Crazy idea, but what if there were an object format could contain something like byte-compiled templates along with real binary code. I guess it would be sort of like precompiled headers that get stuck in the final library. Anyway, it would be cool if I could have all of Boost in one big "library" file rather than a billion little files scattered all over the place. Sorting out all the #include issues seems like it would be tough though. The files depend on being spread all over the place. --bb
Jan 27 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 Sean Kelly wrote:
 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.
Crazy idea, but what if there were an object format could contain something like byte-compiled templates along with real binary code. I guess it would be sort of like precompiled headers that get stuck in the final library.
This is pretty much how C++ "export" works. The files must still be processed at compile-time however, since the generated code may vary based on template parameters.
 Anyway, it would be cool if I could have all of Boost in one big 
 "library" file rather than a billion little files scattered all over the 
 place.
Agreed :-) Sean
Jan 27 2007
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Bill,

 Crazy idea, but what if there were an object format could contain
 something like byte-compiled templates along with real binary code.  I
 guess it would be sort of like precompiled headers that get stuck in
 the final library.
 
 Anyway, it would be cool if I could have all of Boost in one big
 "library" file rather than a billion little files scattered all over
 the place.
 
 Sorting out all the #include issues seems like it would be tough
 though.
 The files depend on being spread all over the place.
 --bb
 
IIRC Ada does somthing like that
Jan 28 2007
prev sibling parent reply BCS <ao pathlink.com> writes:
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.
Jan 26 2007
parent reply kris <foo bar.com> writes:
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)
Jan 26 2007
parent reply BCS <ao pathlink.com> writes:
Reply to kris,

 BCS wrote:
 
 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)
If all imports are private then compiling module N only requiters parsing only the modules that N imports. Also lex/parse/syntax isn't all that compiling requiers.
Jan 27 2007
parent kris <foo bar.com> writes:
BCS wrote:
 Reply to kris,
 
 BCS wrote:

 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)
If all imports are private then compiling module N only requiters parsing only the modules that N imports. Also lex/parse/syntax isn't all that compiling requiers.
I think perhaps we're talking at cross-purposes? <g>
Jan 27 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Jan 26 2007
parent BCS <ao pathlink.com> writes:
Reply to Derek,

 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
vote--
 but it should /not/ be a part of the D Programming Language
 specification.
 
vote++
Jan 27 2007