Re: Unnecessary running of configure with fatal consequences

[Joost Kraaijeveld]

Hi Ralf,

Thanks for answering so quick.

On Wed, 2008-12-03 at 21:57 +0100, Ralf Wildenhues wrote:

> 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.

Mmmmm. No tarball, just a checkout of an SVN repository. The Linux
checkout of exactly the same source does not exhibit this behaviour, but
I will look into it more closely than I have done so far.

> > 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.
Although the version (checked with --version) of the tools appear the
same, I will look into this also

> 
> - 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.
I am under the impression that these 3th party macros (which are
definitely in the original aclocal.m4 file!) do not have to distributed,
as they are included in the aclocal.m4 which renders the configure file
selfcontaining in terms of the macros , am I wrong about that?

> - 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.
This would suggest that a simple "touch aclocal.m4" after a check out
would solve the problem or am I missing something (I rather ask, because
compilation of the complete tree takes ~4 hours on my VirtualBox Windows
XP...) ?

TIA


-- 
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl