* Can't locate ExtUtils/MakeMaker.pm in @INC
@ 2017-03-29 1:03 Jeffrey Walton
2017-03-29 2:18 ` Jeff King
0 siblings, 1 reply; 10+ messages in thread
From: Jeffrey Walton @ 2017-03-29 1:03 UTC (permalink / raw)
To: Git List
This looks like the last issue with Git 2.12.2. This time the machine
is Fedora 25.
I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was
built specifically for this error, and it includes
ExtUtils/MakeMaker.pm:
$ find /usr/local -name MakeMaker.pm
/usr/local/lib/perl5/5.24.1/ExtUtils/MakeMaker.pm
$ make all
...
GEN git-bisect
GEN git-difftool--helper
GEN git-filter-branch
GEN git-merge-octopus
GEN git-merge-one-file
GEN git-merge-resolve
GEN git-mergetool
GEN git-quiltimport
GEN git-rebase
GEN git-request-pull
GEN git-stash
GEN git-submodule
GEN git-web--browse
SUBDIR perl
/usr/bin/perl Makefile.PL PREFIX='/usr/local' INSTALL_BASE=''
--localedir='/usr/local/share/locale'
GEN git-p4
Can't locate ExtUtils/MakeMaker.pm in @INC (you may need to install
the ExtUtils::MakeMaker module) (@INC contains: /usr/local/lib64/perl5
/usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
Makefile.PL line 3.
BEGIN failed--compilation aborted at Makefile.PL line 3.
Makefile:83: recipe for target 'perl.mak' failed
make[1]: *** [perl.mak] Error 2
Makefile:1843: recipe for target 'perl/perl.mak' failed
make: *** [perl/perl.mak] Error 2
make: *** Waiting for unfinished jobs....
Failed to build Git
/usr/local/bin/perl is on path but Git is using the old one in /usr/bin:
$ which perl
/usr/local/bin/perl
It appears Git is not honoring the request for the updated Perl.
Thanks,
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Can't locate ExtUtils/MakeMaker.pm in @INC
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
0 siblings, 1 reply; 10+ messages in thread
From: Jeff King @ 2017-03-29 2:18 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: Git List
On Tue, Mar 28, 2017 at 09:03:43PM -0400, Jeffrey Walton wrote:
> This looks like the last issue with Git 2.12.2. This time the machine
> is Fedora 25.
>
> I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was
> built specifically for this error, and it includes
> ExtUtils/MakeMaker.pm:
I'm not sure what "configured with PERL_PATH" means exactly. If you did:
PERL_PATH=/usr/local/bin/perl ./configure
then I don't think that works. The way to tell configure that you want
to use a specific version of perl is with a command-line option:
./configure --with-perl=/usr/local/bin/perl
When you're running make itself, you can override the default (or what
was specified during configure) with:
make PERL_PATH=/usr/local/bin/perl
Both of the latter two work for me:
$ ./configure --with-perl=/perl/from/configure
[...]
$ make
[...]
/perl/from/configure Makefile.PL PREFIX='/home/peff/local/git/master' INSTALL_BASE='' --localedir='/home/peff/local/git/master/share/locale'
make[1]: /perl/from/configure: Command not found
$ make PERL_PATH=/perl/from/make
[...]
/perl/from/make Makefile.PL PREFIX='/home/peff/local/git/master' INSTALL_BASE='' --localedir='/home/peff/local/git/master/share/locale'
make[1]: /perl/from/make: Command not found
Obviously those are nonsense, but they quickly show that we're using the
requested version of perl.
-Peff
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] perl: regenerate perl.mak if perl -V changes
2017-03-29 2:18 ` Jeff King
@ 2017-03-29 13:29 ` Ævar Arnfjörð Bjarmason
2017-03-29 13:33 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2017-03-29 13:29 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Jeffrey Walton,
Ævar Arnfjörð Bjarmason
Change the perl/perl.mak build process so that the file is re-made if
the output of "perl -V" changes.
Before this change updating e.g. /usr/bin/perl to a new major version
would cause the next "make" command to fail, since perl.mak has
hardcoded paths to perl library paths retrieved from its first run.
Now the logic added in commit ee9be06770 ("perl: detect new files in
MakeMaker builds", 2012-07-27) is extended to regeneratio
perl/perl.mak if there's any change to "perl -V".
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.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
On Wed, Mar 29, 2017 at 4:18 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 28, 2017 at 09:03:43PM -0400, Jeffrey Walton wrote:
>[...]
At first I thought Jeffrey was running into this longstanding issue
with the perl Makefile. Looks like not, and he just wasn't passing
PERL_PATH correctly, but fix this related issue while it's fresh in my
mind.
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index c80fec2920..c0c5510238 100644
--- a/Makefile
+++ b/Makefile
@@ -1850,6 +1850,7 @@ perl/perl.mak: perl/PM.stamp
perl/PM.stamp: FORCE
@$(FIND) perl -type f -name '*.pm' | sort >$@+ && \
+ $(PERL_PATH) -V >$@+ && \
{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; } && \
$(RM) $@+
--
2.11.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v2] perl: regenerate perl.mak if perl -V changes
2017-03-29 13:29 ` [PATCH] perl: regenerate perl.mak if perl -V changes Ævar Arnfjörð Bjarmason
@ 2017-03-29 13:33 ` Ævar Arnfjörð Bjarmason
2017-03-29 13:36 ` stefan.naewe
0 siblings, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2017-03-29 13:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Jeffrey Walton,
Ævar Arnfjörð Bjarmason
Change the perl/perl.mak build process so that the file is re-made if
the output of "perl -V" changes.
Before this change updating e.g. /usr/bin/perl to a new major version
would cause the next "make" command to fail, since perl.mak has
hardcoded paths to perl library paths retrieved from its first run.
Now the logic added in commit ee9be06770 ("perl: detect new files in
MakeMaker builds", 2012-07-27) is extended to regeneratio
perl/perl.mak if there's any change to "perl -V".
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.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Maybe this'll set some sort of record for a v2 submission, but anyway,
this should clearly be >> not >, we don't want to overwrite the list
of *.pm files we just added.
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 9f8b35ad41..485c453ca2 100644
--- a/Makefile
+++ b/Makefile
@@ -1851,6 +1851,7 @@ perl/perl.mak: perl/PM.stamp
perl/PM.stamp: FORCE
@$(FIND) perl -type f -name '*.pm' | sort >$@+ && \
+ $(PERL_PATH) -V >>$@+ && \
{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; } && \
$(RM) $@+
--
2.11.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2] perl: regenerate perl.mak if perl -V changes
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
0 siblings, 1 reply; 10+ messages in thread
From: stefan.naewe @ 2017-03-29 13:36 UTC (permalink / raw)
To: avarab, git; +Cc: gitster, peff, noloader
Am 29.03.2017 um 15:33 schrieb Ævar Arnfjörð Bjarmason:
> Change the perl/perl.mak build process so that the file is re-made if
> the output of "perl -V" changes.
>
> Before this change updating e.g. /usr/bin/perl to a new major version
> would cause the next "make" command to fail, since perl.mak has
> hardcoded paths to perl library paths retrieved from its first run.
>
> Now the logic added in commit ee9be06770 ("perl: detect new files in
> MakeMaker builds", 2012-07-27) is extended to regeneratio
s/regeneratio/regenerate/
> [...]
/S
--
----------------------------------------------------------------
/dev/random says: HELP! I need a tagline. HELP! Not just any tagline.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3] perl: regenerate perl.mak if perl -V changes
2017-03-29 13:36 ` stefan.naewe
@ 2017-03-29 13:57 ` Ævar Arnfjörð Bjarmason
2017-03-29 18:12 ` Jeff King
0 siblings, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2017-03-29 13:57 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Jeffrey Walton, stefan.naewe,
Ævar Arnfjörð Bjarmason
Change the perl/perl.mak build process so that the file is regenerated
if the output of "perl -V" changes.
Before this change updating e.g. /usr/bin/perl to a new major version
would cause the next "make" command to fail, since perl.mak has
hardcoded paths to perl library paths retrieved from its first run.
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".
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.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
On Wed, Mar 29, 2017 at 3:36 PM, <stefan.naewe@atlas-elektronik.com> wrote:
> Am 29.03.2017 um 15:33 schrieb Ævar Arnfjörð Bjarmason:
> [...]
>> Now the logic added in commit ee9be06770 ("perl: detect new files in
>> MakeMaker builds", 2012-07-27) is extended to regeneratio
>
> s/regeneratio/regenerate/
>
>> [...]
>
>
> /S
Thanks!
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 9f8b35ad41..485c453ca2 100644
--- a/Makefile
+++ b/Makefile
@@ -1851,6 +1851,7 @@ perl/perl.mak: perl/PM.stamp
perl/PM.stamp: FORCE
@$(FIND) perl -type f -name '*.pm' | sort >$@+ && \
+ $(PERL_PATH) -V >>$@+ && \
{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; } && \
$(RM) $@+
--
2.11.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes
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
0 siblings, 1 reply; 10+ messages in thread
From: Jeff King @ 2017-03-29 18:12 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Jeffrey Walton, stefan.naewe
On Wed, Mar 29, 2017 at 01:57:03PM +0000, Ævar Arnfjörð Bjarmason wrote:
> Change the perl/perl.mak build process so that the file is regenerated
> if the output of "perl -V" changes.
>
> Before this change updating e.g. /usr/bin/perl to a new major version
> would cause the next "make" command to fail, since perl.mak has
> hardcoded paths to perl library paths retrieved from its first run.
This is one of those things that has been bugging me for years, but it
comes up so rarely that I have never dug into it.
> 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. :)
-Peff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes
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
0 siblings, 2 replies; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2017-03-29 21:09 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano, Jeffrey Walton, stefan.naewe
On Wed, Mar 29, 2017 at 8:12 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Mar 29, 2017 at 01:57:03PM +0000, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the perl/perl.mak build process so that the file is regenerated
>> if the output of "perl -V" changes.
>>
>> Before this change updating e.g. /usr/bin/perl to a new major version
>> would cause the next "make" command to fail, since perl.mak has
>> hardcoded paths to perl library paths retrieved from its first run.
>
> This is one of those things that has been bugging me for years, but it
> comes up so rarely that I have never dug into it.
Glad to help. I've only run into this once a couple of days ago, made
a mental note to fix it, and then I saw that thread...
>> 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".
If we were being more pedantic we could only bust the cache on major
perl version upgrades:
perl -e 'print substr($], 0, 5), "\n"' >>PM.stamp+
Or use Config.pm:
perl -MConfig -e 'print @Config{qw(api_revision api_version)},
"\n"' >>PM.stamp+
But I think overall leaning on the side of busting the cache more
often to avoid cryptic errors is the right choice, and we should use
"perl -V".
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes
2017-03-29 21:09 ` Ævar Arnfjörð Bjarmason
@ 2017-03-29 21:13 ` Junio C Hamano
2017-03-29 22:22 ` Jeffrey Walton
1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2017-03-29 21:13 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jeff King, Git Mailing List, Jeffrey Walton, stefan.naewe
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> We'll also redundantly trigger if you upgrade to a minor new perl
> version, but I think that's squarely in "who cares" territory.
> ...
> But I think overall leaning on the side of busting the cache more
> often to avoid cryptic errors is the right choice, and we should use
> "perl -V".
I'd throw it into "better safe than sorry" category. I think we all
like the approach this patch takes. Let's queue it and merge it
down soonish.
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes
2017-03-29 21:09 ` Ævar Arnfjörð Bjarmason
2017-03-29 21:13 ` Junio C Hamano
@ 2017-03-29 22:22 ` Jeffrey Walton
1 sibling, 0 replies; 10+ messages in thread
From: Jeffrey Walton @ 2017-03-29 22:22 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jeff King, Git Mailing List, Junio C Hamano, stefan.naewe
>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-03-29 22:22 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.