On Tue, 2024-03-26 at 10:15 -0700, Kaz Kylheku wrote:
> However, I'm noticing that expansion preserves the semantic
> boundaries, which is important. If we have $(x) that expands
> to a,b, then we /can/ invoke $(call $(x),c,d). The delimiting
> of argument material must be happening prior to
On 2024-03-26 06:52, Paul Smith wrote:
> There's nothing wrong with creating a variable name containing a comma
> and I don't anticipate making this illegal.
That's good to know. Since the delimiter in function calls is
whitespace, and commas don't come into play until after that in
the argument
On Mon, 2024-03-25 at 18:47 -0700, Kaz Kylheku wrote:
> > I have considered doing this, but only AFTER it becomes an error
> > (not just a warning) to create a make variable with whitespace in
> > the name.
>
> Could you elaborate? How recent of a gmake do we need for this
> diagnostic?
The
> Addendum, yes, directly via:
>
> define a b c
> ...
> endef
>
> as well as with embedded comma:
>
> define a b c,
> ...
> endef
>
> These can be referenced via $(a b c) and $(a b c,).
Eww!
Stefan
On Mon, 2024-03-25 at 23:35 +0100, Tomas Volf wrote:
> I (think I) can just swap the order and do `CC=gcc make' in order to
> work around the issue (is that correct assumption?), but would like
> to understand why it behaves like this.
Dmitry explained that in versions of GNU Make prior to 4.4,
On 2024-03-25 20:35:35 -0400, Dmitry Goncharov wrote:
> On Mon, Mar 25, 2024 at 7:40 PM Tomas Volf <~@wolfsden.cz> wrote:
> > I am currently trying to figure out how to correctly pass CC variable to the
> > make. Passing it as an make variable (`make CC=gcc') seems to work in
> > almost
> > all
