digitalmars.D - Modules/packages correspondence to file system
- Lars E. (14/14) Jul 18 2006 Why are tools like build (http://dsource.org/projects/build) even
- jcc7 (7/9) Jul 18 2006 I disagree that they are "neccessary", but they are useful.
- Hasan Aljudy (3/17) Jul 18 2006 I think his point was, build shouldn't have been needed in the first
- BCS (4/31) Jul 18 2006 If it was there, my immediate first question would be "How do I turn it
- Bruno Medeiros (5/37) Jul 21 2006 Why is that, why wouldn't you use build's functionality?
- BCS (8/24) Jul 21 2006 I like to be able to control things my self. I have some builds that
- Chris Nicholson-Sauls (11/41) Jul 22 2006 Depending on the details, you should be fine with BRF (Build Response Fi...
- BCS (28/47) Jul 24 2006 Build is good for what it does, mostly D projects that might have a few
- Bruno Medeiros (13/38) Jul 26 2006 The functionality that I think should be part of DMD is the one that
- kris (12/39) Jul 18 2006 Yes. I'm also of the opinion the "recursive import" aspect of Build
- Hasan Aljudy (3/46) Jul 18 2006 Yeah, I can't code without build :)
- Lucas Goss (4/9) Jul 19 2006 Yes, thanks Derek. Without Build I might not have gotten into D. Build
Why are tools like build (http://dsource.org/projects/build) even neccessary? I think I read somewhere in the official D docs that the name of the module equals the name of the source file minus extension (unless otherwise specified) and the name of the package equals the name of the directory structure the module resides in. Shouldn't that be enough for the compiler to automatically figure out dependencies itself (if you specified extra search paths if neccessary)? Isn't that how the Java compiler works? I noticed you can easily abstract packages/modules from the file system. That seems a bad idea. I know it allows for more flexibility but with that flexibility comes a great deal of complexity. Simple things should stay simple .. imagine a world without makefiles (build provides this, but why not the language itself?)!
Jul 18 2006
In article <e9jaad$1mlg$1 digitaldaemon.com>, Lars E. says...Why are tools like build (http://dsource.org/projects/build) even neccessary?I disagree that they are "neccessary", but they are useful. These tools are useful because they provide functionality that isn't currently available in dmd/gdc. Maybe someday the compilers include more features that Build has, and Build would become less useful. (But I suspect that won't happen any time soon and Build will continue to be quite useful for a long time.) ;) jcc7
Jul 18 2006
jcc7 wrote:In article <e9jaad$1mlg$1 digitaldaemon.com>, Lars E. says...I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.Why are tools like build (http://dsource.org/projects/build) even neccessary?I disagree that they are "neccessary", but they are useful. These tools are useful because they provide functionality that isn't currently available in dmd/gdc. Maybe someday the compilers include more features that Build has, and Build would become less useful. (But I suspect that won't happen any time soon and Build will continue to be quite useful for a long time.) ;) jcc7
Jul 18 2006
Hasan Aljudy wrote:jcc7 wrote:If it was there, my immediate first question would be "How do I turn it off?" and my next question would be (several months later) "DMD does that?". (repeat question 1)In article <e9jaad$1mlg$1 digitaldaemon.com>, Lars E. says...I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.Why are tools like build (http://dsource.org/projects/build) even neccessary?I disagree that they are "neccessary", but they are useful. These tools are useful because they provide functionality that isn't currently available in dmd/gdc. Maybe someday the compilers include more features that Build has, and Build would become less useful. (But I suspect that won't happen any time soon and Build will continue to be quite useful for a long time.) ;) jcc7
Jul 18 2006
BCS wrote:Hasan Aljudy wrote:Why is that, why wouldn't you use build's functionality? -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#Djcc7 wrote:If it was there, my immediate first question would be "How do I turn it off?" and my next question would be (several months later) "DMD does that?". (repeat question 1)In article <e9jaad$1mlg$1 digitaldaemon.com>, Lars E. says...I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.Why are tools like build (http://dsource.org/projects/build) even neccessary?I disagree that they are "neccessary", but they are useful. These tools are useful because they provide functionality that isn't currently available in dmd/gdc. Maybe someday the compilers include more features that Build has, and Build would become less useful. (But I suspect that won't happen any time soon and Build will continue to be quite useful for a long time.) ;) jcc7
Jul 21 2006
Bruno Medeiros wrote:BCS wrote:I like to be able to control things my self. I have some builds that have more non-D than D parts. I have some builds that need the same file to be compiled several times under different version settings. DMD couldn't do much of what I need without becoming more of a build tool than a compiler. Once I need to use something other than DMD (as it is now) to do the build, I want something more general purpose that DMD should ever become.Hasan Aljudy wrote:Why is that, why wouldn't you use build's functionality?I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.If it was there, my immediate first question would be "How do I turn it off?" and my next question would be (several months later) "DMD does that?". (repeat question 1)
Jul 21 2006
BCS wrote:Bruno Medeiros wrote:Depending on the details, you should be fine with BRF (Build Response File) and properly set up RDF (Rules Definition File) entry for the non-D parts.BCS wrote:I like to be able to control things my self. I have some builds that have more non-D than D parts.Hasan Aljudy wrote:Why is that, why wouldn't you use build's functionality?I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.If it was there, my immediate first question would be "How do I turn it off?" and my next question would be (several months later) "DMD does that?". (repeat question 1)I have some builds that need the same file to be compiled several times under different version settings.Now that's a tough one. Could use a batch to explicitly compile that module a few times, with the different settings, followed by an invocation to build, and include in your BRF a directive to ignore that module. Still a little much though.DMD couldn't do much of what I need without becoming more of a build tool than a compiler. Once I need to use something other than DMD (as it is now) to do the build, I want something more general purpose that DMD should ever become.I agree in that a compiler should be a compiler, and not a build tool. I've actually been known to get mildly frustrated with the Java compiler, when it would get slightly over-zealous on me. (Never anything severe... but like you, I do like to have fine control over things.) -- Chris Nicholson-Sauls
Jul 22 2006
Chris Nicholson-Sauls wrote:BCS wrote:Build is good for what it does, mostly D projects that might have a few non D parts. But it seems a bit clumsy when things start getting more complicated. I just had a neat thought, build figures out all of the dependencies of a build, could it be made to generate a makefile that will have the same effect? </input> <code file="foo.d"> import bar; </code> <code file="bar.d"> import baz; </code> <code file="baz.d"> ... </code> </input> <output> foo : foo.o bar.o baz.o dmd foo.o bar.o baz.o $(D_LINK) foo.o : foo.d bar.d baz.d dmd -c foo.d bar.o : bar.d baz.d dmd -c bar.d baz.o : baz.d dmd -c baz.d </output>I have some builds that have more non-D than D parts.Depending on the details, you should be fine with BRF (Build Response File) and properly set up RDF (Rules Definition File) entry for the non-D parts.I have some builds that need the same file to be compiled several times under different version settings.Now that's a tough one. Could use a batch to explicitly compile that module a few times, with the different settings, followed by an invocation to build, and include in your BRF a directive to ignore that module. Still a little much though. -- Chris Nicholson-Sauls
Jul 24 2006
On Mon, 24 Jul 2006 09:44:50 -0500, BCS wrote:Chris Nicholson-Sauls wrote:Agreed. However, I would like to hear from people about the "more complicated" builds so that maybe I can do something about them. Personally, I try to avoid complications of this sort ;-) I'm currently looking at the "multiple compile" idea in which a source can be made to under go mutliple compiles with different switch/options each time.BCS wrote:Build is good for what it does, mostly D projects that might have a few non D parts. But it seems a bit clumsy when things start getting more complicated.I have some builds that have more non-D than D parts.Depending on the details, you should be fine with BRF (Build Response File) and properly set up RDF (Rules Definition File) entry for the non-D parts.I have some builds that need the same file to be compiled several times under different version settings.Now that's a tough one. Could use a batch to explicitly compile that module a few times, with the different settings, followed by an invocation to build, and include in your BRF a directive to ignore that module. Still a little much though. -- Chris Nicholson-SaulsI just had a neat thought, build figures out all of the dependencies of a build, could it be made to generate a makefile that will have the same effect?Yes it could, but why? It already creates a kind of makefile - the response files for the compiler and linker. -- Derek Parnell
Jul 24 2006
BCS <BCS pathlink.com> Derek wrote:On Mon, 24 Jul 2006 09:44:50 -0500, BCS wrote:Some of my more complicate builds have involved things like using Enki to generate d code compiling that into a program that then generates more d code and them compiling that. For example look at my NetIDL source, I have a makefile file that will start with only the hand generate files and build everything right on out through the examples. I use a hacked version of Enki so I have considered even putting it's bootstrap and build into the makefile. Other things I have done include a sort of poor mans version control (copy everything needed into a new directory) which is pure shell scripting. Some other makefiles use the generated executable to do things (like in the first case, but not code generation).Build is good for what it does, mostly D projects that might have a few non D parts. But it seems a bit clumsy when things start getting more complicated.Agreed. However, I would like to hear from people about the "more complicated" builds so that maybe I can do something about them. Personally, I try to avoid complications of this sort ;-)I'm currently looking at the "multiple compile" idea in which a source can be made to under go mutliple compiles with different switch/options each time.Have Build generate this make file, run it through something like sed to apply arbitrary modifications and then make the result. This would gain many of the benefits of build (automatic dependency searching) while being flexible enough to be used where build would be at its worst (lots of non D stuff) I haven't spent much time looking at Build so It might already do what I want.I just had a neat thought, build figures out all of the dependencies of a build, could it be made to generate a makefile that will have the same effect?Yes it could, but why?
Jul 25 2006
BCS wrote:Bruno Medeiros wrote:The functionality that I think should be part of DMD is the one that (just as javac) figures out the dependencies between modules and (optionally) compiles the whole dependencies together, or does some other work with the found dependencies. I think that it should be part because this is a language-dependent functionality, it requires knowledge of the language and partial parsing of the language source files (which is what the compiler already does and knows). All other kinds of functionality, i.e., language-independent, should be handled by generic build tools (shell scripts, Make, Ant, SConS, etc.). -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#DBCS wrote:I like to be able to control things my self. I have some builds that have more non-D than D parts. I have some builds that need the same file to be compiled several times under different version settings. DMD couldn't do much of what I need without becoming more of a build tool than a compiler. Once I need to use something other than DMD (as it is now) to do the build, I want something more general purpose that DMD should ever become.Hasan Aljudy wrote:Why is that, why wouldn't you use build's functionality?I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.If it was there, my immediate first question would be "How do I turn it off?" and my next question would be (several months later) "DMD does that?". (repeat question 1)
Jul 26 2006
Hasan Aljudy wrote:jcc7 wrote:Yes. I'm also of the opinion the "recursive import" aspect of Build should be part of the compiler front-end ... for dmd, the necessary changes are quite simple; with gdc the changes are apparently a little more involved. On the other hand, I wouldn't want to take anything away from Build ... Derek has given us a extremely useful tool, and deserves all the credit for making D "usable on a daily basis" (yes, it makes that much of a difference) for anything other than demo programs. Still, if Derek would be comfortable 'gifting' that aspect of Build with the compiler front-end, I think it really should be in there. What do others think? And Derek?In article <e9jaad$1mlg$1 digitaldaemon.com>, Lars E. says...I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.Why are tools like build (http://dsource.org/projects/build) even neccessary?I disagree that they are "neccessary", but they are useful. These tools are useful because they provide functionality that isn't currently available in dmd/gdc. Maybe someday the compilers include more features that Build has, and Build would become less useful. (But I suspect that won't happen any time soon and Build will continue to be quite useful for a long time.) ;) jcc7
Jul 18 2006
kris wrote:Hasan Aljudy wrote:Yeah, I can't code without build :) So .. Thanks Derek!jcc7 wrote:Yes. I'm also of the opinion the "recursive import" aspect of Build should be part of the compiler front-end ... for dmd, the necessary changes are quite simple; with gdc the changes are apparently a little more involved. On the other hand, I wouldn't want to take anything away from Build ... Derek has given us a extremely useful tool, and deserves all the credit for making D "usable on a daily basis" (yes, it makes that much of a difference) for anything other than demo programs.In article <e9jaad$1mlg$1 digitaldaemon.com>, Lars E. says...I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.Why are tools like build (http://dsource.org/projects/build) even neccessary?I disagree that they are "neccessary", but they are useful. These tools are useful because they provide functionality that isn't currently available in dmd/gdc. Maybe someday the compilers include more features that Build has, and Build would become less useful. (But I suspect that won't happen any time soon and Build will continue to be quite useful for a long time.) ;) jcc7
Jul 18 2006
kris wrote:Still, if Derek would be comfortable 'gifting' that aspect of Build with the compiler front-end, I think it really should be in there. What do others think? And Derek?Yes, thanks Derek. Without Build I might not have gotten into D. Build is the main reason I'm here. Lucas
Jul 19 2006