From: Jeffrey Walton <noloader@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
stefan.naewe@atlas-elektronik.com
Subject: Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes
Date: Wed, 29 Mar 2017 18:22:26 -0400 [thread overview]
Message-ID: <CAH8yC8mkndAWP46M2L7TX8HF_y4xa5X29-Q--bA6Prurpya48Q@mail.gmail.com> (raw)
In-Reply-To: <CACBZZX70oXn7McjavzvK5S30EXjXQhLixhb=WYbKCKYXVo1KBA@mail.gmail.com>
>>> Now the logic added in commit ee9be06770 ("perl: detect new files in
>>> MakeMaker builds", 2012-07-27) is extended to regenerate
>>> perl/perl.mak if there's any change to "perl -V".
>>
>> Nice. This fix is way simpler than I feared.
>>
>>> This will in some cases redundantly trigger perl/perl.mak to be
>>> re-made, e.g. if @INC is modified in ways the build process doesn't
>>> care about through sitecustomize.pl, but the common case is that we
>>> just do the right thing and re-generate perl/perl.mak when needed.
>>
>> I think that's fine. There's a related bug that the generation of
>> perl/perl.mak via recursive-make is sometimes racy. So that _might_
>> trigger more often as a result of this, but I think the solution is to
>> fix that race, not try to pretend it won't happen. :)
>
> We'll also redundantly trigger if you upgrade to a minor new perl
> version, but I think that's squarely in "who cares" territory. This'll
> only impact people working on git, and *occasionally* they might get a
> 100 ms hit when running make, as opposed to a cryptic error where
> they'll likely stare at it for a bit before running "make clean".
+1, I don't mind extra config or build times as long as things "just
work" for the common case.
I was trying to figure out the use case that I was seeing. I was
envisioning someone with Perl 4 in /usr/local who complained it would
break some one-off setup. In the common case, the guy running Perl 4
should do the extra work, not the majority of users operating under
the common case.
Jeff
prev parent reply other threads:[~2017-03-29 22:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 1:03 Can't locate ExtUtils/MakeMaker.pm in @INC Jeffrey Walton
2017-03-29 2:18 ` Jeff King
2017-03-29 13:29 ` [PATCH] perl: regenerate perl.mak if perl -V changes Ævar Arnfjörð Bjarmason
2017-03-29 13:33 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2017-03-29 13:36 ` stefan.naewe
2017-03-29 13:57 ` [PATCH v3] " Ævar Arnfjörð Bjarmason
2017-03-29 18:12 ` Jeff King
2017-03-29 21:09 ` Ævar Arnfjörð Bjarmason
2017-03-29 21:13 ` Junio C Hamano
2017-03-29 22:22 ` Jeffrey Walton [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH8yC8mkndAWP46M2L7TX8HF_y4xa5X29-Q--bA6Prurpya48Q@mail.gmail.com \
--to=noloader@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=stefan.naewe@atlas-elektronik.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.
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 NNTP newsgroup(s).