On Fri, Feb 21, 2003 at 11:37:49PM +0100, Per Olofsson wrote: > * Building shared libraries in a portable way. Autoconf + libtool > helps much when doing that.
The only thing that "needs" to be checked for is, if shared libraries are supported; the rest is handled by a build script customized for the system (libtool?). > * Checking endianness. Most well-written programs don't need this information explicitly and when they do, this information could be provided in a header file of the hypotetical standardization library. There is no need to check for such constants every time a program is compiled. > * Checking length of types. intxx_t types are in C99 IIRC and rather commonly available. The types could be, again, provided by the standardization library for other platforms. > * Headers have different names on different platforms. > (this one may be quite large) A standardization library could include headers to wrap to the right files. > * Compilers behave much differently. There aren't that many different kind of compilation tasks. Scripts could be provided for these. Autoconf probably already has all this information somewhere but doesn't provide a handy script interface. > * libc is full of functions. A library covering all of them will not > necessary be minimal. (also large) Most libc functions are rather standardized, AFAIK. Correct me if I'm wrong. The *nix stuff is the problem. > And yes, if there was a library and there was information available, > there's no need to check for all those things. The problem is that > such a library and such information isn't available. The problem is that autoconf was written instead of a better solution that would remove most of the problems instead just hiding them from the user. The programmer's task isn't any easier than it was, on the contrary. Instead of worrying of differences between *nix variants and such, he now has to worry of how to check for those too and if the script will work on all platforms. > Still, I don't see any reasons to blame Autoconf for everything. I > don't think Autoconf is unreliable, I would say it is the input it > gets that is bad then. You should blame the packages that use > Autoconf, not Autoconf itself. Of course. There can be bad Makefile-based configurations too. They're just easier to fix and less things that can go wrong than with autoconf. -- Tuomo
