Re: autoconf: Does it meet these cross-platform goals?

[Ralf Wildenhues]

* 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