NetBSD-Users archive

[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:

#ifdef __NetBSD__
#include <sys/param.h>
#if __NetBSD_Version__ …

Ok, now you covered NetBSD. Now you have to do the same for:

• Linux
• Solaris
• FreeBSD
• OpenBSD
• Haiku
• …

and if you added #ifdefs for all those, you still don't support many operating systems!

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 detail
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 respects.

Can you please elaborate? While I agree that most 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 files that check for stuff they don't even need.

Sadly even NetBSD's pkgsrc doesn't make truly ideal use of Autoconf, and
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- wide cache file being used to avoid having to run zillions of identical tests over and over again with the build of each Autoconf-using pkgsrc module. And this is just one example of how lame most use of autoconf has become
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 changed?

It's probably simpler just to look at operating system name and version number and use #ifdef. There will be some differences, but the major APIs don't
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 support the most widely used platforms there's no need to use either Autoconf or
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 target
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).


Home | Main Index | Thread Index | Old Index