Re: missing quotes in gcc/Makefile.in (stmp-fixinc)

[DJ Delorie <dj at redhat dot com>]

Toomas Rosin <toomas@ns.tklabor.ee> writes:
> --- gcc-2.95.3/gcc/Makefile.in.orig
> +++ gcc-2.95.3/gcc/Makefile.in
> @@ -2161,7 +2161,7 @@
>  stmp-fixinc: fixinc.sh gsyslimits.h
>  	rm -rf include; mkdir include
>  	TARGET_MACHINE=$(target); srcdir=`cd $(srcdir); pwd`; \
> -	INSTALL_ASSERT_H=$(INSTALL_ASSERT_H); SHELL=$(SHELL) ;\
> +	INSTALL_ASSERT_H=$(INSTALL_ASSERT_H); SHELL='$(SHELL)' ;\
>  	export TARGET_MACHINE srcdir INSTALL_ASSERT_H SHELL ; \
>  	$(SHELL) ./fixinc.sh `pwd`/include $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS)
>  	rm -f include/syslimits.h

This looks fine, but could you include a ChangeLog entry also?

> By the way, I have always wondered about a "philosophical" question:
> why are "&&" and "set -e" so seldom used in makerules?  Not in
> Makefiles for GCC only, but just about everywhere?  Are they not
> portable?  I would have guessed using one or the other of them in all
> multi-command rules would be a good practice.

&& needn't be used if the command you're running can't possibly fail,
and using ';' is clearer.  When you need to check the exit value, it
should be make checking it, not the shell, if you can arrange that.
In the case above, setting an environment variable should never fail
(well, except for your case, but a $SHELL with spaces is bound to
cause problems somewhere).  Also, && can't be used if the command is
expected to harmlessly fail on some occasions.  Otherwise, it's up to
the programmer to decide if/when error checking is needed and/or
useful.

set -e is dangerous if you happen to use a command whose exit code can
be nonzero for success (i.e. if the exit code is meaningful, not just
a pass/fail code), or if it's plain that a failure is tolerable.  For
example, the "rm -rf" above might fail (say, if the directory doesn't
exist and the system rm doesn't honor "-f" properly), but that can
safely be ignored as long as the mkdir succeeds.

When possible, it's better to have make invoke each command separately
and let it deal with the errors.  In theory, this will always be the
case, and it would be pointless to use && or set -e for anything.