[bug #59956] Recipes inside conditionals can break the parser

[Paul D. Smith]

Follow-up Comment #7, bug #59956 (project make):

Adding a new keyword doesn't help: it's not that we're trying to use a make
*else* clause but the *else* is being interpreted as something else, where
replacing it with *.else* would help clarify what is meant; the problem is
that we're trying to use a shell (in this situation) *else* clause, so we
can't change it to *.else*, but make is interpreting it as a make *else*
clause.

The only way new keywords could help would be something like: allowing all
make conditional statements (*ifeq*, *ifneq*, *ifdef*, *else*, *endif*) to be
prefixed by ".", _and_ whichever form is used by the if-statement would have
to be used throughout.  So if you used *.ifeq* instead of *ifeq* then you must
also use *.else* and *.endif* and *else* and *endif* would not be recognized
for that if-statement.  This is a lot of churn; I'm not convinced.

I'm not sure what to say about people using TAB to indent conditionals. 
That's SO dangerous and SO error-prone!  All that has to happen is that the
makefile is modified so these exist in a recipe context and boom!  Your entire
makefile is broken.  And how easy is it to create a recipe context?  As I show
in my replies below, *very* easy; here's a simple example:


ifeq (1,1)
        X = true
else
        X = false
endif

all:;@echo $X


That prints *true* as you expect.  Now if I change this makefile just
slightly:


.PHONY: all

ifeq (1,1)
        X = true
else
        X = false
endif

all:;@echo $X


Now *X* is not set at all!!  How many hours of staring at this makefile will
it take to understand what the problem is here?!?!

It's very hard for me to justify preserving such dangerous behavior as a
"feature".

An alternative heuristic would be that the same indentation level as the
*ifeq* would be required for all the conditional statements but I suspect that
would lead to even more widespread backward-compatibility problems.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59956>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/