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.
