|
Peter,
On Thu, 28 Aug 2003, Peter W. Draper wrote:
> On Thu, 28 Aug 2003, Norman Gray wrote:
>
> > That's not the point right now -- ASTROM and autoastrom are not in CVS,
> > and build with ./configure;make straight out of the box, and `./mk' and
> > `./mk build' are just shorthands for that.
> >
>
> Hi Norman,
>
> still doesn't build I'm afraid. See the attached file.
OooooKayyyy. This is tricky, and I think I now understand the
generated-files problem much more clearly than I did.
The fundamental problem is this: if a file is touched, or regenerated
with identical content, then although its timestamp is updated, CVS
does _not_ regard it as having changed, so it does _not_ offer to
commit it, thus the timestamp in the _repository_ hasn't changed, and
so the file's time when someone next does an update isn't changed
either.
Thus I've just now made a trivial edit of moggy/configure.ac, and
regenerated moggy/config.h.in, which depends on moggy/configure.ac.
In my working directory, I have
... Aug 28 17:25 config.h.in
... Aug 28 17:24 configure.ac
but in cvs.starlink.ac.uk:/cvs/applications/autoastrom/moggy/,
... Aug 27 17:50 configure.ac,v
... Aug 25 13:58 config.h.in,v
because I haven't committed the configure.ac yet. If, however, I do
`cvs status' on configure.ac and config.h.in, I'm told that configure.ac
is locally modified (true), but that config.h.in is _up-to-date_ (true,
sort of, but unfortunate, for this purpose). Thus if you were to do
an update after I commit this, then your configure.ac and config.h.in
would have the correct contents, but config.h.in would have an earlier
timestamp than configure.ac, making make think that it needs regenerating.
This is the meaning of the apparently innocuous remark in the automake
documentation (well, innocuous to me -- perhaps everyone else appreciated
its significance immediately)[1]:
If users use cvs update to update their copy, instead of cvs checkout
to fetch a fresh one, timestamps will be inaccurate. Some rebuild
rules will be triggered and attempt to run developer tools such as
autoconf or automake.
So far so straightforward.
This is such a clear problem that one of the auxiliary files that you
get with an automake package is `missing'. When automake and autoconf
are invoked to regenerate files such as config.h.in, or Makefile.in from
Makefile.am, that is done via `missing':
cd . && /bin/sh /loc/pwda/pdraper/cvs/autoastrom/moggy/missing --run aclocal-1.7
/loc/pwda/pdraper/cvs/autoastrom/moggy/missing: line 46: aclocal-1.7: command not found
WARNING: `aclocal-1.7' is missing on your system. You should only need it if
you modified `acinclude.m4' or `configure.ac'. You might want
to install the `Automake' and `Perl' packages. Grab them from
any GNU archive site.
You don't have aclocal-1.7, so `missing' says you probably don't need it,
and updates the timestamp on the file it thought it had to regenerate
(but didn't, and couldn't). That's ok, and the build can now carry
on as if nothing had happened (is the plan). It does the same with
automake-1.7, but when it thinks that it has to regenerate configure from
configure.ac (not sure why, since configure's newer than configure.ac in
the repository), it attempts to run `autoconf', rather than a specific
autoconf version, and since you _do_ have a version of autoconf available,
it does run it, but barfs on the AM_INIT_AUTOMAKE macro, which is specific
to a recent version of _automake_, and so isn't one of the m4 macros which
your autoconf (which is the same version as mine, I recall) knows about.
In other words, the `missing' mechanism works if you have a recent
version of the autotools or _no_ version, but not, or not completely,
otherwise.
All this did work with me, even though I carefully didn't have the
recent autotools in my path -- only the ancient RH7.3 tools -- because
my generated files were genuinely newer than their sources, and so
missing wasn't invoked. My generated files were newer because I
tested this in a freshly checked out copy of the module, rather than
an updated working copy, and that meant that the timestamps
corresponded with the actual state of the files.
So? What?
(i) Force all of us to use the current versions of the autotools?
No. Even though I better understand the problems with the check-em-in
school, the keep-em-out problems still sound worse.
(ii) Revert to old versions?
I could possibly alter the moggy things so that I wasn't using the
AM_INIT_AUTOMAKE macro in the configure.ac, so that the result was
processable by older versions of autotools. But that's daft -- I
don't know what effect that would have on the configuration, and
even if it did still work now, there's no guarantee that thing
would continue to work in future. Also, this isn't really solving
the general problem, merely evading it in this case. So no, I
think.
(iii) Make sure we remove system autotools from our paths
Though it might be a fuss, initially, this might be most reliable.
They're in /usr/bin, so this would involve deinstalling the autoconf,
automake and libtool RPMs, and either installing them elsewhere,
if they're relocatable, or just building and installing them by
hand in a non-default place (what I've done). If there are _no_
autotools in the path, then the `missing' script can do its work
successfully, and this problem disappears.
(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.
I think that (iii) is possibly the best plan, followed by (iv). Any
other suggestions?
See you,
Norman
[1] http://sources.redhat.com/automake/automake.html#CVS again
[2] http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/contrib/gcc_update
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|
