%% Alexandre Duret-Lutz <[EMAIL PROTECTED]> 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 <[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
