bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Jan Djärv]

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.

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Glenn Morris]

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.

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

[Jan Djärv]

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.

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Eli Zaretskii]

> Date: Wed, 07 Sep 2011 18:18:10 +0200
> From: Jan Djärv <jan.h.d@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?

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Paul Eggert]

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.

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Paul Eggert]

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
 

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Eli Zaretskii]

> Date: Wed, 07 Sep 2011 11:15:24 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 
>  9459@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.

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@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/

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Paul Eggert]

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
 

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Stefan Monnier]

>> 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

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Paul Eggert]

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.

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Lars Magne Ingebrigtsen]

Paul Eggert <eggert@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/

bug#9459: 24.0.50; Condigure aborts, complains about missing install.sh in build-aux.

[Paul Eggert]

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.