Re: configure -C by default?

[Steffen Dettmer]

In short:
I think, no cache loading from manual explicite configure run
(but for sub-packages and make-triggered), keeping it as it is.

By this, if in doubt, by re-running all build tools, chances are
best to get a correct result. Performance tuning for the price of
correctness isn't always a good trade-off I think.

Just in case I write about some experiences below.

On Sun, Feb 6, 2011 at 11:11 PM, <address@hidden> wrote:
> Apparently, a lot of users do not even know about configure -C aka.
> --config-cache which of course doesn't help Autoconf's reputation about
> producing configure scripts which are slow even for development.

I think the first question is: what feels slow?
What is multi-platform-toolchain-language-single-srcdir-crosscompiling faster?

For us often configure runs are triggered by increasing package
version numbers, leading to updated config.h and to compiling
everthing (probably this could be improved by using autoconf
better?).

Often caching system properties might be good for developers
as long as remembering to clean the cache as soon as the system
was updated. An automatism would be helpful, if possible.

However, there is just one cache. We also use some code in
configure.ac to get information about our own (sub-)packages. We
have open issues where the cache renders this useless, because if
a subpackage is updated it won't be detected. Hacks like touch
configure.ac in Makefile failed, however behavior probably could
be avoided by setting the cache variables in the "exporting"
package I guess (would this be considered an implementation or a
hack?).

On cygwin, IMHO, configure -C slow. Make is slow, echo is slow,
everything is slow... :) Caching IMHO really saves a lot of time
here (but we use it for subpackages only). As we don't have much
cygwin-specific code, in most cases we develop on linux. I don't
know whether crosscompiling (build=linux, host=cygwin) is
possible.
Of course, the great thing about cygwin is that is usually works
and "feels like a unix". Really cool. You can even select(2)
serial ports.

A great think about autoconf is that basically any needed
exception may be added in configure.ac, could be the most strange
thing (like "but do not use XYZ if cygwin version = 1.2.3 and
expat is installed", having a special tool version installed or
whatever). In the past we had issues with "stale" caches.

MSYS seems to be much faster as cygwin, but more troublesome.
I think it is nice to cross-compile with gcc-mingw on a linux
box, test via WINE (BTW, can "make check" be made working? Recent
linux distributions sometimes support starting .EXE files by
automatically starting WINE).

On linux when compiling native code, I only know about problems
with stale caches about own (sub-)packages (which, as written
above, probably are due to wrong usage of caching).

On linux, when cross-compiling, we have all sorts of issues with
"stale caches". Here most developers are used to manually re-run
topdir/configure to get it clean. I think it would be unexpected
that this would use some cache. It was called to configure, not
to assume - in contrast to maybe a make-triggered configure,
which might be supposed to be faster for the price of less correct.

> So one question would be what about making -C the default?
> We could have --force or --no-cache to turn it off.

When a user runs "configure" I think no cache should be loaded.
When configure runs subpkg/configure, I think a cache is good.
When make runs configure, I think a cache is good, too.

> Back then, the consensus was to not make it the default because that was
> deemed too dangerous for users.

I think this is still true (even more, because common linux users
may read even less instructions than ten years ago).
Here many developers don't care about the build process and they
also don't use a "persistent cache" (in constrast to
"subpackge-caching", which is used). So even developers don't
use "make distclean".

oki,

Steffen