> The other day I got a copy of the latest cvs updates so I could publish a
> patch. When I did the cvs update, I got an error about configure and
> incompatibilities. I could not resolve them so I got the latest configure.
> I could not make it work
What wasn't working?
> so I moved my copy of the tree and captured a new copy
> of the tree with 'cvs -z3 checkout ethereal'. I did a configure on that
> (unchanged) copy of the tree.
That worked - what's different between the "configure" that didn't work
and the one that did:
> Now, I can see that AM_PATH_GTK is declared in aclocal.m4 (line 273 on my
> system), but why can't aclocal find it?
I don't think "aclocal" is looking for it in "aclocal.m4".
"aclocal" is what *creates* "aclocal.m4" out of "acinclude.m4" and
various libraries of autoconfigure macros.
What I'm not certain of is where "aclocal" is looking for AM_PATH_GTK; I
have vague memories of the installation of GTK doing *something* to
install its own library of autoconfig/automake stuff, but I'm not sure
what convinces "aclocal" to look there.
An unfortunate characteristic of working with a CVS-based tree is that
the mod time on stuff that's in the CVS tree *and* is derived from
other stuff in the CVS tree isn't necesarily later than the mod times on
the stuff from which it's derived, so "make" will try to rebuild that
stuff. A workaround would be to do a "touch" on "aclocal.m4" to keep
"make" from trying to rebuild it.
