GNU bug report logs - #9459
24.0.50; Configure aborts, complains about missing install.sh in build-aux

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9459 in the body.
You can then email your comments to 9459 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Condigure aborts, complains about missing install.sh in
	build-aux.
Date: Wed, 07 Sep 2011 18:18:10 +0200

Hi.

Updated today.

% make
cd /home/jhd/src/emacs/current && aclocal -I m4
cd /home/jhd/src/emacs/current && autoconf
if [ -x ./config.status ]; then	\
	    ./config.status --recheck;	\
	else				\
	    ./configure;		\
	fi
running CONFIG_SHELL=/bin/bash /bin/bash ../current/configure --verbose 
--enable-asserts --prefix=/opt/emacs-cvs CFLAGS=-g --no-create --no-recursion
configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
"../current"/build-aux

and also:

% ../current/configure
configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
"../current"/build-aux

	Jan D.

Message #8 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;
	Condigure aborts, complains about missing install.sh in build-aux.
Date: Wed, 07 Sep 2011 12:26:35 -0400

Jan Djärv wrote:

> configure: error: cannot find install-sh, install.sh, or shtool in
> build-aux "../current"/build-aux

There's probably some autotools invocation that avoids this, and
starting from a fresh checkout probably doesn't have an issue; but all I
did for my existing checkouts after I saw the corresponding change get
installed was:

  mv compile config.guess config.sub depcomp install-sh missing build-aux/

plus the usual maintainer-clean.

Message #11 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50; Configure aborts, complains about missing
	install.sh in build-aux.
Date: Wed, 07 Sep 2011 18:38:21 +0200

Glenn Morris skrev 2011-09-07 18:26:
> Jan Djärv wrote:
>
>> configure: error: cannot find install-sh, install.sh, or shtool in
>> build-aux "../current"/build-aux
>
> There's probably some autotools invocation that avoids this, and
> starting from a fresh checkout probably doesn't have an issue; but all I
> did for my existing checkouts after I saw the corresponding change get
> installed was:
>
>    mv compile config.guess config.sub depcomp install-sh missing build-aux/
>
> plus the usual maintainer-clean.

Yes that fixes it.  But a heads up would be nice when making a 
configure-breaking change like this.  Why not let configure do the move itself 
if it detects those files at the top of the tree?

	Jan D.

Message #14 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>,
	Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;
	Condigure aborts, complains about missing install.sh in build-aux.
Date: Wed, 07 Sep 2011 19:44:18 +0300

> Date: Wed, 07 Sep 2011 18:18:10 +0200
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> 
> Updated today.
> 
> % make
> cd /home/jhd/src/emacs/current && aclocal -I m4
> cd /home/jhd/src/emacs/current && autoconf
> if [ -x ./config.status ]; then	\
> 	    ./config.status --recheck;	\
> 	else				\
> 	    ./configure;		\
> 	fi
> running CONFIG_SHELL=/bin/bash /bin/bash ../current/configure --verbose 
> --enable-asserts --prefix=/opt/emacs-cvs CFLAGS=-g --no-create --no-recursion
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
> "../current"/build-aux
> 
> and also:
> 
> % ../current/configure
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux 
> "../current"/build-aux

Run ./autogen.sh by hand, and everything will be fixed again.

I don't know if GNUMakefile is supposed to DTRT with the kind of
changes installed in one of the recent commits (files used during
configure moved to other subdirectories).  Paul?

Message #19 received at 9459-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>,
	9459-done <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;	Condigure aborts, complains about missing
	install.sh in build-aux.
Date: Wed, 07 Sep 2011 11:00:13 -0700

On 09/07/11 09:44, Eli Zaretskii wrote:

> Run ./autogen.sh by hand, and everything will be fixed again.

Yes, that's right.

> I don't know if GNUMakefile is supposed to DTRT with the kind of
> changes installed in one of the recent commits (files used during
> configure moved to other subdirectories).  Paul?

In general, GNUmakefile can't recover from arbitrary mishaps
when one has an old tree, does a "bzr update", and then tries to
mimic autogen.sh's actions by hand but makes a mistake in the
process (which is what happened here).

Instead of trying to change GNUmakefile it's probably better to
just drop a line to emacs-devel; I'll do that next.

Message #20 received at 9459-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9459-done <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;	Condigure aborts, complains about missing
	install.sh in build-aux.
Date: Wed, 07 Sep 2011 20:15:02 +0200

Paul Eggert skrev 2011-09-07 20:00:
> On 09/07/11 09:44, Eli Zaretskii wrote:
>
>> Run ./autogen.sh by hand, and everything will be fixed again.
>
> Yes, that's right.
>
>> I don't know if GNUMakefile is supposed to DTRT with the kind of
>> changes installed in one of the recent commits (files used during
>> configure moved to other subdirectories).  Paul?
>
> In general, GNUmakefile can't recover from arbitrary mishaps
> when one has an old tree, does a "bzr update", and then tries to
> mimic autogen.sh's actions by hand but makes a mistake in the
> process (which is what happened here).
>

I did not try to mimic autogen.sh, I just did make.
If there was a mistake in there somewhere, the make rules are wrong.

	Jan D.

