- Package:
- automake
- Source:
- automake-1.16
- Submitter:
- Michael Biebl
- Date:
- 2010-03-13 19:42:14 UTC
- Severity:
- normal
Hi, I followed the advise from libtoolize and added `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and `-I m4' to ACLOCAL_AMFLAGS in Makefile.am When I now run "autoreconf -vfi" from a fresh git checkout, where the (empty) m4/ directory does not yet exist, I get a failure: autoreconf -vfi autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 aclocal: couldn't open directory `m4': No such file or directory autoreconf: aclocal failed with exit status: 1 I suggest that either autoreconf or aclocal should create that directory, before any of the tools tries to copy it's macro files there. If you rather think this is a bug in aclocal (I use automake 1.11), feel free to reassign. Cheers, Michael
Michael Biebl <biebl@debian.org> writes: Hi Michael. It's hard for me to see exactly why any of the tools should create this directory. It seems to me that, if you want files to be put in a particular source directory, it's reasonable for the tools to assume that you have already created that directory. Can you explain why you think this is a bug?
Ben Pfaff wrote: Hi Ben libtoolize already does it that way. It seems to me that, if you want files to Principle of least surprise. If the tools can create the directory itself and not fail, why should they not do it? It would also be consistent with what libtoolize is already doing. Third, and this is more a limitation of Git, you can't put empty directories in Git (unless you resort to imho ugly workarounds like putting empty . files in a m4/ directory). So it is up to everyone checking out a Git repository, to create the m4/ on their own. That is imo just inconvenient. People seeing that error message probably don't immediately know, what that error message means and can easily be solved by simply creating a m4/ directory. Cheers, Michael
Michael Biebl <biebl@debian.org> writes: [...] autoreconf runs libtoolize first, so I guess this is for packages that do not use libtool then? To me, it seems like it would be reasonable for aclocal to create the "m4" directory if it is being asked to copy files into it, that is, if aclocal is being invoked with --install. But autoreconf as far as I can tell never invokes aclocal with --install, so this would not help. Actually, I am now a little confused. If your package does not have any of its own M4 files in m4/, and it does not use libtoolize, and it does not expect --install to be used with aclocal, then where are the files in m4/ eventually coming from? Perhaps I just misunderstand (sometimes the autotools still catch me by surprise after many years). Actually, it is a little unusual that aclocal complains about nonexistent macro search directories at all. Most Unix software does not complain about nonexistent directories in search paths (e.g. $PATH and "cc -I"). Perhaps we should find out why aclocal is different.
Hi Michael. I didn't see a reply to my most recent email on this bug, from about two weeks ago, which is archived at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663#20 Does that mean that you don't believe any longer that this is a bug, or simply that you have not had time to reply yet. Thanks, Ben.
If you want to reproduce the problem, try $ git clone git://anongit.gnome.org/git/tracker $ cd tracker $ rm -rf m4 (I added that directory to Git to avoid the described failure) $ autoreconf -vfi autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 aclocal: couldn't open directory `m4': No such file or directory autoreconf: aclocal failed with exit status: 1 Although the project uses libtool, libtoolize is not invoked first. So, I'd say, if "aclocal --force -I m4" wants to access m4/ it should create the directory if not existent. Cheers, Michael
Michael Biebl <biebl@debian.org> writes: Thank you for the additional information. You still did not provide a direct answer to my questions from the cited email. Could you do that? Here they are again: To me, it seems like it would be reasonable for aclocal to create the "m4" directory if it is being asked to copy files into it, that is, if aclocal is being invoked with --install. But autoreconf as far as I can tell never invokes aclocal with --install, so this would not help. Actually, I am now a little confused. If your package does not have any of its own M4 files in m4/, and it does not use libtoolize, and it does not expect --install to be used with aclocal, then where are the files in m4/ eventually coming from? Perhaps I just misunderstand (sometimes the autotools still catch me by surprise after many years).
If m4 does not exist at the time aclocal is run and --install is not given, maybe aclocal should simply issue a warning and proceed? Simply failing at this point is counterintuitive imho. I do use libtool, but libtoolize is run *after* acloclal. Cheers, Michael
Michael Biebl <biebl@debian.org> writes: Ah. All the pieces have come together for me. I understand now. I will see what I can do.
The process for bootstrapping some software from a version control system
checkout involves running aclocal before the m4 directory exists, then
populating the m4 directory and running aclocal again. This is what
happens with, for example, the "tracker" program that can be checked out
via git://git.gnome.org/tracker: removing the "m4" directory from this
checkout (which was added as a dummy just to suppress this problem) and
running "autoreconf -vfi" will fail with a fatal error from aclocal:
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force -I m4
aclocal: couldn't open directory `m4': No such file or directory
autoreconf2.50: aclocal failed with exit status: 1
With this commit, the autoreconf step can be completed.
This problem was reported by Michael Biebl <biebl@debian.org> as a bug
against the Debian packaging of Autoconf. The Debian bug log is available
at <http://bugs.debian.org/565663>.
---
ChangeLog | 6 ++++++
aclocal.in | 3 ++-
2 files changed, 8 insertions(+), 1 deletions(-)
mode change 100644 => 100755 aclocal.in
diff --git a/ChangeLog b/ChangeLog
index 5fbc889..d0d8ccf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-02-27 Ben Pfaff <blp@cs.stanford.edu>
+
+ Make -Idir a warning instead of a fatal error if 'dir' does not
+ exist.
+ * aclocal.in (scan_m4_dirs): Demote fatal error to warning.
+
2010-02-24 Antonio Diaz Diaz <ant_diaz@teleline.es> (tiny change)
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
diff --git a/aclocal.in b/aclocal.in
old mode 100644
new mode 100755
index dc84762..6d6156e
--- a/aclocal.in
+++ b/aclocal.in
@@ -311,7 +311,8 @@ sub scan_m4_dirs ($@)
{
if (! opendir (DIR, $m4dir))
{
- fatal "couldn't open directory `$m4dir': $!";
+ msg ('unsupported', "couldn't open directory `$m4dir': $!");
+ next;
}
# We reverse the directory contents so that foo2.m4 gets
The process for bootstrapping some software from a version control system
checkout involves running aclocal before the m4 directory exists, then
populating the m4 directory and running aclocal again. This is what
happens with, for example, the "tracker" program that can be checked out
via git://git.gnome.org/tracker: removing the "m4" directory from this
checkout (which was added as a dummy just to suppress this problem) and
running "autoreconf -vfi" will fail with a fatal error from aclocal:
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force -I m4
aclocal: couldn't open directory `m4': No such file or directory
autoreconf2.50: aclocal failed with exit status: 1
With this commit, the autoreconf step can be completed.
This problem was reported by Michael Biebl <biebl@debian.org> as a bug
against the Debian packaging of Autoconf. The Debian bug log is available
at <http://bugs.debian.org/565663>.
---
ChangeLog | 6 ++++++
aclocal.in | 3 ++-
2 files changed, 8 insertions(+), 1 deletions(-)
mode change 100644 => 100755 aclocal.in
diff --git a/ChangeLog b/ChangeLog
index 5fbc889..d0d8ccf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-02-27 Ben Pfaff <blp@cs.stanford.edu>
+
+ Make -Idir a warning instead of a fatal error if 'dir' does not
+ exist.
+ * aclocal.in (scan_m4_dirs): Demote fatal error to warning.
+
2010-02-24 Antonio Diaz Diaz <ant_diaz@teleline.es> (tiny change)
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
diff --git a/aclocal.in b/aclocal.in
old mode 100644
new mode 100755
index dc84762..6d6156e
--- a/aclocal.in
+++ b/aclocal.in
@@ -311,7 +311,8 @@ sub scan_m4_dirs ($@)
{
if (! opendir (DIR, $m4dir))
{
- fatal "couldn't open directory `$m4dir': $!";
+ msg ('unsupported', "couldn't open directory `$m4dir': $!");
+ next;
}
# We reverse the directory contents so that foo2.m4 gets
reassign 565663 automake thanks Hi Michael. Because we determined that the appropriate fix here is to aclocal, which is part of automake, I'm reassigning this to Debian's automake package. I had hoped that this would be fixed upstream, because I did send a patch (see http://permalink.gmane.org/gmane.linux.debian.devel.bugs.general/678260) and a week later a ping (see http://permalink.gmane.org/gmane.comp.sysutils.automake.patches/3859), but neither one of my emails elicited any kind of public or private response. It's not really my job to maintain Automake; perhaps Debian's Automake maintainer has a better connection to upstream than I do. Thanks, Ben.