mbox series

[v2,0/6] Makefile/perl: correctly re-generate build/* + speed up under NO_GETTEXT=Y

Message ID cover-0.6-00000000000-20210510T104937Z-avarab@gmail.com (mailing list archive)
Headers show
Series Makefile/perl: correctly re-generate build/* + speed up under NO_GETTEXT=Y | expand

Message

Ævar Arnfjörð Bjarmason May 10, 2021, 10:50 a.m. UTC
The summary, from v1:

    These patches are relatively trivial fixes for bugs noticed when I was
    working on recent send-email patches. We don't re-build perl/build/*
    assets when variables that affect them are changed, and needlessly use
    our non-mock gettext Perl i18n framework under NO_GETTEXT=Y if the
    system happens to have Locale::Messages installed.

Changes since v1:

The only change to the end-state is the trivial change-on-top of:

    -PERL_DEFINES :=
    +PERL_DEFINES =

I.e. the PERL_DEFINES is now also refactored away from a
simply-expanded variable. The re-arrangement and split-up of patches
in this v2 just makes for a more incremental way to get there, per the
discussion on v1.

Ævar Arnfjörð Bjarmason (6):
  Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changes
  Makefile: don't re-define PERL_DEFINES
  Makefile: make PERL_DEFINES recursively expanded
  Makefile: split up the deceleration of PERL_DEFINES
  Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS change
  perl: use mock i18n functions under NO_GETTEXT=Y

 Makefile         | 13 +++++++++----
 perl/Git/I18N.pm | 10 ++++++++++
 2 files changed, 19 insertions(+), 4 deletions(-)

Range-diff against v1:
2:  49339028db4 = 1:  8b899364916 Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changes
-:  ----------- > 2:  c15887bbc93 Makefile: don't re-define PERL_DEFINES
-:  ----------- > 3:  7919ae0e546 Makefile: make PERL_DEFINES recursively expanded
1:  ed2005a2fbf ! 4:  2cdefbe920c Makefile: don't re-define PERL_DEFINES
    @@ Metadata
     Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
     
      ## Commit message ##
    -    Makefile: don't re-define PERL_DEFINES
    +    Makefile: split up the deceleration of PERL_DEFINES
     
    -    Since 07d90eadb50 (Makefile: add Perl runtime prefix support,
    -    2018-04-10) we have been declaring PERL_DEFINES right after assigning
    -    to it, with the effect that the first PERL_DEFINES was ignored.
    +    Split the declaration of PERL_DEFINES across multiple line, making
    +    this easier to read.
     
    -    That bug didn't matter in practice since the first line had all the
    -    same variables as the second, so we'd correctly re-generate
    -    everything. It just made for confusing reading.
    -
    -    Let's remove that first assignment, and while we're at it split these
    -    across lines to make them more maintainable.
    +    In 07d90eadb50 (Makefile: add Perl runtime prefix support, 2018-04-10)
    +    when PERL_DEFINES was added only the RUNTIME_PREFIX was put on its own
    +    line the rest weren't formatted like that for consistency. Let's do
    +    that to make this consistent with most of the rest of this Makefile.
     
         Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
     
    @@ Makefile: perl_localedir_SQ = $(localedir_SQ)
      
      ifndef NO_PERL
      PERL_HEADER_TEMPLATE = perl/header_templates/fixed_prefix.template.pl
    --PERL_DEFINES = $(PERL_PATH_SQ):$(PERLLIB_EXTRA_SQ):$(perllibdir_SQ)
    --
    --PERL_DEFINES := $(PERL_PATH_SQ) $(PERLLIB_EXTRA_SQ) $(perllibdir_SQ)
    -+PERL_DEFINES :=
    +-PERL_DEFINES = $(PERL_PATH_SQ) $(PERLLIB_EXTRA_SQ) $(perllibdir_SQ)
    ++PERL_DEFINES =
     +PERL_DEFINES += $(PERL_PATH_SQ)
     +PERL_DEFINES += $(PERLLIB_EXTRA_SQ)
     +PERL_DEFINES += $(perllibdir_SQ)
3:  06e25bc1db3 = 5:  1171b73256e Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS change
4:  97247cb72a5 = 6:  7a5e7cf39a5 perl: use mock i18n functions under NO_GETTEXT=Y

Comments

Junio C Hamano May 10, 2021, 6:17 p.m. UTC | #1
Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> The summary, from v1:
>
>     These patches are relatively trivial fixes for bugs noticed when I was
>     working on recent send-email patches. We don't re-build perl/build/*
>     assets when variables that affect them are changed, and needlessly use
>     our non-mock gettext Perl i18n framework under NO_GETTEXT=Y if the
>     system happens to have Locale::Messages installed.
>
> Changes since v1:

Hmph, didn't reviewers declare that the previous round good enough?
I thought I merged it 'next' already.
Ævar Arnfjörð Bjarmason May 11, 2021, 6:56 a.m. UTC | #2
On Tue, May 11 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> The summary, from v1:
>>
>>     These patches are relatively trivial fixes for bugs noticed when I was
>>     working on recent send-email patches. We don't re-build perl/build/*
>>     assets when variables that affect them are changed, and needlessly use
>>     our non-mock gettext Perl i18n framework under NO_GETTEXT=Y if the
>>     system happens to have Locale::Messages installed.
>>
>> Changes since v1:
>
> Hmph, didn't reviewers declare that the previous round good enough?
> I thought I merged it 'next' already.

I sent this re-roll before I noticed that. Nevermind & sorry for the
noise.
Junio C Hamano May 11, 2021, 7:05 a.m. UTC | #3
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Tue, May 11 2021, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>>
>>> The summary, from v1:
>>>
>>>     These patches are relatively trivial fixes for bugs noticed when I was
>>>     working on recent send-email patches. We don't re-build perl/build/*
>>>     assets when variables that affect them are changed, and needlessly use
>>>     our non-mock gettext Perl i18n framework under NO_GETTEXT=Y if the
>>>     system happens to have Locale::Messages installed.
>>>
>>> Changes since v1:
>>
>> Hmph, didn't reviewers declare that the previous round good enough?
>> I thought I merged it 'next' already.
>
> I sent this re-roll before I noticed that. Nevermind & sorry for the
> noise.

Mails cross all the time.  A single-liner follow-up incremental
would be good, perhaps?

Thanks.