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