Denis Koroskin wrote:
Does it look any better? No way!
Of course doing it that way doesn't look any better, because it still
just replicates the C preprocessor style of doing it.
A far better solution is to create a series of modules:
gcnetbsd.d
gchurd.d
gcsunos5.d
...
and inside each one put the specifics for that particular system. The
huge advantage of this is that if I want to create a BrightBSD operating
system, I just have to write a:
gcbrightbsd.d
rather than trying to carefully fold it into that conditional
compilation mess without inadvertently breaking other platform support.
(And I cannot even tell if I broke the SunOS5 platform support or not,
because I don't have a SunOS5 platform to test it on.)
The story is not about different functionality on different platforms
but rather about a common code which is 98% the same on all the
platforms and is different in *small* details.
For example, I'd like to
make my library D1 and D2 compatible. Do you suggest me to maintain 2
different libraries? This is ridiculous, and that's why there is no
Tango2 release yet - there is *no* point in supporting such a large
library as Tango (or DWT) for two language versions without a sane
versioning mechanism.
There are two very different things going on here. One is accounting for
differences in the *language*, the other is about generating different
builds based on language independent different desired features and
platform characteristics.
I agree that version is not a solution to the D1/D2 language difference
problem, and furthermore contend it cannot be coerced into being one.
The only real solution, other than maintaining separate source files, is
to use a text macro preprocessor.
(Sadly, the C preprocessor cannot be used, because it is a tokenizing
textual preprocessor, and C preprocessor tokens are different from D
tokens.)
