||[Feb. 25th, 2001|06:56 pm]
In general, when running an autoconf'd program, you should rm config.cache when running ./configure again with new settings.|
I suspected that this is what has been causing problems with VERSION being undefined, so I added an "rm -f config.cache" to autogen.sh a few commits back.
If someone knows of a "proper" way to do this, I'd be grateful... though I don't expect there to be one.
Unless config.cache is part of the cvs repository (which it shouldn't be), that isn't the problem. Because I now delete the existing cvs checkout and download a fresh one.
I confirmed that. Checking out a clean CVS tree and doing the following gives me the error:
cvs -z3 -d:pserver:firstname.lastname@example.org:/cvsroot/loserjabber co loserjabber
I verified that there was no config.cache in the clean checkout, and no config.cache previous to the configure.
Same error, running autogen.sh and configure again takes care of it.
2001-02-25 10:06 pm (UTC)
autoheader apparently works *slightly* differently before and after aclocal is run. autoheader generates config.h.in after *supposedly* parsing configure.in, but it apparently parses some other files that are generated by one of (aclocal autoconf automake) and generates config.h. The VERSION macro is defined in that file, and its absence breaks the build.
In summary, the first time you checkout, the order of running everything is not quite right.
I removed the call to autoheader in autogen.sh, and I'll just keep config.h.in up-to-date in the CVS version.
Bleh. Thanks for the debugging help. :)
2001-02-25 10:05 pm (UTC)
Really should probably look at what you're doing before posting, but what the hell! I'll assume that autogen.sh is doing 'aclocal;autoheader;automake;autoconf'? If you AC_DEFINE anything... then config.cache holds onto that value in a special variable which you are supposed to recheck in case the system has changed since configure first ran. There are other ways things get into config.cache... but again you can use the variable specified therein in configure to avoid problems.
Here is what I typically do with VERSION, as in GNU Classpath... these names can be used in Makefile files. From configure.in...
2001-02-25 10:57 pm (UTC)
The automake way to do this, as I understand it, is:AM_INIT_AUTOMAKE(somepackage, myversion)
And that sets the PACKAGE
and VERSION #define
s in config.h
I think I figured it out anyway, though.
(You work on classpath? That's a pretty serious project. How'd you get hosted on gnu.org?)
2001-02-26 07:52 pm (UTC)
My roommate during part of college, Paul Fisher, set it up. There is an evaluation team (or will be) that helps RMS decide whether or not to accept (sponsor) a project. Help GNU
should get you started.