Re: functions in different libraries on different OSes.

[Russ Allbery]

Stewart Brodie <address@hidden> writes:

> I still tend to check for it on the basis that I check all other header
> files, so I might as well check that one.  There are systems that do not
> have sys/types.h.  That way, all header file checks are done the same
> way.  That also means that I always check for stdio.h too, which is
> contrary to the recommendations, but makes all the header checks the
> same.

I don't understand what you're trying to accomplish.

If you find a system that doesn't have those header files, they won't be
included.  The types and functions defined in those header files therefore
won't be declared, and your program will break (unless you don't actually
need those header files, in which case there was no need to include them
at all).  The only thing that you're actually handling in the way of
portability is portability to systems without those header files that
nonetheless declare everything that you use in your program in some other
header file that you're also including, and I strongly disbelieve in the
existence of any such system.

Furthermore, if you do encounter a system without such header files,
you've ensured that your program is going to fail to compile with strange
and bizarre error messages that the user won't understand rather than
failing with the clear error message of "can't find sys/types.h" and
letting the user thwack his head and go "of course, I forgot to install
the library header files, let me go do that."

So in other words, this doesn't make your code any more portable and makes
it harder to correct correctable errors in the build environment and
harder to port to some obscure system that actually doesn't have those
headers.

Really, I think the first principle of writing autoconf scripts should be
"never make any check for which your code is not prepared to handle either
outcome."  Handling it may involve aborting the compilation with a clear
error message, but just not including necessary header files if they don't
exist without ever testing on a system where they don't exist isn't really
handling it.

If you follow that principle of autoconf design, your code will fail in
more predictable fashions on platforms to which it has not yet been ported
and the porter will be able to get right to the heart of the problem
rather than digging through your configure machinery to untangle the
random stuff you're doing that was never tested.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>