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
