Modules/packages correspondence to file system

[Chris Nicholson-Sauls]

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