Re: make and backslash-newline's

[Paul D. Smith]

%% "Alfred M\. Szmidt" <address@hidden> writes:

  ams> Thanks for the detailed explanation, but the thing with the
  ams> backslash/newline stuff is that it breaks old Makefiles, and it
  ams> makes new Makefiles not work with old makes; it is also hard (and
  ams> might make it even more unreadable than what you have now!) to
  ams> make old Makefiles work with both a > 3.80 Make, and a <= 3.80
  ams> Make, which is why I'm really against this kind of change.

I don't think it's hard to support both.  There is no question that some
makefiles will need to change, and that's always unfortunate.  I still
believe the change is localized and not widespread enough to justify
supporting both behaviors... hopefully I'm not whistling past the
graveyard.

There are two simple ways to write makefiles such that they will work
with both old and new versions of GNU make: the first is simply avoid
using backslash/newline inside single-quoted strings.  This can, of
course, create some long lines, but a few longer lines might not be too
bothersome.

If the lines would be too long and confusing to read/maintain such that
the first solution is not acceptable, then the other solution is to move
the contents of the single-quoted string (or even the entire command, if
you prefer) into a make variable, where the backslash/newlines pairs are
interpreted by make using makefile rules, not by the shell using shell
rules.  So, instead of:

    foo:
            perl -e 'some long script \
                     with lots of backslash/newline \
                     pairs.'

You would have:

    foo_SCRIPT = 'some long script \
                  with lots of backslash/newline \
                  pairs.'
    foo:
            perl -e $(foo_SCRIPT)

Or maybe:

    foo_SCRIPT = perl -e 'some long script \
                          with lots of backslash/newline \
                          pairs.'
    foo: ; $(foo_SCRIPT)

Or any other similar combination.


Either of these methods will behave identically to the "old way", and
also will behave identically in both old and new versions of GNU make
(and other versions of make, if that's important to anyone).  And, I
don't think readability or maintainability suffers much using either of
these methods (of course these things are in the eye of the
beholder... Dan Jacobson for one seems to feel otherwise).


So, from a package owner standpoint, you may need to say that if you
upgrade to version 3.81 of GNU make you'll need to upgrade to version
X.YZ of your package to get an enhanced makefile, which is definitely
unfortunate, but there shouldn't be any need to say that if you upgrade
to version X.YZ of your package you must also install version 3.81 of
GNU make... that WOULD be awful.

-- 
-------------------------------------------------------------------------------
 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