On Sun, 31 Aug 2003, Norman Gray wrote:

> There is a possibility (v): install the autotools as third-party
> software in the repository. Though this has its attractions, I don't
> think it's necessary, since I think I have a generic solution of type
> (iv).
>
> If you check out, update, or export autoastrom now, the build sequence
> is
>
> # make sure match-0.7.tar{,.gz} is in the directory, either by
> copying it there, or
> # wget http://spiff.rit.edu/match/match-0.7.tar.gz
> ./configure
> RUN_LOCAL_AUTOTOOLS=false make
>
> (or `env RUN_LOCAL_AUTOTOOLS=false make' in csh).

Hi Norman,

OK, that got me further this time. See the attached build log for new
problems. Looks like C++ compiler issues (or may system include files)
now, so to speed this up I'll tell you the versions I'm using.

RH9 standard:

 > g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

Actually I see the same issues under RH8.

> If you actually do
> have sufficiently new autotools, then just `./configure;make' works.
> This setting changes the behaviour of the `missing' script in
> autoastrom/moggy/missing so that it never attempts to use local
> autotools to regenerate files, and acts as if there were no local
> autotools at all. It produces the warnings that the tools are missing,
> but goes ahead and updates the timestamps. This `missing' script is a
> modified version of the script which `automake --add-missing'
> generates, and is checked in. With this variable set, the make acts as
> a combination of the make plus the update-timestamp script which must
> precede it.
>
> I've tested this in a configuration where the autotools in my path are
> autoconf 2.13 and automake 1.4-p5, which I've verified do break the
> build if they are actually called.
>
> As before, I emphasise that this is necessary _only_ when building a
> CVS checkout or export. Someone building the resulting tarball needs
> only `./configure;make'.

That's reassuring to hear.

> This is also only necessary in directories which are configured using
> automake, since it is only in these directories that there is a
> Makefile in which configure has an expressed dependency on configure.ac
> (etc).
>
> If you forget to include the RUN_LOCAL_AUTOTOOLS setting and you have
> old local autotool versions, the build will possibly fail, and you may
> have garbage in the generated files. In this case, delete the
> wrongly-generated files (which will be everything newer than the CVS/
> directory, I think), do another update, and do the make again, with the
> variable set. You need to give this special make command only once,
> after you've done an update which has resulted in moggy/configure.ac or
> moggy/Makefile.am having the wrong ordering with respect to their
> generated dependencies; thereafter, just `make' will be sufficient,
> since all the timestamps will have the correct ordering.
>
> Note: there is another generated file, moggy/aclocal.m4, which I have
> not checked in to the repository. This is firstly on the general
> grounds that the fewer generated files in the repository the better,
> and secondly because I have persuaded myself (and believe I have
> tested) that, in the case we are discussing here, its contents are
> irrelevant and only its timestamp matters. That timestamp is what the
> `missing' script takes care of. If I have persuaded myself wrongly,
> the symptom will be the build persistently failing even after the
> delete-checkout-make cycle in the previous paragraph -- let me know
> about that.
>
> > (p.s. I'm unclear if this should still be the case or not, but a fresh
> > checkout still breaks the same way as yesterday).
>
> Yes, after some thought, I've decided this is obvious! Contrary to
> what I said on Friday, it's also the case in exported trees. The
> reason this isn't a problem in practice, however -- the reason you
> never have to do more than ./configure;make in unpacked tarballs -- is
> a lot less arcane than timestamp magic. The person making the
> distribution will have run `make dist' successfully in that export
> directory (or else they wouldn't have had a tarball to release), and
> that will have satisfied all of the Makefile.* and config.*
> dependencies one way or another, so the timestamp issues have all
> necessarily been resolved by the time the tarball is made.
>
> So try this, and you don't need me to tell you to tell me if it goes
> wrong.

Indeed.

> All the best,

Yup, had a few nice ones (best that is) at the Durham Beer Festival on
Friday.

Cheers,

Peter.