Re: Possible solution for special characters in makefile paths

[Paul Smith]

On Thu, 2014-02-20 at 20:31 -0800, Bill Cox wrote:
> If the new lexing/encoding behavior is turned off by default, and only
> explicitly enabled, users are safe from a quiet behavior change, which
> removes my concern.

OK thanks for the update.  In general I'm very much against having these
sorts of "modes" available.  Not only is it confusing to users, but each
such mode exponentially increases the amount of testing needed and the
possible issues with interaction on other optional features.

So, it wouldn't be my first choice to have the behavior be optional and
something you could turn off and on, regardless of which was the default
behavior.

Rather I'd prefer to understand what the issues are and either mitigate
them if possible, document them if they are rare and can't be fixed, or
else choose a different method where the compatibility issues were less
severe.


I don't see that this proposal has much of a problem with
backward-compatibility, and especially not with quiet behavior changes.
However it's very possible I'm overlooking something important.

The most concerning group to me are people who are currently trying to
use hacks and tricks to get around the "no whitespace" restriction in
the current GNU make.  I've seen people try things like replace all
spaces with a special character inside the makefile, then undo that with
subst in recipe lines, etc.  I don't think this will cause their
existing workarounds to fail, but I may not be that familiar with them.

The potential backward-compat issues I see are:

     1. Makefiles containing the special mapping characters (we can
        detect this and fail during makefile parsing)
     2. Makefiles already using whatever special quoting method we
        choose ($[, $`, etc.)  We can detect this on assignment, if we
        want, and warn about it... although I'd prefer not to.
     3. Makefiles assuming that the results of `$(wildcard ...)` will
        contain spaces.  I don't see any legitimate way this could be a
        problem though.
     4. Makefiles assuming that goal targets may contain whitespace.
        Again I can't see any legitimate way this could currently be
        used.

So overall, the backward-compatibility problems seem minimal except
possibly for the first two.  Is your concern about those?  Or one of the
others?  Or something I've missed?

Thanks for taking the time to think about this!