Re: Output quoting (was: Re: Possible solution for special characters in makefile paths)

[Paul Smith]

On Sun, 2014-04-13 at 08:26 +0300, Eli Zaretskii wrote:
> > When expanding $(BAR) in the recipe, make cannot determine that it
> > should remove the backslash inside '$(FOO)' but not the one in
> > '(foo\ bar)', and if it removes the latter the script will have a syntax
> > error.  And there are a TON of scripts like this out there (any
> > automake-generated makefile has numerous examples).
> 
> Aren't these very problems solved every day in Unix shells, Lisp, and
> even in Make itself?  You just double any literal backslash on
> encoding, and that's it.  What am I missing?

Backward-compatibility.  If this problem had been considered and
addressed back when makefile syntax was being created, like it was for
the shell etc., then we wouldn't be having this conversation.  It
wasn't, so there are hundreds of thousands of makefiles out there that
contain unescaped backslashes in variable values.

This change would require those makefiles to be modified to double their
literal backslashes before they will work properly.  Mind you this is
not just "makefiles that want to work with special characters in
filenames must be changed", but every makefile that uses a literal
backslash in a variable value would have to be changed.

Also this is a "flag day" change where once you've modified your
makefile to work with the new version of GNU make it won't work anymore
with _older_ versions of GNU make, which do not expect those backslashes
to be doubled and won't un-double them when variables are expanded.

This also means that all makefile-generating programs like automake,
cmake, etc. that generated makefiles containing backslashes (there's no
question automake does this, at least) would have to change.

And, it violates the POSIX spec for make which does not require
backslashes to be doubled in order to work properly, which means GNU
make is no longer a strict superset of the POSIX standard, and we'd have
to choose this basic behavior or not depending on the .POSIX special
target.


> Not if we find a way of knowing which backslashes were introduced by
> encoding.

Yes, that's true.  But how can we know?  It's possible to know in a few
simple cases, such as automatic variables and the results of some make
functions.  But when expanding a random variable into a recipe how can
we know which backslashes in the expanded string are there for make, and
should be removed, and which are there for the shell, and should be
preserved?

That's really the entire advantage of the other quoting method: it uses
entirely new syntax, rather than overlapping with existing syntax, so
it's possible to know exactly what the user intends without ambiguity.