Re: Strangeness with m4_include and aclocal.
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
[PATCH] {maint} Document in detail some limitations of aclocal. (was: Re: Strangeness with m4_include and aclocal.)
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:
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.
I've gone ahead and documented this non-obvious limitation, and another
similar one regarding AC_DEFUN. See the attached patch.
Ralf, ok to apply to maint?
Nick, the attached patch also adds your name and e-mail address to the
automake THANKS file; do you have any problem with that?
Regards,
Stefano
-*-*-*-
Document in detail some limitations of aclocal.
* doc/automake.texi (Limitations of aclocal): New section.
* tests/aclocal-limit-defun.test: New test, checking that the
aclocal limitation(s) exposed in the newly added manual section
does really hold.
* tests/aclocal-limit-include.test: Likewise.
* tests/Makefile.am (TESTS): Updated.
* .gitignore: Updated.
* THANKS: Updated.
From a report by Nick Bowler.
---
ChangeLog| 13 +
THANKS |1 +
doc/automake.texi| 95 ++
tests/.gitignore |4 +-
tests/Makefile.am|2 +
tests/Makefile.in|2 +
tests/aclocal-limit-defun.test | 83 +
tests/aclocal-limit-include.test | 88 +++
8 files changed, 286 insertions(+), 2 deletions(-)
create mode 100644 tests/aclocal-limit-defun.test
create mode 100644 tests/aclocal-limit-include.test
From 9c4a6898f2b0119fdaff7e794a2b09372a83de78 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Thu, 4 Nov 2010 20:12:59 +0100
Subject: [PATCH] Document in detail some limitations of aclocal.
* doc/automake.texi (Limitations of aclocal): New section.
* tests/aclocal-limit-defun.test: New test, checking that the
aclocal limitation(s) exposed in the newly added manual section
does really hold.
* tests/aclocal-limit-include.test: Likewise.
* tests/Makefile.am (TESTS): Updated.
* .gitignore: Updated.
* THANKS: Updated.
From a report by Nick Bowler.
---
ChangeLog| 13 +
THANKS |1 +
doc/automake.texi| 95 ++
tests/.gitignore |4 +-
tests/Makefile.am|2 +
tests/Makefile.in|2 +
tests/aclocal-limit-defun.test | 83 +
tests/aclocal-limit-include.test | 88 +++
8 files changed, 286 insertions(+), 2 deletions(-)
create mode 100644 tests/aclocal-limit-defun.test
create mode 100644 tests/aclocal-limit-include.test
diff --git a/ChangeLog b/ChangeLog
index 18c5ff6..2f4ba06 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2010-11-04 Stefano Lattarini stefano.lattar...@gmail.com
+
+ Document in detail some limitations of aclocal.
+ * doc/automake.texi (Limitations of aclocal): New section.
+ * tests/aclocal-limit-defun.test: New test, checking that the
+ aclocal limitation(s) exposed in the newly added manual section
+ does really hold.
+ * tests/aclocal-limit-include.test: Likewise.
+ * tests/Makefile.am (TESTS): Updated.
+ * .gitignore: Updated.
+ * THANKS: Updated.
+ From a report by Nick Bowler.
+
2010-11-01 Ralf Wildenhues ralf.wildenh...@gmx.de
Add FAQ entry for bug reporting instructions.
diff --git a/THANKS b/THANKS
index 78da1de..1869d14 100644
--- a/THANKS
+++ b/THANKS
@@ -240,6 +240,7 @@ Motoyuki Kasahara m-kas...@sra.co.jp
Nathanael Nerode nero...@twcny.rr.com
Nelson H. F. Beebe be...@math.utah.edu
Nicholas Wourms nwou...@netscape.net
+Nick Bowler nbow...@elliptictech.com
Nicolas Joly nj...@pasteur.fr
Nicolas Thiery nthi...@icare.mines.edu
NightStrike nightstr...@gmail.com
diff --git a/doc/automake.texi b/doc/automake.texi
index b75c7a5..ce1617f 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -188,6 +188,7 @@ Auto-generating aclocal.m4
* Extending aclocal:: Writing your own aclocal macros
* Local Macros::Organizing local macros
* Serials:: Serial lines in Autoconf macros
+* Limitations of aclocal:: Some warts and limitations of aclocal
* Future of aclocal:: aclocal's scheduled death
Autoconf macros supplied with Automake
@@ -3099,6 +3100,7 @@ overridden using the @env{AUTOM4TE} environment variable.
* Extending aclocal:: Writing your own aclocal macros
* Local Macros::Organizing local macros
* Serials:: Serial lines in Autoconf macros
+* Limitations of aclocal:: Some warts and limitations of aclocal
* Future of
Re: [PATCH] {maint} Document in detail some limitations of aclocal. (was: Re: Strangeness with m4_include and aclocal.)
On 2010-11-04 20:47 +0100, Stefano Lattarini wrote:
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:
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.
I've gone ahead and documented this non-obvious limitation, and another
similar one regarding AC_DEFUN. See the attached patch.
Ralf, ok to apply to maint?
Nick, the attached patch also adds your name and e-mail address to the
automake THANKS file; do you have any problem with that?
No problem. I have a couple comments, however:
-*-*-*-
Document in detail some limitations of aclocal.
[...]
+...@example
+## Let's see an @command{aclocal} limitation w.r.t.@: scanning
+## of macro definitons.
+$ @kbd{cat m4/foo.m4}
+# Indirection used here, to avoid triggering the bug described
+# above.
+AC_DEFUN([MY_DEFUN], [m4_apply([AC_DEFUN], [$1], [$2])])
This is insufficiently quoted, it should be:
[m4_apply([AC_DEFUN], [[$1], [$2]])]
[...]
+These limitations might be lifted in a future version of
+...@command{aclocal}, but then again, they might not, so you
+should be preperated to live with them.
^^
prepared
[...]
+++ b/tests/aclocal-limit-defun.test
[...]
+cat m4/foo.m4 'END'
+AC_DEFUN([MY_DEFUN], [m4_apply([AC_DEFUN], [$1], [$2])])
Same quoting issue as above.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
[PATCH] {maint} Document in detail some limitations of aclocal. (was: Re: Strangeness with m4_include and aclocal.)
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:
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.
I've gone ahead and documented this non-obvious limitation, and another
similar one regarding AC_DEFUN. See the attached patch.
Ralf, ok to apply to maint?
Nick, the attached patch also adds your name and e-mail address to the
automake THANKS file; do you have any problem with that?
Regards,
Stefano
-*-*-*-
Document in detail some limitations of aclocal.
* doc/automake.texi (Limitations of aclocal): New section.
* tests/aclocal-limit-defun.test: New test, checking that the
aclocal limitation(s) exposed in the newly added manual section
does really hold.
* tests/aclocal-limit-include.test: Likewise.
* tests/Makefile.am (TESTS): Updated.
* .gitignore: Updated.
* THANKS: Updated.
From a report by Nick Bowler.
---
ChangeLog| 13 +
THANKS |1 +
doc/automake.texi| 95 ++
tests/.gitignore |4 +-
tests/Makefile.am|2 +
tests/Makefile.in|2 +
tests/aclocal-limit-defun.test | 83 +
tests/aclocal-limit-include.test | 88 +++
8 files changed, 286 insertions(+), 2 deletions(-)
create mode 100644 tests/aclocal-limit-defun.test
create mode 100644 tests/aclocal-limit-include.test
From 9c4a6898f2b0119fdaff7e794a2b09372a83de78 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Thu, 4 Nov 2010 20:12:59 +0100
Subject: [PATCH] Document in detail some limitations of aclocal.
* doc/automake.texi (Limitations of aclocal): New section.
* tests/aclocal-limit-defun.test: New test, checking that the
aclocal limitation(s) exposed in the newly added manual section
does really hold.
* tests/aclocal-limit-include.test: Likewise.
* tests/Makefile.am (TESTS): Updated.
* .gitignore: Updated.
* THANKS: Updated.
From a report by Nick Bowler.
---
ChangeLog| 13 +
THANKS |1 +
doc/automake.texi| 95 ++
tests/.gitignore |4 +-
tests/Makefile.am|2 +
tests/Makefile.in|2 +
tests/aclocal-limit-defun.test | 83 +
tests/aclocal-limit-include.test | 88 +++
8 files changed, 286 insertions(+), 2 deletions(-)
create mode 100644 tests/aclocal-limit-defun.test
create mode 100644 tests/aclocal-limit-include.test
diff --git a/ChangeLog b/ChangeLog
index 18c5ff6..2f4ba06 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2010-11-04 Stefano Lattarini stefano.lattar...@gmail.com
+
+ Document in detail some limitations of aclocal.
+ * doc/automake.texi (Limitations of aclocal): New section.
+ * tests/aclocal-limit-defun.test: New test, checking that the
+ aclocal limitation(s) exposed in the newly added manual section
+ does really hold.
+ * tests/aclocal-limit-include.test: Likewise.
+ * tests/Makefile.am (TESTS): Updated.
+ * .gitignore: Updated.
+ * THANKS: Updated.
+ From a report by Nick Bowler.
+
2010-11-01 Ralf Wildenhues ralf.wildenh...@gmx.de
Add FAQ entry for bug reporting instructions.
diff --git a/THANKS b/THANKS
index 78da1de..1869d14 100644
--- a/THANKS
+++ b/THANKS
@@ -240,6 +240,7 @@ Motoyuki Kasahara m-kas...@sra.co.jp
Nathanael Nerode nero...@twcny.rr.com
Nelson H. F. Beebe be...@math.utah.edu
Nicholas Wourms nwou...@netscape.net
+Nick Bowler nbow...@elliptictech.com
Nicolas Joly nj...@pasteur.fr
Nicolas Thiery nthi...@icare.mines.edu
NightStrike nightstr...@gmail.com
diff --git a/doc/automake.texi b/doc/automake.texi
index b75c7a5..ce1617f 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -188,6 +188,7 @@ Auto-generating aclocal.m4
* Extending aclocal:: Writing your own aclocal macros
* Local Macros::Organizing local macros
* Serials:: Serial lines in Autoconf macros
+* Limitations of aclocal:: Some warts and limitations of aclocal
* Future of aclocal:: aclocal's scheduled death
Autoconf macros supplied with Automake
@@ -3099,6 +3100,7 @@ overridden using the @env{AUTOM4TE} environment variable.
* Extending aclocal:: Writing your own aclocal macros
* Local Macros::Organizing local macros
* Serials:: Serial lines in Autoconf macros
+* Limitations of aclocal:: Some warts and limitations of aclocal
* Future of
Re: [PATCH] {maint} Document in detail some limitations of aclocal. (was: Re: Strangeness with m4_include and aclocal.)
On 2010-11-04 20:47 +0100, Stefano Lattarini wrote:
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:
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.
I've gone ahead and documented this non-obvious limitation, and another
similar one regarding AC_DEFUN. See the attached patch.
Ralf, ok to apply to maint?
Nick, the attached patch also adds your name and e-mail address to the
automake THANKS file; do you have any problem with that?
No problem. I have a couple comments, however:
-*-*-*-
Document in detail some limitations of aclocal.
[...]
+...@example
+## Let's see an @command{aclocal} limitation w.r.t.@: scanning
+## of macro definitons.
+$ @kbd{cat m4/foo.m4}
+# Indirection used here, to avoid triggering the bug described
+# above.
+AC_DEFUN([MY_DEFUN], [m4_apply([AC_DEFUN], [$1], [$2])])
This is insufficiently quoted, it should be:
[m4_apply([AC_DEFUN], [[$1], [$2]])]
[...]
+These limitations might be lifted in a future version of
+...@command{aclocal}, but then again, they might not, so you
+should be preperated to live with them.
^^
prepared
[...]
+++ b/tests/aclocal-limit-defun.test
[...]
+cat m4/foo.m4 'END'
+AC_DEFUN([MY_DEFUN], [m4_apply([AC_DEFUN], [$1], [$2])])
Same quoting issue as above.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: Strangeness with m4_include and aclocal.
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. I haven't tested this, but I suspect it also means that my workaround isn't going to cut it in the general case where foo.m4 uses or defines macros that aclocal needs to find. Exactly. And this too should be documented IMO. Nevertheless, if both aclocal and automake agreed on when to update aclocal.m4, then the workaround _would_ solve my specific problem. As a side note, adding a new make variable (say `ACLOCAL_M4_DEPENDENCIES') to let the user specify extra dependencies for aclocal.m4 could be helpful for cases like yours. Something similar is already done for `configure' and `config.status' dependecies with respectively the make variables `CONFIGURE_DEPENDENCIES' and `CONFIG_STATUS_DEPENDENCIES'. Thanks for your time on this matter, And thanks for the time you spent reporting the problem and helping me to understand it. Regards, Stefano
Re: Strangeness with m4_include and aclocal.
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. 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. 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. 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. I haven't tested this, but I suspect it also means that my workaround isn't going to cut it in the general case where foo.m4 uses or defines macros that aclocal needs to find. Nevertheless, if both aclocal and automake agreed on when to update aclocal.m4, then the workaround _would_ solve my specific problem. Thanks for your time on this matter, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: Strangeness with m4_include and aclocal.
On Friday 22 October 2010, Nick Bowler wrote:
On 2010-10-22 20:43 +0200, Stefano Lattarini wrote:
May I ask you that, the next time you report a problem, you also tell which
version of aclocal/automake are you using, and post the content of all the
relevant files (or reduced exemples thereof)? That would make it easier
for us to understand and reproduce the reported issues. Thanks.
Will do.
Thanks, much appreciated.
Using aclocal-1.11.1 and automake-1.11.1. Here's the
configure.ac, with the MY_INC stuff commented out:
AC_INIT([test], [1.0])
AM_INIT_AUTOMAKE([foreign])
dnl AC_DEFUN([MY_INC], [m4_include([$1])])
dnl MY_INC([foo.m4])
AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
MY_INC2([foo.m4])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Makefile.am and foo.m4 are empty files.
OK, similar enough to what I had hypothesized. So far, so good.
AC_DEFUN([MY_INC], [m4_include([$1])])
[...]
aclocal: error: configure.ac:1: file `$1' does not exist
I currently have no idea of why this is happening
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).
My explanation seems to be confirmed by the fact that substituting:
AC_DEFUN([MY_INC], [m4_include([$1])])
with the equivalent (on m4 level at least):
AC_DEFUN([MY_INC], [m4_][include([$1])])
makes the error above disappear.
Also, it explaines this other problem noticed by you:
On another note: the following also fails in configure.ac:
m4_ignore([m4_include([a_file_that_does_not_exist.m4])])
% autoreconf
aclocal: error: configure.ac:4: file `a_file_that_does_not_exist.m4' does
not exist
This error too disappers when one uses e.g.:
m4_ignore([m4_][include([a_file_that_does_not_exist.m4])])
instead.
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.
(but luckily you have a workaround, so this should not be such a big
problem for you ATM).
Well, the workaround just replaces one problem (aclocal spits an error)
with another (make tries to rebuild aclocal.m4 needlessly). Not really
perfect.
Hmm... I thought that git automake solved the second problem (needless
rebuilding of aclocal.m4), but you tell me it does not. So let's see...
So I tried to avoid this by being a little trickier:
AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
Now aclocal works properly, but the makefiles generated by automake do
not: if the m4_included file is newer than aclocal.m4, 'make' will
attempt to regenerate aclocal.m4 by calling aclocal. Since aclocal.m4
isn't actually out of date, aclocal does nothing and aclocal.m4 isn't
updated. Thus, every 'make' invocation will run aclocal needlessly.
I can reproduce and confirm this problem with Automake 1.11, but luckily
it *seems* to have been fixed in developement version from git master
branch, probably with commit `v1.11-17-g333c18a' by Ralf Wildenhues.
I just tried with git master, it still seems to be present.
I re-tried, and now I *can* reliably reproduce the bug. I probably messed
up something in my previous attempt. Sorry for the noise, and thanks for
persisting.
This is with the above configure.ac (commands prefixed with %, some
output redacted):
% automake --version
automake (GNU automake) 1.11a
[...]
% autoreconf -fi
[...]
% ./configure
[...]
% make
make: Nothing to be done for `all'.
% touch foo.m4
% make
[...]
% make
CDPATH=${ZSH_VERSION+.}: cd . /bin/sh /scratch_space/actest/missing
--run aclocal-1.11a
make: Nothing to be done for `all'.
% make
CDPATH=${ZSH_VERSION+.}: cd . /bin/sh /scratch_space/actest/missing
--run aclocal-1.11a
make: Nothing to be done for `all'.
% touch aclocal.m4 configure config.status Makefile Makefile.in
% make
make: Nothing to be done for `all'.
I'm out of time right now, but maybe tomorrow I might be able to check
that it really was that commit that fixed that problem; and if it is so,
your report might become a nice testsuite addition, ensuring that we do
not regress again in this matter.
[...]
The failure in your second example was probably due to timestamp issues
(I'd classify it as a minor bug in automake). I still have no idea why
your first example fails; I might try to dig deeper in the next days (if
nobody beats me ;-).
The Makefile has the dependency:
am__aclocal_m4_deps = $(top_srcdir)/foo.m4 $(top_srcdir)/configure.ac
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
Re: Strangeness with m4_include and aclocal.
On 2010-10-22 20:43 +0200, Stefano Lattarini wrote:
May I ask you that, the next time you report a problem, you also tell which
version of aclocal/automake are you using, and post the content of all the
relevant files (or reduced exemples thereof)? That would make it easier
for us to understand and reproduce the reported issues. Thanks.
Will do. Using aclocal-1.11.1 and automake-1.11.1. Here's the
configure.ac, with the MY_INC stuff commented out:
AC_INIT([test], [1.0])
AM_INIT_AUTOMAKE([foreign])
dnl AC_DEFUN([MY_INC], [m4_include([$1])])
dnl MY_INC([foo.m4])
AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
MY_INC2([foo.m4])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Makefile.am and foo.m4 are empty files.
AC_DEFUN([MY_INC], [m4_include([$1])])
[...]
aclocal: error: configure.ac:1: file `$1' does not exist
I currently have no idea of why this is happening (but luckily you have
a workaround, so this should not be such a big problem for you ATM).
Well, the workaround just replaces one problem (aclocal spits an error)
with another (make tries to rebuild aclocal.m4 needlessly). Not really
perfect.
So I tried to avoid this by being a little trickier:
AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
Now aclocal works properly, but the makefiles generated by automake do
not: if the m4_included file is newer than aclocal.m4, 'make' will
attempt to regenerate aclocal.m4 by calling aclocal. Since aclocal.m4
isn't actually out of date, aclocal does nothing and aclocal.m4 isn't
updated. Thus, every 'make' invocation will run aclocal needlessly.
I can reproduce and confirm this problem with Automake 1.11, but luckily
it *seems* to have been fixed in developement version from git master
branch, probably with commit `v1.11-17-g333c18a' by Ralf Wildenhues.
I just tried with git master, it still seems to be present. This is
with the above configure.ac (commands prefixed with %, some output
redacted):
% automake --version
automake (GNU automake) 1.11a
[...]
% autoreconf -fi
[...]
% ./configure
[...]
% make
make: Nothing to be done for `all'.
% touch foo.m4
% make
[...]
% make
CDPATH=${ZSH_VERSION+.}: cd . /bin/sh /scratch_space/actest/missing
--run aclocal-1.11a
make: Nothing to be done for `all'.
% make
CDPATH=${ZSH_VERSION+.}: cd . /bin/sh /scratch_space/actest/missing
--run aclocal-1.11a
make: Nothing to be done for `all'.
% touch aclocal.m4 configure config.status Makefile Makefile.in
% make
make: Nothing to be done for `all'.
I'm out of time right now, but maybe tomorrow I might be able to check
that it really was that commit that fixed that problem; and if it is so,
your report might become a nice testsuite addition, ensuring that we do
not regress again in this matter.
[...]
The failure in your second example was probably due to timestamp issues
(I'd classify it as a minor bug in automake). I still have no idea why
your first example fails; I might try to dig deeper in the next days (if
nobody beats me ;-).
The Makefile has the dependency:
am__aclocal_m4_deps = $(top_srcdir)/foo.m4 $(top_srcdir)/configure.ac
so it believes that aclocal.m4 is out of date when foo.m4 is updated.
However, the aclocal program itself decides not to update aclocal.m4
when 'make' runs it.
On another note: the following also fails in configure.ac:
m4_ignore([m4_include([a_file_that_does_not_exist.m4])])
% autoreconf
aclocal: error: configure.ac:4: file `a_file_that_does_not_exist.m4' does not
exist
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Strangeness with m4_include and aclocal.
I'm trying to define an autoconf macro which calls m4_include on one of its arguments. However, aclocal and/or automake seem to be choking a bit when I do this. My first idea was to write something simple like the following: AC_DEFUN([MY_INC], [m4_include([$1])]) but this causes aclocal to fail with the following error message: aclocal-1.11: configure.ac:5: file `$1' does not exist Strange. So I tried to avoid this by being a little trickier: AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])]) Now aclocal works properly, but the makefiles generated by automake do not: if the m4_included file is newer than aclocal.m4, 'make' will attempt to regenerate aclocal.m4 by calling aclocal. Since aclocal.m4 isn't actually out of date, aclocal does nothing and aclocal.m4 isn't updated. Thus, every 'make' invocation will run aclocal needlessly. 'make dist' correctly picks up the m4_included file in either case. What's going on here? -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
