>>> 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
