version() abuse! Note of library writers.

[Travis Boucher]

Anders F Björklund wrote:
> Travis Boucher wrote:
>> The use of version(...) in D has the potential for some very elegant 
>> portable code design.  However, from most of the libraries I have 
>> seen, it is abused and misused turning it into a portability nightmare.
> 
> It has done this for years, so it's already turned that way.
> Usually it's "version(Win32) /*Windows*/; else /*linux*/;"...

I'm fairly new to D, and one thing I really love about it is the removal 
of the preprocessor in favor of specific conditional compilation 
(version, debug, unittest, static if, CTFE, etc).  Nothing was worse 
then trying to decode a massive #ifdef tree supporting different 
features from different OSes.

I don't expect things to change right now, but I think that there should 
be some standard version() statements that are not only implementation 
defined.  I'd also like people to start thinking about the OS 
hierarchies with version statements.

Windows
   Win32
   Win64
   WinCE  (as an example...)
Posix (or Unix, I don't care which one)
   BSD
     FreeBSD
     OpenBSD
     NetBSD
     Darwin
   Linux
   Solaris

The problem with "version(Win32) /*Windows*/; else /*linux*/;" is fairly 
subtle, but I have run into it alot with bindings to C libraries that 
use the dlopen() family and try to link against libdl.

>> Anything that accesses standard libc functions, standard unix 
>> semantics (eg. signals, shm, etc) should use version(Posix) or 
>> version(unix).
> 
> Nice rant, but it's "version(Unix)" in GCC and we're probably
> stuck with the horrible version(linux) and version(OSX) forever.

On my install (FreeBSD) version(Unix) and version(Posix) are both defined.

>> Build systems and scripts that are designed to run on unix machines 
>> should not assume the locations of libraries and binaries, and refer 
>> to posix standards for their locations.  For example, bash in 
>> /bin/bash or the assumption of the existence of bash at all.  If you 
>> need a shell script, try writing it with plain bourne syntax without 
>> all of the bash extensions to the shell, and use /bin/sh.  Also avoid 
>> using the GNU extensions to standard tools (sed and awk for example).  
>> If you really want to do something fancy, do it in D and use the 
>> appropriate {g,l}dmd -run command.
> 
> I rewrote my shell scripts in C++ for wxD, to work on Windows.
> Tried to use D (mostly for DSSS), but it wasn't working right.

Yeah, I can understand in some cases using D itself could be a major 
bootstrapping hassle.  This issue isn't D specific, and exists in alot 
of packages.  I've even gotten to the point to expect most third party 
packages won't work with FreeBSD's make, and always make sure GNU make 
is available.

>> A few things to keep in mind about linux systems vs. pretty much all
>> other unix systems:
> 
> Nice list, you should put it on a web page somewhere (Wiki4D ?)
> Usually one also ends up using runtime checks or even autoconf.

I haven't registered in Wiki4D yet, I might soon once I take the time to 
clean up this ranty post into something a little more useful.

> 
> PS. Some people even think that /usr/bin/python exists. :-)
>     Guess they were confusing it with standard /usr/bin/perl

I won't even go into my feelings about python.  Sadly perl is slowly 
becoming more extinct.  It would be nice for people to remember that 
perl started as a replacement for sed & awk, and still works well for 
that purpose.  At least people don't assume ruby exists.

The bad thing is when a build system breaks because of something 
non-critical failing.  A good example of this is the gtkd demoselect.sh 
script.  It use to assume /bin/bash, which would trigger a full build 
failure.  Since it was changed to /bin/sh, it doesn't work correctly on 
FreeBSD (due to I think some GNU extensions used in sed), but it doesn't 
cause a build failure.  It just means the default demos are built.