On Thu, Dec 14, 2006 at 01:10:01PM -0800, Bob Palowoda wrote: > I often wondered what the meaning of porting meant when it > comes to 'autoconf'. Maybe an example to the gates of hell.
Yes. As often as not, porting software these days includes both the traditional removal of platform- or OS-specific assumptions and now the new component of working around the braindead insistence of autoconf and especially libtool that they know how to deal with your platform when in fact they usually do the exact wrong thing. That said, I like what Eric's put together here; it seems like essentially a human-readable version of the metadata that ports archives contain. The knowledge-sharing aspect is commendable; this can in effect serve as a repository of information about the very kinds of workarounds I referred to above. Nevertheless, I think it punts on the essential issue: the machine-readable metadata repository itself. That is, it's pretty easy to take a machine-readable repository and offer a human-readable front-end like this one. The hard part, overwhelmingly, is getting enough people to agree on the form that repository will take to make it viable, and unfortunately that task requires both tremendous technical ability and superb statesmanship. So I see this as a placeholder for knowledge, waiting for someone to come along and put an implementation in place. I do question the value of the rating scale, however; using autoconf is actually not always an advantage, especially if the contents of config.in are wrong. Software that includes a generic set of Makefiles that works on recent versions of common systems (Solaris, GNU/Linux, BSD, and HPUX) would actually be more useful in the real world than software that uses autotools and libtool to attempt to understand the characteristics of every conceivable platform. That is, I care a lot more that my software can build and work on S10 than that it can be built on Dynix, especially since I'm CERTAIN that no one has ever tested most of this software on Dynix and thus it almost surely doesn't work even if it somehow does build. It wouldn't be so bad, of course, if autoconf actually got it right, but it almost never does. A casual glance through autoconf's output when building a typical component on Solaris Nevada will reveal anywhere from a handful to dozens of pieces of inaccurate information. Of course, as often as not, the information in question - which the author of config.in took pains to obtain - is never actually used to build the software, which usually consists of only a few C source files that could easily be compiled using a couple of generic make rules in a 40-line makefile that would work on any OS you're likely to encounter in the real world. Worse, autotools-based config systems usually end up emitting GNU-make-specific output even when $MAKE is set to some other make, so not only are autotools not useful as portability aids, they are often active hindrances. Even in the cases in which autoconf gets it right, libtool will *ALWAYS* produce broken libraries. So really I'd give a big fat -4 to any component that delivers a library and uses libtool to build it, a -2 to any component that fails to take advantage of or duplicates existing, available system functionality because of broken, missing, or inadequate autoconf functionality test macros, and -1 to anything that spews out crap from configure that doesn't actually have anything to do with the objects being produced. A perfect example of this is the search for a FORTRAN compiler. It scarecly matters what this test concludes if the component doesn't include any FORTRAN source; whatever configure outpus is either useless or confusing - if it finds g77, does that mean I might want to start over using F77=/opt/SUNWspro/bin/f77? What if it doesn't find libfoo, an optional dependency? Do I care? If there's no way to say "I really want to use the functionality that depends on libfoo" then how can I - automatically - ensure that libfoo is found and usable, even if the author of the component has provided a way to build on systems without it? That seems like a big fat -2 right there, at least. By the time I got through every significant defect with most of these build systems, I'd be assigning most components a nice big -20 even though many of them do in fact build and at least appear upon casual inspection to work. At the same time, it's not a big deal to me if the code includes gccisms; after all, gcc is part of Solaris and generally works fine. I'd much rather code use OS- and architecture-independent gccisms than be compiler-neutral but make architecture- or OS-specific assumptions, or rely on some bleeding-edge compiler version (whether gcc or anything else). See, I'm a lot less interested in whether something appears upon casual inspection to work on 20 different systems that no one's used since 1985. It's a lot more important that it *actually* work *correctly* and *reliably* on *Solaris*. Obviously, at some level that reflects my personal biases and values, but it's also a pragmatic response to what's become a highly baroque build infrastructure. To the extent that this repository can offer the magic 500-character command lines needed to get autotools to approximate that state of affairs, it's a helpful step forward (even if only in convincing people that autoconf isn't the right answer). But absent a rigorous test infrastructure, admittedly at least partly the responsibility the authors themselves have shirked in many cases, it's not clear to me that we have a handle on the actual efficacy of the instructions. Sure, we can tell whether it builds, but what does that mean? Therefore useful enhancements to this repository might include: - The expected correct output of configure (vetted for inaccuracies which are addressed by included diffs) - A set of tests, even manual ones, which will verify that the software actually does work beyond simply not dumping core when fed --help. - At least lip service to cross-platform builds (for example, the emacs instructions include -xpentium in CFLAGS - I'm sure that ain't gonna work on SPARC). - A list of optional dependencies in addition to third-party requirements, and how to incorporate them - analogous to Portage's IUSE and friends. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
