Conditional Compilation Multiple Versions
    Joakim via Digitalmars-d-learn 
    digitalmars-d-learn at puremagic.com
       
    Sat Jan  7 23:36:54 PST 2017
    
    
  
On Friday, 6 January 2017 at 13:44:37 UTC, Claude wrote:
>> Yes, it works quite well for most use cases and should 
>> generally be preferred. I disagree that it scales, though. At 
>> some point (a point that is highly project-dependent), it 
>> breaks down, requiring either very large modules or duplicated 
>> versions across multiple modules.
>
> Yes, in that case, you would probably break it down into 
> several specialized config modules. I meant it forces you not 
> to put directly version(Windows) into your code, but rather 
> version(ThatFeatureSupportedByWindowsAmongstOtherOSs).
Yes, this is the idiom that version() encourages.  You can put 
all your configuration logic in one place in your build script 
and then pass -version=hasFeature to your build.  If you use 
reggae, you can even write your configuration logic in D:
https://github.com/atilaneves/reggae/
>> My position is that I will always choose version blocks first, 
>> but if I find myself in a situation where I have to choose 
>> between duplicating version statements (e.g. version(A) 
>> {version=AorB; version=AorC;}) across multiple modules and 
>> restructuring my code to accommodate versioning, I much prefer 
>> to use the enum alternative as an escape hatch.
>
> Ok, that's interesting.
> Do you have code samples where you do that? I'm just curious.
Druntime uses this for its translation of POSIX header files:
https://github.com/dlang/druntime/blob/master/src/core/sys/posix/config.d
An example:
https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/resource.d#L96
    
    
More information about the Digitalmars-d-learn
mailing list