Message #23 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;	Condigure aborts, complains about missing
	install.sh in build-aux.
Date: Wed, 07 Sep 2011 11:15:24 -0700

The following change to Makefile.in would, I think, have
worked around Jan's problem.  It will slow down autoconfish
builds in general, though, I expect, because it'll run all
of autogen every time, instead of the individual components
needed.  Do you think it worth the tradeoff?

=== modified file 'Makefile.in'
--- Makefile.in	2011-07-24 22:15:47 +0000
+++ Makefile.in	2011-09-07 18:09:21 +0000
@@ -409,11 +409,11 @@ config.status: ${srcdir}/configure ${src
 AUTOCONF_INPUTS = @MAINT@ $(srcdir)/configure.in $(srcdir)/aclocal.m4
 
 $(srcdir)/configure: $(AUTOCONF_INPUTS)
-	cd ${srcdir} && autoconf
+	cd ${srcdir} && ./autogen.sh
 
 ACLOCAL_INPUTS = @MAINT@ $(srcdir)/m4/$(DOS_gnulib_comp.m4)
 $(srcdir)/aclocal.m4: $(ACLOCAL_INPUTS)
-	cd $(srcdir) && aclocal -I m4
+	cd $(srcdir) && ./autogen.sh
 
 AUTOMAKE_INPUTS = @MAINT@ $(srcdir)/aclocal.m4 $(srcdir)/lib/Makefile.am $(srcdir)/lib/gnulib.mk
 $(srcdir)/lib/Makefile.in: $(AUTOMAKE_INPUTS)
@@ -426,9 +426,9 @@ $(srcdir)/src/config.in: $(srcdir)/src/s
 	@ # because stamp-h.in has changed (since building stamp-h.in
 	@ # refreshes config.in as well), but if config.in is missing
 	@ # then we really need to do something more.
-	[ -r "$@" ] || ( cd ${srcdir} && autoheader )
+	[ -r "$@" ] || ( cd ${srcdir} && ./autogen.sh )
 $(srcdir)/src/stamp-h.in: $(AUTOCONF_INPUTS)
-	cd ${srcdir} && autoheader
+	cd ${srcdir} && ./autogen.sh
 	rm -f $(srcdir)/src/stamp-h.in
 	echo timestamp > $(srcdir)/src/stamp-h.in
 

Message #26 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: jan.h.d <at> swipnet.se, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;
	Condigure aborts, complains about missing install.sh in build-aux.
Date: Wed, 07 Sep 2011 21:22:22 +0300

> Date: Wed, 07 Sep 2011 11:15:24 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Jan Djärv <jan.h.d <at> swipnet.se>, 
>  9459 <at> debbugs.gnu.org
> 
> The following change to Makefile.in would, I think, have
> worked around Jan's problem.  It will slow down autoconfish
> builds in general, though, I expect, because it'll run all
> of autogen every time, instead of the individual components
> needed.  Do you think it worth the tradeoff?

My opinion: no, please don't.  Such changes are rare enough and far in
between, while normal builds are much more frequent.  It only takes
one botched build to learn to run autogen.sh manually when "make"
won't cut it.

Message #29 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;
	Condigure aborts, complains about missing install.sh in build-aux.
Date: Wed, 07 Sep 2011 20:24:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> My opinion: no, please don't.  Such changes are rare enough and far in
> between, while normal builds are much more frequent.  It only takes
> one botched build to learn to run autogen.sh manually when "make"
> won't cut it.

I agree.

But would it be possible to have "make" spit out "Compilation failed;
have you tried running ./autogen.sh before reporting this as a bug?" if
building fails?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #32 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50; Condigure aborts, complains about missing
	install.sh in build-aux.
Date: Wed, 07 Sep 2011 11:39:16 -0700

On 09/07/11 11:24, Lars Magne Ingebrigtsen wrote:
> would it be possible to have "make" spit out "Compilation failed;
> have you tried running ./autogen.sh before reporting this as a bug?" if
> building fails?

Sure.  Or "make" could simply fall back on autogen.sh
if the current approach fails.  That would be just as fast as
now, in the normal case where the build works, and it would have
addressed Jan's problem I expect.  How about something like this?


=== modified file 'Makefile.in'
--- Makefile.in	2011-07-24 22:15:47 +0000
+++ Makefile.in	2011-09-07 18:35:28 +0000
@@ -409,15 +409,15 @@ config.status: ${srcdir}/configure ${src
 AUTOCONF_INPUTS = @MAINT@ $(srcdir)/configure.in $(srcdir)/aclocal.m4
 
 $(srcdir)/configure: $(AUTOCONF_INPUTS)
-	cd ${srcdir} && autoconf
+	cd ${srcdir} && autoconf || ./autogen.sh
 
 ACLOCAL_INPUTS = @MAINT@ $(srcdir)/m4/$(DOS_gnulib_comp.m4)
 $(srcdir)/aclocal.m4: $(ACLOCAL_INPUTS)
-	cd $(srcdir) && aclocal -I m4
+	cd $(srcdir) && aclocal -I m4 || ./autogen.sh
 
 AUTOMAKE_INPUTS = @MAINT@ $(srcdir)/aclocal.m4 $(srcdir)/lib/Makefile.am $(srcdir)/lib/gnulib.mk
 $(srcdir)/lib/Makefile.in: $(AUTOMAKE_INPUTS)
-	cd $(srcdir) && automake --gnu -a -c lib/Makefile
+	cd $(srcdir) && automake --gnu -a -c lib/Makefile || ./autogen.sh
 am--refresh: $(srcdir)/aclocal.m4 $(srcdir)/configure $(srcdir)/src/config.in
 .PHONY: am--refresh
 
@@ -428,7 +428,7 @@ $(srcdir)/src/config.in: $(srcdir)/src/s
 	@ # then we really need to do something more.
 	[ -r "$@" ] || ( cd ${srcdir} && autoheader )
 $(srcdir)/src/stamp-h.in: $(AUTOCONF_INPUTS)
-	cd ${srcdir} && autoheader
+	cd ${srcdir} && autoheader || ./autogen.sh
 	rm -f $(srcdir)/src/stamp-h.in
 	echo timestamp > $(srcdir)/src/stamp-h.in
 

Message #35 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;
	Condigure aborts, complains about missing install.sh in build-aux.
Date: Wed, 07 Sep 2011 21:46:26 -0400

>> would it be possible to have "make" spit out "Compilation failed;
>> have you tried running ./autogen.sh before reporting this as a bug?" if
>> building fails?

> Sure.  Or "make" could simply fall back on autogen.sh
> if the current approach fails.  That would be just as fast as
> now, in the normal case where the build works, and it would have
> addressed Jan's problem I expect.  How about something like this?

I much prefer a message, since the failure may be due to too
many things.


        Stefan

Message #38 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50; Condigure aborts, complains about missing
	install.sh in build-aux.
Date: Thu, 08 Sep 2011 09:25:37 -0700

On 09/07/11 18:46, Stefan Monnier wrote:
> I much prefer a message

I tried that approach, but abandoned it because it didn't work well.
If we do something like this:

         $(srcdir)/configure: $(AUTOCONF_INPUTS)
        -       cd ${srcdir} && autoconf
        +       cd ${srcdir} && autoconf || { \
        +         echo 'Please run ./autogen.sh before reporting a bug.'; \
        +         exit 1; \
        +       }

then the "Please run autogen.sh" message is displayed all the time,
even when autoconf succeeds, because "make" always tells us what it
will do, and the message itself is in the instructions we send to
"make".  I'd rather avoid this sort of annoying chatter in the normal
case.  (The problem can be worked around with some makefile hackery,
but this minor issue isn't worth the complexity.)

> since the failure may be due to too many things.

Yes, of course.  But if the failure is something that autogen.sh can
repair (which was the case with Jan's problem), then invoking
autogen.sh is a win.  And if it's something that autogen.sh can't
repair, then we're no worse off than before.  So falling back on
autogen.sh seems to be a win overall.

Message #41 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50;
	Condigure aborts, complains about missing install.sh in build-aux.
Date: Thu, 08 Sep 2011 18:30:23 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> I tried that approach, but abandoned it because it didn't work well.
> If we do something like this:
>
>          $(srcdir)/configure: $(AUTOCONF_INPUTS)
>         -       cd ${srcdir} && autoconf
>         +       cd ${srcdir} && autoconf || { \
>         +         echo 'Please run ./autogen.sh before reporting a bug.'; \
>         +         exit 1; \
>         +       }

Can't you put the message in a variable (or something)?  Either that, or
suppress printing this particular line...

> Yes, of course.  But if the failure is something that autogen.sh can
> repair (which was the case with Jan's problem), then invoking
> autogen.sh is a win.  And if it's something that autogen.sh can't
> repair, then we're no worse off than before.  So falling back on
> autogen.sh seems to be a win overall.

If the build failure is something completely irrelevant to autogen.sh
(if, for instance, we're hacking the sources), then having autogen.sh
run unexpectedly would be annoying.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #44 received at 9459 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 9459 <at> debbugs.gnu.org
Subject: Re: bug#9459: 24.0.50; Condigure aborts, complains about missing
	install.sh in build-aux.
Date: Thu, 08 Sep 2011 10:04:11 -0700

On 09/08/11 09:30, Lars Magne Ingebrigtsen wrote:
> Can't you put the message in a variable (or something)?

Putting it in a makefile variable won't work, because 'make'
would still expand the variable and display the message
before running autoconf.

We could put the message into a separate shell script (which
we could call "not-autogen.sh" say), but that's overkill.
I can think of other, even fancier ways to attack the problem,
but they're all overkill too.

> or suppress printing this particular line...

But then the user wouldn't be informed when 'autoconf' runs.
We shouldn't do that.

>> > falling back on autogen.sh seems to be a win overall.
> If the build failure is something completely irrelevant to autogen.sh
> (if, for instance, we're hacking the sources)

autogen.sh would be run only when a subset of autogen.sh fails,
so the build failure cannot possibly be irrelevant to autogen.sh.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.