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

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

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.

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)

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?

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!

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

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

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.

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

> 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