> 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 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 curre
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 c
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, no
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 l
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 expans
