* Stepan Kasal wrote on Tue, Apr 04, 2006 at 04:29:02PM CEST: > On Tue, Apr 04, 2006 at 02:25:03PM +0200, Ralf Wildenhues wrote: > > * Ed Hartnett wrote on Tue, Apr 04, 2006 at 01:58:39PM CEST: > > > > The autotools way is hard at first but scales very well. > > > > There are some known scaling issues that come with the autotools, [...] > > I this this might cause misunderstanding: Yes, you are correct, to some extent. I am diffusively speaking about several different things at once. > The extra infrastructure costs something. (If you wanted extra-quick > builds, you'd use hand-crafted build environment, of course.) > Our scaling here could be better: when the project is more and more > ``complicated,'' the builds are slower and slower. > > But what does the ``complicated'' mean here? Basically, as your project > has more and more subdirectories and shared libraries, and as also as you > add support for more and more totally different platforms, the build slows > down. But also as both you, the package author, and autotools discover and take care of more issues on more systems, there are and will be more tests. Thus the configure script gets larger. Let's have an example: AC_INIT AC_PROG_CC AC_CHECK_HEADERS([foo.h]) With Autoconf-2.13, this invokes the compiler 4 times, and the preprocessor once. With Autoconf-2.59, we are at 4 simple compiler invocations (--version and such), 5 preprocessor invocations, and 19 compiler invocations, and a check for one tool (egrep). With 2.60, we will actually be at 18 compiler invocations only, but we check for two tools (grep and egrep). The sizes of the respective configure scripts: 2.13: 30356 2.59: 84093 HEAD: 93637 So yes, there is a cost attached to portability. I don't see any point in trying to discuss it away. (You may call this example unfair, and I won't disagree ;-) Luckily, I chose an interface as an example that is well implemented in one respect: as you increase the number of headers to test listed in the argument of the AC_CHECK_HEADERS macro, only the number of compilations and preprocessing increases (and both only by one, for 2.59+), but the size of the configure script increases by a tiny amount only. Invoking AC_CHECK_HEADERS multiple times with only one header makes for a much larger configure script than just one macro invocation for all of them. Other Autoconf macros aren't so well-done (yet). A move to shell functions will help fix that to some extent, for a much larger class of configure.ac scripts. Let's look at the execution time POV: many end users compile your package, but only on one or two systems. So for them, the answers to configure checks will always be the same. Even if they consistently make use of config.cache/config.site files, they too have to pay a bit for the overhead of "increased portability", in both time spent configuring and disk space. And then, we should not be unrealistic: large, complicated packages just won't find every test they need in stock autotools. This is fine in itself, but it does mean that the package developer may have to do portability work herself here, write macros, test, debug them. And that work sometimes does increase with the number of supported systems. This is in contrast to what Ed stated: for the tests that the autotools provides themselves, the package developer typically gets increased portability (almost) for free, without extra work. For example, AC_CHECK_HEADERS typically works even on new systems, where it's never been tried before. Or, when Libtool adds another system port, just autoreconf'ing will get you that support, without any extra work (albeit a bit larger configure script). > But I don't think this is a big problem in practice, so you > shouldn't be much afraid. It's inconvenient. No need to be afraid. ;-) > I'm not sure I succeeded in my attempt to clarify this issue. > In any case, I believe that if you want to support many platforms, > autotools are the way to go. Oh, I did not mean to argue against them. It's always good to know about limitations of a tool, though. And yes, I think the added portability is worth all the extra costs. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf