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*/;"...
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.
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.
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.
--anders
PS. Some people even think that /usr/bin/python exists. :-)
Guess they were confusing it with standard /usr/bin/perl