Modules/packages correspondence to file system

Bruno Medeiros brunodomedeirosATgmail at SPAM.com
Wed Jul 26 09:29:58 PDT 2006


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



More information about the Digitalmars-d mailing list