bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

string comparison operators (was: Re: Tail call elimination)


From: Paul Smith
Subject: string comparison operators (was: Re: Tail call elimination)
Date: Mon, 18 May 2020 16:44:30 -0400

On Mon, 2020-05-18 at 20:04 +0000, Tim Murphy wrote:
> Re comparing strings: we already have ifeq and what I have often
> wanted is to have a function equivalent so I can use it in
> expressions. As bad as ifeq may be from the point of view of locale
> this need be no better to be an improvement over the unpleasant hacks
> I've had to use to get the same effect with more complicated
> expressions.

The issue is that conditionals have a very different syntax than an
inline function:

  ifeq (arg1, arg2)
  ifeq 'arg1' 'arg2'
  ifeq "arg1" "arg2"
  ifeq "arg1" 'arg2'
  ifeq 'arg1' "arg2"

You can see that here we are actually accepting and parsing quotes:
it's the only place in GNU make syntax where make cares about quotes.

How would this translate to an inline function?  Do we need to invent
quote matching and parsing there as well?  If we don't have some kind
of quoting it will be very hard to manage string comparisons where
strings contain whitespace and/or operators:

   x = does x eq
   y = y

   z = $(expr $x ne $y)

will run expr with arguments "does x eq ne y" which is not going to be
parsed correctly.

The reason (I assume) GNU make accepts so many different delimiters is
that it doesn't contain a robust escape sequence implementation
(personally I think this was the wrong choice because it assumes you
know the contents of your variables sufficiently to pick a set of
delimiters that won't conflict--I would have preferred a single set of
delimiters and a 100% reliable escape character mechanism across the
entire grammar--at least outside of recipes--plus maybe a function that
will "enscapify" a string).

This kind of thing is why I'd prefer to separate out the different
proposals as some answers are much simpler than others.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]