Re: NetBSD macros

[Jonathan Schleifer <js%webkeks.org@localhost>]

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__ …
…
#else
…
#endif

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

• Linux
• Solaris
• FreeBSD
• OpenBSD
• AIX
• HP-UX
• Haiku
• QNX
• …

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 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,  
> 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.
>
> Indeed.

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).

--
Jonathan