>>> [..skip..] >>> Maybe the current error should be demoted to a warning, to allow us to >>> be more forward-compatible with such possible future scenarios? >> >> I vote for this approach. >> >I'm starting to be convinced myself that it is the best one. > > But then again, mulling over the issue a little longer, I've come to realize > that autoreconf takes care of re-executing aclocal after (and if) libtoolize > is run, which makes my previous concerns about the "wrong execution order" > mostly moot, and might give a valid use case for not having an error nor a > warning if the "primary" m4 macro dir doesn't exist. > > So, what should we do in the end?
As we probably don't want to run 'aclocal --install' for the first run during 'autoreconf' (there could be unintentional file substitutions of m4 files in general, or are there other problems?), (1) I would let there warning in aclocal and (2) I would create this directory by autoreconf because this tool specifies where libtool should put .m4 files. (There is not possible to not run aclocal without '-I m4' as this is specified in Makefile.am by ACLOCAL_AMFLAGS). Eric, would you agree with this solution? Should I try to prepare patch for this? I would let the warning there just because of older autoreconfs. And for situations when user specifies bad ACLOCAL_AMFLAGS inclusions (to inform him). Pavel
