%% [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
