Hi Bob,
* Bob Rossi wrote on Tue, Jan 17, 2006 at 03:03:42AM CET:
> Ping. Please help.
While I personally need and like to be reminded of things sometimes,
it's really not uncommon for replies to take several days on the
autotools lists. The audience is often busy, and can afford little
time on mailing list work, so it's not a sign of ignorance if your
question isn't replied immediately.
> > In short, is there a nice way of adding the generated files into CVS and
> > not having timestamp problems with out this macro?
(a) Well, you could always just use a script `update' that does
$CVS update
if $configure_dependencies_updated; then
touch configure
..
fi
..
See gcc/contrib/gcc_update for example.
(b) Or you could require users of CVS versions to simply have all
the available tools (with sufficient versions), and not check in
any generated files. If you can also offer nightly tarball builds,
that is pretty easy to deal with in my experience.
(c) Maybe there now also exists a version control system that allows
to store relative time stamp ordering(?) requirements and reproduce them
upon checkout. I have no idea whether such a thing exists, the number
of available systems has grown much, and maybe someone has thought of
this already.
> Also, I recently learned that I had to check in the .info and .texi
> files that are generated.
That's of course nonsense as a broad statement. True is: usually .texi
files are hand-written, and .info files are generated. Iff you require
CVS users to have texinfo available, you can do without storing the
latter. Otherwise not. Nothing new.
> Would that stop the need for the --enable-maintainer-mode?
Well, AM_MAINTAINER_MODE hasn't grown ugly over night, so just because
other people advise against it now, doesn't mean it won't be useful for
you. You could avoid it with above suggestions, but you could also just
leave things as they are. You just need to keep in mind then that if
you change prerequisites to one of the generated files, a build tree
without --enable-maintainer-mode will not cause the dependencies to
_properly_ reflect those changes.
What was your original problem, by the way?
BTW, this is really an Automake question rather than an Autoconf one.
Cheers,
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
