Re: Unnecessary running of configure with fatal consequences

[Ralf Wildenhues]

Hello Joost,

* Joost Kraaijeveld wrote on Wed, Dec 03, 2008 at 09:09:58PM CET:
> On linux everything works as advertised: "../configure; make" and
> everything runs/works (I do an out-of-tree build).
> 
> On Windows however, when I do a "make" after running "../configure",
> "configure" is run again as part of the "make" process.

That's the first issue.  Most likely due to messed up time stamps,
maybe due to the packing/unpacking process?  w32 file systems may have
different time stamp granularity or so.  But with a correctly packaged
tarball, I don't think this should happen.

> During that
> process (the second run of configure) it changes all the aclocal.m4,
> Makefiles.in files and the configure script in the source tree. In that
> process it loses all the non-default (?) macros that are in the
> aclocal.m4 files ( macros for wxWidgets an Boost) and the configure
> fails miserably.

This is the second issue.  It can have several reasons:
- the package requires (typically newer) autotools releases than are
available on the system.  If this is the case, then the required
versions should be annotated in configure.ac (with AC_PREREQ and
AM_INIT_AUTOMAKE), so that older versions fail reliably with exit status
63.  That will then fix the rebuild process to ignore this.

- there are third-party macros needed for regenerating files which are
either not packaged with your package, or not found by aclocal.  The
solution to the former is typically, to install them in m4/ (which can
be done with new 'aclocal --install' if AC_CONFIG_MACRO_DIR([m4]) is
used in configure.ac), the solution to the latter is to add
  ACLOCAL_AMFLAGS = -I m4
to the toplevel Makefile.am file.

- Last but not least, of course you might hit a backward compatibility
  issue in an autotool, or the package or some used macro relies on some
undocumented semantics that are not preserved across versions.

I might have forgotten to list more here.

> If I than do a revert from SVN (restore all the changed files but
> WITHOUT removing the freshly generated Makefiles in the build tree) ,
> *don't* run configure but run make immediately , it *again* starts a
> "configure" but this time it does *not* lose the macros and the build
> succeeds, be it that I have to repeat this procedure for every one of
> the 3 "sub configures".

Well, whether any or all of the files are regenerated, depends on the
relative time stamps.  If the restoration process leaves aclocal.m4 new
enough, then it will likely not be regenerated next time.  I assume it's
this part that is buggy for you.

Cheers,
Ralf