On Thursday 28 October 2010, Stefano Lattarini wrote: > On Wednesday 27 October 2010, Nick Bowler wrote: > > On 2010-10-23 15:23 +0200, Stefano Lattarini wrote: > > > Now I do. This happens because `aclocal', to find the includes in an > > > input file, *grep* the file's content, looking for literal `m4_include' > > > (and similar), without analyzing m4 traces (not sure why aclocal acts > > > this way, but I suspect there is a good reason behind this behaviour). > > > > So it seems that there is a strange dichotomy between automake and > > aclocal: automake apparently uses the traces to figure out the aclocal > > dependencies (also for 'make dist'), but aclocal _doesn't_ use the > > traces to actually do things. > Well, if you consider what aclocal has to accomplish, it's pretty clear > it has (partly at least) to work by grepping rather than tracing. The > real problem here, as you pointed out, is the dichotomy between automake > and aclocal w.r.t. the calculation of aclocal.m4 dependencies. > > > > So I think your first problem is "just" an aclocal limitation we should > > > resign to live with. But I also think that such a limitation should be > > > documented explicitly, since it's by no means obvious. > > > > It's especially non-obvious because the other autotools handle this just > > fine. > Agreed. > > > > > so it believes that aclocal.m4 is out of date when foo.m4 is updated. > > > > > > And this is right, because configure.ac includes foo.m4, and since > > > aclocal.m4 depends on all the content of configure.ac, *also the parts > > > m4_included from other files*, aclocal.m4 must be considered out-of-date > > > when it's older than foo.m4. What is wrong is that aclocal fails to > > > update the aclocal.m4 timestamp, so that the rules to rebuild it are > > > uselessly called over and over ... > > > > Ah right. Foo.m4 might call AC_DEFUN or another macro defined in > > this way, and aclocal needs to know about these things. > True (well, sort of). For example, with the following setup: > > $ cat configure.ac > AC_INIT([test], [1.0]) > FOO > $ cat m4/bar.m4 > AC_DEFUN([MY_INC], [m4_][include([$1])]) > $ cat m4/baz.m4 > MY_INC([m4-extra/foo.m4]) > $ cat m4-extra/foo.m4 > AC_DEFUN([FOO], [BAR]) > > we'll have: > > $ aclocal -I m4 && autoconf > $ sed -n '$p' configure > FOO > > which suggests that the inclusion of `m4-extra/foo.m4' wasn't seen > and processed by aclocal; but changhing the setup so that: > > $ cat m4/baz.m4 > m4_include([m4-extra/foo.m4]) > > we'll have: > > $ aclocal -I m4 && autoconf > $ sed -n '$p' configure > BAR > > as expected. > > > In my instance, foo.m4 _doesn't_ do either of these things so I didn't > > notice this. If I'm understanding correctly, then, aclocal _isn't_ > > going to find this information from foo.m4 because it doesn't _know_ > > about foo.m4. > Yes, in the general case this is a possibility (see example above).
> I'm starting to think that it would be aclocal's duty to inform automake > about the dependencies it (aclocal) has been able to figure out, so that > automake can emit make rules and dependencies that agrees with aclocal's > idea of dependencies. This might be quite easy to implement, but before > giving it a try I'd like to hear Ralf opinion on the matter. > Ping on this? Reference to original thread: <http://lists.gnu.org/archive/html/automake/2010-10/msg00036.html> Regards, Stefano
