digitalmars.D - Creation of a Build tool on top of the D compiler
- Frank Benoit (keinfarbton) (5/5) Jan 26 2007 Now we have dependency information in the verbose output of DMD.
- kris (11/18) Jan 26 2007 Er, why not just have a compiler option to do a simplistic "build"
- Sean Kelly (5/25) Jan 26 2007 Good point :-) I guess the run option currently only works for
- Hasan Aljudy (3/12) Jan 26 2007 I thought it'd also work if you pass all the file names at the command
- kris (9/29) Jan 26 2007 heh - it will, but that's impractical to do by hand [1]. Especially when...
- Andrey Khropov (7/10) Jan 27 2007 I strongly believe that compiler *should* be able to compile templates t...
- Sean Kelly (5/15) Jan 27 2007 C++ tried this with "export" and it's been a bit of a fiasco. Last I
- Bill Baxter (11/33) Jan 27 2007 Crazy idea, but what if there were an object format could contain
- Sean Kelly (6/34) Jan 27 2007 This is pretty much how C++ "export" works. The files must still be
- BCS (2/16) Jan 28 2007 IIRC Ada does somthing like that
- BCS (5/29) Jan 26 2007 what If I have a 200+ module project that take ten minutes to compile (l...
- Derek Parnell (5/12) Jan 26 2007 Just a reminder that this sort of thing might be placed into a D compile...
- BCS (3/17) Jan 27 2007 vote++
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
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
kris wrote:Frank Benoit (keinfarbton) wrote:Seems like it would.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?Good point :-) I guess the run option currently only works for single-module apps, huh? Sean
Jan 26 2007
Sean Kelly wrote:kris wrote:I thought it'd also work if you pass all the file names at the command line, heh.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?
Jan 26 2007
Hasan Aljudy wrote:Sean Kelly wrote: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.kris wrote:I thought it'd also work if you pass all the file names at the command line, heh.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?
Jan 26 2007
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
Andrey Khropov wrote:kris wrote: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. SeanEspecially 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.
Jan 27 2007
Sean Kelly wrote:Andrey Khropov wrote: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. --bbkris wrote: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. SeanEspecially 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.
Jan 27 2007
Bill Baxter wrote:Sean Kelly wrote: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.Andrey Khropov wrote: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.kris wrote: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.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.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
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. --bbIIRC Ada does somthing like that
Jan 28 2007
Reply to kris,Frank Benoit (keinfarbton) 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.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
BCS wrote:Reply to kris,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)Frank Benoit (keinfarbton) 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.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
Reply to kris,BCS wrote: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.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 27 2007
BCS wrote:Reply to kris,I think perhaps we're talking at cross-purposes? <g>BCS wrote: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.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 27 2007
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
Reply to Derek,On Sat, 27 Jan 2007 00:24:09 +0100, Frank Benoit (keinfarbton) wrote:vote--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 compilerbut it should /not/ be a part of the D Programming Language specification.vote++
Jan 27 2007