git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/4] Makefile: don't re-define PERL_DEFINES
Date: Thu, 6 May 2021 12:55:58 -0400	[thread overview]
Message-ID: <YJQfnviIeK7UdCBy@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq4kfg3c4v.fsf@gitster.g>

On Thu, May 06, 2021 at 10:05:20AM +0900, Junio C Hamano wrote:

> As to the simply-expanded vs recursively-expanded variable, there is
> aneed to use former, which comes from what the original commit
> 07d90ead did outside the context of this patch, which is:
> 
>     PERL_DEFINES := $(subst $(space),:,$(PERL_DEFINES))
>     GIT-PERL-DEFINES: FORCE
>             @FLAGS='$(PERL_DEFINES)'; \
>                 if test x"$$FLAGS" != x"`cat $@ 2>/dev/null`" ; then \
>                     echo >&2 "    * new perl-specific parameters"; \
>                     echo "$$FLAGS" >$@; \
>                 fi
> 
> That is, up to this point PERL_DEFINES accumulate various build-time
> settings with += (i.e. space separated tokens), and at this point
> finally it is turned into a colon separated tokens, which cannot be
> written with a recursively expanded variable.
> 
> But I tend to agree that you do not have to := clear the list in
> this patch.

OK, that matches my understanding. Thanks for laying out.

In general, I would say that the later use that you quoted above would
do better to use a second variable (because then there is no question of
when PERL_DEFINES is space-separated and when it is colon-separated).
But that is not that big a deal, and certainly very orthogonal to Ævar's
patch.

I'd also question whether the colon transformation is even necessary.
The point of the file is to change when the values change. Being sloppy
with delimiters means we _could_ miss a change, but in practice I doubt
it is very likely (and it is not like colons cannot appear in values,
either, so they are not foolproof). But again, not really important for
this patch.

-Peff

P.S. I also wondered briefly if make would preserve spaces even for
empty variables (since without that, we might miss delimiters and
confuse one of the variables for another). I.e., we know that:

  FOO = $(one):$(two):$(three)

will have two colons even if some of the variables are empty. But does
it preserve them even for "$(one) $(two) $(three)", or more importantly,
when using "+=" (which _would_ be relevant to this patch)? The answer is
yes, they are all fine.

You can demonstrate it with the Makefile below, running "make one=foo
three=bar", "make two=foo", etc.

-- >8 --
empty :=
space := $(empty) $(empty)

COLONS = $(one):$(two):$(three)

SPACES_SINGLE = $(one) $(two) $(three)
SPACES_SINGLE := $(subst $(space),:,$(SPACES_SINGLE))

SPACES_PLUS =
SPACES_PLUS += $(one)
SPACES_PLUS += $(two)
SPACES_PLUS += $(three)
SPACES_PLUS := $(subst $(space),:,$(SPACES_PLUS))

all:
	@echo "COLONS=$(COLONS)"
	@echo "SPACES_SINGLE=$(SPACES_SINGLE)"
	@echo "SPACES_PLUS=$(SPACES_PLUS)"

  reply	other threads:[~2021-05-06 16:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 12:21 [PATCH 0/4] Makefile/perl: correctly re-generate build/* + speed up under NO_GETTEXT=Y Ævar Arnfjörð Bjarmason
2021-05-05 12:21 ` [PATCH 1/4] Makefile: don't re-define PERL_DEFINES Ævar Arnfjörð Bjarmason
2021-05-05 14:08   ` Jeff King
2021-05-06  1:05     ` Junio C Hamano
2021-05-06 16:55       ` Jeff King [this message]
2021-05-06  6:23     ` Ævar Arnfjörð Bjarmason
2021-05-06  8:42       ` Junio C Hamano
2021-05-06  9:04         ` Ævar Arnfjörð Bjarmason
2021-05-06 16:59           ` Jeff King
2021-05-07  8:42           ` Junio C Hamano
2021-05-05 12:21 ` [PATCH 2/4] Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changes Ævar Arnfjörð Bjarmason
2021-05-05 12:21 ` [PATCH 3/4] Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS change Ævar Arnfjörð Bjarmason
2021-05-05 12:21 ` [PATCH 4/4] perl: use mock i18n functions under NO_GETTEXT=Y Ævar Arnfjörð Bjarmason
2021-05-10 10:50 ` [PATCH v2 0/6] Makefile/perl: correctly re-generate build/* + speed up " Ævar Arnfjörð Bjarmason
2021-05-10 10:50   ` [PATCH v2 1/6] Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changes Ævar Arnfjörð Bjarmason
2021-05-10 10:50   ` [PATCH v2 2/6] Makefile: don't re-define PERL_DEFINES Ævar Arnfjörð Bjarmason
2021-05-10 10:50   ` [PATCH v2 3/6] Makefile: make PERL_DEFINES recursively expanded Ævar Arnfjörð Bjarmason
2021-05-10 10:50   ` [PATCH v2 4/6] Makefile: split up the deceleration of PERL_DEFINES Ævar Arnfjörð Bjarmason
2021-05-10 10:50   ` [PATCH v2 5/6] Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS change Ævar Arnfjörð Bjarmason
2021-05-10 10:50   ` [PATCH v2 6/6] perl: use mock i18n functions under NO_GETTEXT=Y Ævar Arnfjörð Bjarmason
2021-05-10 18:17   ` [PATCH v2 0/6] Makefile/perl: correctly re-generate build/* + speed up " Junio C Hamano
2021-05-11  6:56     ` Ævar Arnfjörð Bjarmason
2021-05-11  7:05       ` Junio C Hamano
2021-05-12  9:49         ` [PATCH] Makefile: make PERL_DEFINES recursively expanded Ævar Arnfjörð Bjarmason
2021-05-12 19:53           ` Jeff King
2021-05-12 22:45             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJQfnviIeK7UdCBy@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).