2008/7/28, Tor Arntsen wrote:

> It looks like the m4 version (1.4.5) is actually to blame for the
> Solaris build problem. Even though I installed a newer version
> (1.4.11) in /usr/local/bin and adjusted the PATH accordingly (and the
> build script detected and reported that version), the installed
> autom4te program had /opt/csw/bin/gm4 hardcoded (the 1.4.5 version),
> unless an M4 environment variable is set to override it.

Amazing :-O

The 'real thing' behind all the auto* tools and derived software is m4.

> I'm running a local autobuild right now which seems to be going
> through. The question is what to do with that - is there a real
> problem with the "official" Blastwave.org gm4 and/or gm4 1.4.5?
> Or is it us?

One thing is real for sure, since we had never used an additional .m4
file with package-local macros, we had never exercised the automake
code related with "aclocal -I m4" neither that of makefiles related
with "ACLOCAL_AMFLAGS = -I m4".

It is also true, that with that file we increase the number of macros
used so far. With this increased number of macros we might be hitting
some limit, but I don't know.

I think that besides the "aclocal -I m4" call in buildconf and the
"ACLOCAL_AMFLAGS = -I m4". line in Makefile.am there is nothing
missing to be able to use whatever number of m4 files we wanted in the
m4 subdirectory. But I could be missing something.

You could make a couple of tests to pinpoint this further.

With the gm4 1.4.5 in place and with a just checked out curl CVS tree run:

cat ares/m4/reentrant.m4 >> ares/acinclude.m4
cat m4/reentrant.m4 >> acinclude.m4
rm ares/m4/reentrant.m4
rm m4/reentrant.m4
./buildconf

If this still fails then, additionally run

sed 's/-I m4//' buildconf > buildconf.new
mv buildconf.new buildconf
sed 's/ACLOCAL_AMFLAGS = -I m4//' Makefile.am > Makefile.am.new
mv Makefile.am.new Makefile.am
sed 's/-I m4//' ares/buildconf > ares/buildconf.new
mv ares/buildconf.new ares/buildconf
sed 's/ACLOCAL_AMFLAGS = -I m4//' ares/Makefile.am > ares/Makefile.am.new
mv Makefile.am.new Makefile.am
./buildconf

At least this should give us further info about if the problem is
triggered with the new macros or with the inclusion of the
subdirectory.

-- 
-=[Yang]=-