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

Reply via email to