Peter et al (et Al),

On Friday, August 29, 2003, at 11:15 AM, Peter W. Draper wrote:

>> (iv) Use a post-update script to finagle the timestamps
>> This is one of the solutions the automake manual suggests. The
>> GCC script they're referring to is, I think, GCC's
>> contrib/gcc_update[2]. That particular script is customised for
>> that build tree. I think we could get away with a more generic
>> one which knew what things depended on what. This feels slightly
>> dodgy, though.

> of the above only (ii) or (iv) have any appeal at all. Otherwise as an
> end
> user, just trying to quickly build this package, you're asking far too
> much of me. After all there are loads of packages I can (and have)
> just
> typed "./configure;make" without any of these issues having to enter
> the
> process.

I think (ii) is out, because forcing us all to use old versions of the
autotools is as bad as forcing us all to use new versions.

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

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.

All the best,

Norman
[going back to TimeFrame_again_]


--
----------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow [log in to unmask]