www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Modules/packages correspondence to file system

reply "Lars E." <notavailable notavailable.com> writes:
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
parent reply jcc7 <jcc7_member pathlink.com> writes:
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
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
jcc7 wrote:
 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

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.
Jul 18 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Hasan Aljudy wrote:
 
 
 jcc7 wrote:
 
 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

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 18 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
BCS wrote:
 Hasan Aljudy wrote:
 jcc7 wrote:

 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

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)

Why is that, why wouldn't you use build's functionality? -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 21 2006
parent reply BCS <BCS pathlink.com> writes:
Bruno Medeiros wrote:
 BCS wrote:
 
 Hasan Aljudy wrote:

 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)

Why is that, why wouldn't you use build's functionality?

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.
Jul 21 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
BCS wrote:
 Bruno Medeiros wrote:
 
 BCS wrote:

 Hasan Aljudy wrote:

 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)

Why is that, why wouldn't you use build's functionality?

I like to be able to control things my self. I have some builds that have more non-D than D parts.

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.

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.

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
parent reply BCS <BCS pathlink.com> writes:
Chris Nicholson-Sauls wrote:
 BCS wrote:
 
 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

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>
Jul 24 2006
parent reply Derek <derek psyc.ward> writes:
On Mon, 24 Jul 2006 09:44:50 -0500, BCS wrote:

 Chris Nicholson-Sauls wrote:
 BCS wrote:
 
 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

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.
 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? It already creates a kind of makefile - the response files for the compiler and linker. -- Derek Parnell
Jul 24 2006
parent BCS <BCS pathlink.com> writes:
Derek wrote:
 On Mon, 24 Jul 2006 09:44:50 -0500, 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.

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 ;-)

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).
 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.
 
 
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?

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.
Jul 25 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
BCS wrote:
 Bruno Medeiros wrote:
 BCS wrote:

 Hasan Aljudy wrote:

 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)

Why is that, why wouldn't you use build's functionality?

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.

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#D
Jul 26 2006
prev sibling parent reply kris <foo bar.com> writes:
Hasan Aljudy wrote:
 
 
 jcc7 wrote:
 
 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

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.

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?
Jul 18 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
kris wrote:
 Hasan Aljudy wrote:
 
 jcc7 wrote:

 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

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.

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.

Yeah, I can't code without build :) So .. Thanks Derek!
Jul 18 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
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