Stewart Brodie <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
