2009/9/29, Daniel Stenberg wrote: > Weird. It's quite unclear to me how _any_ files in the m4 subdirectory end > up in the tarball. It seems that's some kind of default or possibly the > ACLOCAL_AMFLAGS variable triggers it.
Its the 'aclocal -I m4'. 'aclocal -I m4' will make that any *.m4 file in the m4 subdirectory with a function/macro directly or indirectly referenced from configure.ac will be included in the resulting aclocal.m4 file. Later on 'automake' creates for the 'configure file' dependencies for the above referenced *.m4 files in 'Makefile.in', and all configure's dependencies get automatically placed in DIST_COMMON making all this the magic to include such files in the distribution archive. So, if for any reason the 5 libtool files are present in the m4 subdirectory when 'aclocal -I m4' runs they will get later pulled into the distribution tarball. Until next week I have no access to a libtool 2.2.X installation, but if my memory doesn't fail those 5 files are copied into the m4 subdirectory when a 2.2.X libtoolize runs. This is good for the distributed configure script generated from these files. But as soon as those 5 files are incompatible with the installed libtool version and buildconf runs problems will arise due to intermixed libtool macros. Since buildconf will only be used on systems that have the full auto-tool chain installed I think that the least intrusive way to avoid mixing libtool versions is to simply let buildconf search these 5 files in the libssh2 tree and remove them before running libtoolize. Other libtool related files might also need removal, hmm. I'll make some tests with the libtool 2.2.X installation next week, and report back. -- -=[Yang]=- _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
