RE: [bug #13877] Error parsing define/endef when both are indente d using tabs

[Paul D. Smith]

%% address@hidden writes:

  rm> I can see your points.  I may not agree with them ;-), but I understand
  rm> them.

OK, good... starting from the same place is always best :-).

  rm> In the case where someone wants to put 'endef', or any of the
  rm> others as the first word of a command, one could always remove the
  rm> specialness of the keyword by escaping, or quoting, it.  Example:

  rm>   <tab>define macro
  rm>   <tab>tgt:
  rm>   <tab><tab>\endef ...
  rm>   <tab>endef
  rm> or
  rm>   <tab>define macro
  rm>   <tab>tgt:
  rm>   <tab><tab>'endef' ...
  rm>   <tab>endef

That's true, it could have been done that way.

But, that's not how GNU make works now and it's not how it's ever worked
before (for "any of the others", at any rate).

Also it should be pointed out that the POSIX standard for make requires
that lines starting with TAB characters be considered command script
lines and doesn't allow for special cases like this.  Of course you can
argue that ifdef etc. are not POSIX, but the question for POSIX
compliance as far as GNU make is concerned is, for every makefile that
is valid according to the POSIX spec, does GNU make handle it as the
POSIX spec requires?

endef is really an annoying case, of course, since it can't be handled
correctly 100% of the time.

  rm> IMO, this is a much better solution that standing on our heads to
  rm> support the rare case where 'endef', et. al, might be used as the
  rm> first word of a command.

It's just as easy, and more consistent and correct, to avoid using TAB
to indent make control lines.  Then you completely avoid ALL these
issues!

  rm> And, I tried to define a target within a define/endef -- it doesn't
  rm> work.  Example:

  rm>   define macro
  rm>   all::
  rm>   <tab>@echo command1
  rm>   <tab>@echo command2
  rm>   endef
  rm>   $(macro)

  rm> Results in:

  rm>   make: *** No rule to make target '
  rm>   ', needed by all. Stop.

It will work if you do this:

    $(eval $(macro))

Of course, you need a newer version of GNU make to use $(eval ...) but
this kind of thing is a staple of eval; in fact, the usefulness of eval
would be significantly diminished without define.

  rm> I would think it should work, but it doesn't.  Effectively
  rm> removing one of your arguments.

Back atcha!! :-)

  rm> So, IMO, all these reserved words (ifndef, ..., endif, define,
  rm> endef) should always be recognized - regardless of leading
  rm> blanks/tabs, and if you want to use one of these reserved words as
  rm> the first word of a command, then you need to escape, or quote it.

  rm> Consistency is a good thing.  Consistency across make versions is
  rm> even better.

Hm.  On the one hand you're arguing backward compatibility and on the
other you're saying we should change ALL the preprocessor statements to
accept TAB at the beginning of the line, which would be even more
incompatibility.


Although backward compatibility is important, proper and consistent
behavior is also important, as is POSIX compatibility... and finally
indenting non command script lines with TAB is just bad makefile style
on every level, so I have a hard time viewing breaking compatibility in
this way as a terrible disaster.  I realize though that your perspective
(with lots of makefiles that have this problem) is different :-).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist