[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD macros
Am 14.12.2009 um 20:43 schrieb Greg A. Woods:
I wasn't referring to __NetBSD__ alone -- I would include
<sys/param.h>'s __NetBSD_Version__ as well of course.
So you'd already have:
#if __NetBSD_Version__ …
Ok, now you covered NetBSD. Now you have to do the same for:
and if you added #ifdefs for all those, you still don't support many
Ok, now please write this for just a single function you need to
check. And then please think about how much code you have just written
and rethink about if that's really more useful than just checking for
the feature you want…
Neither should be used blindly either of course -- it's horrid to see
long trails of "#if defined(__NetBSD__) || defined(__FreeBSD__) ||
defined(__OpenBSD__) || defined(__DragonFly__) || defined(__Darwin__)"
(with the only missing one being __Linux__ or whatever!)
Although this is already long, it's wrong as it does not check versions.
None the less there are places where both __NetBSD_Version__ and
__NetBSD__ can be used effectively.
Only if you intend to write code that is for NetBSD only and want to
make sure it runs on different NetBSD versions.
I have looked into Autoconf (and Automake, and libtool) in great
and I have used them on a number of projects, as well as having
maintained and ported many more projects (hundreds!) which they use.
(I've also worked in great detail with Imake and Imake-using projects,
and I've worked extensively with some proprietary build-time
configuration systems as well.)
Autoconf _is_ far too complex and far too time consuming in all
Can you please elaborate? While I agree that most configure.ac files
are too big because they are written by people who don't know what
they're doing, you can to very much in autoconf with very little code.
For the time consuming part, I couldn't disagree more: It's much more
time consuming to write a check yourself when it's just a single line
in autoconf. If you were reffering to the time needed to run the
generated configure script, this is again because many write stupid
configure.ac files that check for stuff they don't even need.
Sadly even NetBSD's pkgsrc doesn't make truly ideal use of Autoconf,
in part it doesn't do so because Autconf users are not disciplined
enough overall to allow for such ideal use. I.e. there's no system-
cache file being used to avoid having to run zillions of identical
over and over again with the build of each Autoconf-using pkgsrc
And this is just one example of how lame most use of autoconf has
over the years.
There's nothing wrong with doing the checks again, as the system can
have changed. If it would cache it, how would it know the system
It's probably simpler just to look at operating system name and
and use #ifdef. There will be some differences, but the major APIs
chance that much.
That's not true, see above.
These days even if you're writing X11 applications (i.e. rather than
just plain POSIX command-line style programs) and hoping only to
the most widely used platforms there's no need to use either
Imake. Such code can be written in a portable way without even having
to resort to very many #ifdef's at all.
This is why abstraction was invented - and as most GUI applications
use Qt or GTK, they come with a framework as well that takes care of
portability for you.
The problem of course with doing so is that few programmers have the
depth of experience of writing and maintaining code on all their
platforms, as well has having a good understanding of historical
portability issues across all of unix-land.
If you use one of the above mentioned frameworks, you don't have to
care too much about that, as they should behave the same on all
systems (at least in theory, sometimes they don't due to bugs - but in
this case, reporting the bug and hoping that it gets fixed is the way
to go instead of doing even more strange things).
Main Index |
Thread Index |