Re: I: adjust test suite for upcoming GNU Make 3.83

[Paul D. Smith]

%% Alexandre Duret-Lutz <address@hidden> writes:

  adl> So any solution that require a syntax that is different in
  adl> prerequisites than it is in the commands seems wrong to me.

  pds> I definitely agree that this incongruity is disturbing, but
  pds> that's the way it is.

  adl> Don't read me wrong, that wasn't a judgement of the way things
  adl> are but an attempt to characterize an acceptable solution for
  adl> Automake.  Automake is meant to produce portable Makefiles so I
  adl> don't want to introduce non-portable constructs in its generated
  adl> output, even conditionally (it's already hard enough to test).
  adl> The only place we could tolerate non-portable constructs is in
  adl> the user input (*.am) that is output almost verbatim.  Hence my
  adl> statement: since users writes the variables, I'm looking for a
  adl> solution that involves only changing these variables, and since
  adl> these variables are used both in prerequisite lists and
  adl> commands...

I definitely understand your concern.  All I can say is that filenames
with $ in them (and so, in effect, any support of Java IIRC) is already
completely non-portable.  I guess the problem is that it used to be
non-portable in that it wouldn't work correctly, but at least the output
makefile was a valid makefile for all versions of make.  Now, if we want
to support backward-compatibility, you'd need to put some code into the
makefile which is valid make syntax only in GNU make... which means
you'd have to forgo even printing it into a makefile unless you knew it
was needed.

Hm.  Or, do you?

This actually should be valid make syntax in all versions of make:

  PRE_D = $(if $(filter second-expansion,$(.FEATURES)),$$$$,$$)

  FILENAMES = foo$$bar

  all: $(subst $$,$(PRE_D),$(FILENAMES))
      @echo 'FILENAMES = $(FILENAMES)'
      @echo '$@ : $^'

  foo$$bar:
      @echo 'touch $@'

Now, obviously, it won't WORK properly with any make other than GNU
make, but at least the syntax is valid POSIX make syntax.

The other problem of course, is that you can't use the subst function in
every makefile for every prerequisite: you'd need to figure out which
makefiles might have "$" in the prerequisite lists and only use it
there.

So, it's still gross.


The other alternative is to do away with backward compatibility and just
say that as of release automake XXX you need GNU make 3.81 if your
makefiles have $ in the names.  The nice(?) thing about this is that
these makefiles should also, then, work with other SysV make versions.

Or, you can have an automake option that selects which the user has.  Or
test for it, although of course that's not very reliable.

Bleah.  I see no good solution to this.

  pds> Hopefully the next version of GNU make will have some more generic
  pds> mechanism for quoting that will handle ALL different "special
  pds> characters" that might appear in filenames, including colons and
  pds> whitespace as well as dollar signs.

  adl> Excellent!  That seems to be the ticket, doesn't it?

Well, sure, but that won't help us between the time 3.81 is released and
the time the version with the quoting enhancement is released.  I'd
really hate to have to tell people they couldn't use 3.81 with
automake.  I guess it would only impact users with "$" in filenames but
still...

And, of course, that syntax won't be portable either :-/.

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