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