[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD macros
Am 18.12.2009 um 22:25 schrieb Greg A. Woods:
No, actually you don't, usually -- and that's my point. You only use
the system-specific identification macros for system-specific
i.e. those features found _only_ on one(1) type of system.
And these system specific features are either different per OS (many
#ifdefs) or available on a many systems (long #ifdefs). Both are bad
code and should be avoided by testing for the specific feature, which
will be always smaller and more efficient if you try to be portable.
If the feature is found on multiple types of systems, but not all, and
for some reason you must still use it, then you should identify it
unique identifier and find some other way to enable that identifier,
other than messing about with system-specific identifiers.
And this is what autoconf does.
(However, BTW, often the version checking is irrelevant because the
feature is, for this example say, a common BSD feature that was
the original code from which all the various modern variants have been
derived -- a wee bit of history goes a long way!)
This is only true for BSD features, but is already false when it comes
to POSIX features. Just think about getaddrinfo for example, which
still is not thread-safe on OpenBSD and is also not thread-safe on
NetBSD 3.x and FreeBSD 5.x. So you _HAVE_ to check versions here.
Also, all that said, I'd rather see a few snarly #ifdef lines in one
header file that can sort out a few necessary conflicting features
to have to use Autoconf.
Then you prefer bad design.
Most configure.ac files are large and result in huge scripts with many
tests because if you truly wish to use Autoconf properly to make your
code as ultra-portable as possible then you really must include a very
large number of tests (and also all the necessary #ifdef's in your
code), even for quite simple programs.
Badly written configure.ac files are not autoconf's fault - most of
the configure.ac files check stuff which they never use anyway - or at
least they check it and never pay attention to the check. It is quite
possible to write short configure.ac checks that do the checks you
want way more efficient than your #ifdef hell.
I.e. they often do know what they're doing -- it's just futile to do
No, checking for a feature and never paying attention to the result is
not knowing what you do - and a lot of configure.ac files do that,
because often it's just copy & pasted from another configure.ac file,
without really understanding it.
That's the problem with doing feature tests and relying on them solely
to keep your code portable.
I do agree that some people do write too many feature tests, but
you're able to go out and re-test the program on every platform it has
already been tested on, it's sometimes really difficult to prove that
any given feature test can be safely removed. Not always, but
Well, as many write code that only works with gcc anyway, you can
leave out a lof of compiler checks. You only need to test gcc for C99
compatibility then, for example, instead of checking for each C99
The right way to do things is to write code that's portable in the
place. Don't ever make use of _any_ system-specific features unless
absolutely necessary! Use template header files to adapt to the few
features which often do vary between systems.
Well, it almost always is absolutely necessary. Even for simple tasks
like using socket.
There are of course classes of programs which must make use of
which are not standardised sufficiently and thus they must have
alternate implementations to supplement systems without, etc.
Which is basically almost every application doing more than simple
Writing good portable code does require one to be a good historian of
the relevant systems and standards, and also to know when supporting a
given system, or class of systems, or even a standard, has become
Who are you to decide whether a system is irrelevant or not? You can't
know if it's still out there in productive use. It's not too long ago
that they shut down the last multics system…
I suppose a first-time programmer who knows little beyond the system
or she is initially working with, can achieve some degree of
of their early code by simply following the Autoconf guide and/or
However even that can come later -- if they simply write good clean
that works properly on the one system they have access to, but which
as much as possible written to use the _standard_ APIs that their
happens to support (POSIX, ISO C, etc.), then any issues with
another system can be addressed at a later time, perhaps with the help
of someone more experienced in porting code. I.e. I would not
one try to make one's first big/largish program portable by
starting with the likes of GNU Autoconf!
Yeah, right, if the standard APIs would be fully supported by at least
one system. Neither GNU, nor BSD fully supports POSIX. And gcc does
not fully support ISO C 99 either.
The point is that the system does not (usually) change! Every test
you do twice or more is a waste of resources.
This is especially false for dependencies. Dependency libraries often
change, for example.
IFF the system does change, eg. you upgrade to a new version, and IFF
the system's APIs have changed incompatibly, then you need to throw
the cache and start fresh. You know when you've changed the system,
you know how to manage your cache file!
So you want to update the entire cache each time you changed only a
little bit to the system? Great, now _THAT_'s waste of checks!
And what if I decide to compile a single application with another
compiler? What if I decide to cross compile? What if I changed some
flags with which some stuff is not available?
Ideally Autoconf would come with a standard boiler-plate configure.ac
file which could be run once on a target system to generate a cache
all standard tests.
I already see the bug reports due to broken caches. Yeah, really
something I want to spend my time on: Closing bugs in bugtrackers and
tell people to regenerate their cache…
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.
I would claim that's not why many abstractions were invented,
not for GUIs. They are not primarily portability layers -- though
sometimes they can be made to do that job as well. Even those which
start out as simple portability layers have almost always gone well
beyond that level. Most abstraction layers are designed to hide
complexity and to (hopefully) share common code.
Well, glib's and Qt4Core's main purpose is to provide functions for
commonly used tasks (like for example opening a file and building a
path) for every system they work on. This is what I'd call a
Main Index |
Thread Index |