?

Log in

No account? Create an account
In general, when running an autoconf'd program, you should rm… - LogJam [entries|archive|friends|userinfo]
LogJam

[ website | LogJam ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Feb. 25th, 2001|06:56 pm]
LogJam
logjam
[evan]
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.
LinkReply

Comments:
[User Picture]From: corvar
2001-02-25 07:30 pm (UTC)
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.
(Reply) (Thread)
[User Picture]From: corvar
2001-02-25 08:05 pm (UTC)
I confirmed that. Checking out a clean CVS tree and doing the following gives me the error:
cvs -z3 -d:pserver:anonymous@cvs.loserjabber.sourceforge.net:/cvsroot/loserjabber co loserjabber
cd loserjabber
./autogen.sh
./configure --prefix=/usr
make

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.
(Reply) (Parent) (Thread)
From: evan
2001-02-25 10:06 pm (UTC)
Aha!
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. :)
(Reply) (Parent) (Thread)
[User Picture]From: cbj
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...

PACKAGE="classpath"
VERSION="0.02"
LIBVERSION="0:0:0"
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(LIBVERSION)
(Reply) (Thread)
From: evan
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 #defines 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?)
(Reply) (Parent) (Thread)
[User Picture]From: cbj
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.
(Reply) (Parent) (Thread)