{"thread":{"id":"45533","subject":"Can't locate ExtUtils/MakeMaker.pm in @INC","startedAt":"2017-03-29T01:04:14Z","lastAt":"2017-03-29T22:22:31Z","messageCount":10,"participants":["Jeffrey Walton","Jeff King","Ævar Arnfjörð Bjarmason","stefan.naewe@atlas-elektronik.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"315643","messageId":"CAH8yC8kpKii+FNZEUqDqLcuEWBsTTnrqMHq_3VLdAzcpDSKFww@mail.gmail.com","threadId":"45533","inReplyTo":null,"subject":"Can't locate ExtUtils/MakeMaker.pm in @INC","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2017-03-29T01:03:43Z","receivedAt":"2017-03-29T01:04:14Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"This looks like the last issue with Git 2.12.2. This time the machine\nis Fedora 25.\n\nI configured with PERL_PATH=/usr/local/bin/perl. The local Perl was\nbuilt specifically for this error, and it includes\nExtUtils/MakeMaker.pm:\n\n$ find /usr/local -name MakeMaker.pm\n/usr/local/lib/perl5/5.24.1/ExtUtils/MakeMaker.pm\n\n$ make all\n...\n\n GEN git-bisect\n GEN git-difftool--helper\n GEN git-filter-branch\n GEN git-merge-octopus\n GEN git-merge-one-file\n GEN git-merge-resolve\n GEN git-mergetool\n GEN git-quiltimport\n GEN git-rebase\n GEN git-request-pull\n GEN git-stash\n GEN git-submodule\n GEN git-web--browse\n SUBDIR perl\n/usr/bin/perl Makefile.PL PREFIX='/usr/local' INSTALL_BASE=''\n--localedir='/usr/local/share/locale'\n GEN git-p4\nCan't locate ExtUtils/MakeMaker.pm in @INC (you may need to install\nthe ExtUtils::MakeMaker module) (@INC contains: /usr/local/lib64/perl5\n/usr/local/share/perl5 /usr/lib64/perl5/vendor_perl\n/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at\nMakefile.PL line 3.\nBEGIN failed--compilation aborted at Makefile.PL line 3.\nMakefile:83: recipe for target 'perl.mak' failed\nmake[1]: *** [perl.mak] Error 2\nMakefile:1843: recipe for target 'perl/perl.mak' failed\nmake: *** [perl/perl.mak] Error 2\nmake: *** Waiting for unfinished jobs....\nFailed to build Git\n\n/usr/local/bin/perl is on path but Git is using the old one in /usr/bin:\n\n $ which perl\n /usr/local/bin/perl\n\nIt appears Git is not honoring the request for the updated Perl.\n\nThanks,\n"},{"id":"315646","messageId":"20170329021807.voys2r65knn6tdwg@sigill.intra.peff.net","threadId":"45533","inReplyTo":"CAH8yC8kpKii+FNZEUqDqLcuEWBsTTnrqMHq_3VLdAzcpDSKFww@mail.gmail.com","subject":"Re: Can't locate ExtUtils/MakeMaker.pm in @INC","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-29T02:18:07Z","receivedAt":"2017-03-29T02:18:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 28, 2017 at 09:03:43PM -0400, Jeffrey Walton wrote:\n\n> This looks like the last issue with Git 2.12.2. This time the machine\n> is Fedora 25.\n> \n> I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was\n> built specifically for this error, and it includes\n> ExtUtils/MakeMaker.pm:\n\nI'm not sure what \"configured with PERL_PATH\" means exactly. If you did:\n\n PERL_PATH=/usr/local/bin/perl ./configure\n\nthen I don't think that works. The way to tell configure that you want\nto use a specific version of perl is with a command-line option:\n\n ./configure --with-perl=/usr/local/bin/perl\n\nWhen you're running make itself, you can override the default (or what\nwas specified during configure) with:\n\n make PERL_PATH=/usr/local/bin/perl\n\nBoth of the latter two work for me:\n\n $ ./configure --with-perl=/perl/from/configure\n [...]\n $ make\n [...]\n /perl/from/configure Makefile.PL PREFIX='/home/peff/local/git/master' INSTALL_BASE='' --localedir='/home/peff/local/git/master/share/locale'\n make[1]: /perl/from/configure: Command not found\n\n $ make PERL_PATH=/perl/from/make\n [...]\n /perl/from/make Makefile.PL PREFIX='/home/peff/local/git/master' INSTALL_BASE='' --localedir='/home/peff/local/git/master/share/locale'\n make[1]: /perl/from/make: Command not found\n\nObviously those are nonsense, but they quickly show that we're using the\nrequested version of perl.\n\n-Peff\n"},{"id":"315665","messageId":"20170329132924.31321-1-avarab@gmail.com","threadId":"45533","inReplyTo":"20170329021807.voys2r65knn6tdwg@sigill.intra.peff.net","subject":"[PATCH] perl: regenerate perl.mak if perl -V changes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-29T13:29:24Z","receivedAt":"2017-03-29T13:29:42Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change the perl/perl.mak build process so that the file is re-made if\nthe output of \"perl -V\" changes.\n\nBefore this change updating e.g. /usr/bin/perl to a new major version\nwould cause the next \"make\" command to fail, since perl.mak has\nhardcoded paths to perl library paths retrieved from its first run.\n\nNow the logic added in commit ee9be06770 (\"perl: detect new files in\nMakeMaker builds\", 2012-07-27) is extended to regeneratio\nperl/perl.mak if there's any change to \"perl -V\".\n\nThis will in some cases redundantly trigger perl/perl.mak to be\nre-made, e.g. if @INC is modified in ways the build process doesn't\ncare about through sitecustomize.pl, but the common case is that we\njust do the right thing and re-generate perl/perl.mak when needed.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n\nOn Wed, Mar 29, 2017 at 4:18 AM, Jeff King wrote:\n> On Tue, Mar 28, 2017 at 09:03:43PM -0400, Jeffrey Walton wrote:\n>[...]\n\nAt first I thought Jeffrey was running into this longstanding issue\nwith the perl Makefile. Looks like not, and he just wasn't passing\nPERL_PATH correctly, but fix this related issue while it's fresh in my\nmind.\n\n Makefile | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/Makefile b/Makefile\nindex c80fec2920..c0c5510238 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1850,6 +1850,7 @@ perl/perl.mak: perl/PM.stamp\n \n perl/PM.stamp: FORCE\n \t@$(FIND) perl -type f -name '*.pm' | sort >$@+ && \\\n+\t$(PERL_PATH) -V >$@+ && \\\n \t{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; } && \\\n \t$(RM) $@+\n \n-- \n2.11.0\n\n"},{"id":"315666","messageId":"20170329133359.5992-1-avarab@gmail.com","threadId":"45533","inReplyTo":"20170329132924.31321-1-avarab@gmail.com","subject":"[PATCH v2] perl: regenerate perl.mak if perl -V changes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-29T13:33:59Z","receivedAt":"2017-03-29T13:34:33Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change the perl/perl.mak build process so that the file is re-made if\nthe output of \"perl -V\" changes.\n\nBefore this change updating e.g. /usr/bin/perl to a new major version\nwould cause the next \"make\" command to fail, since perl.mak has\nhardcoded paths to perl library paths retrieved from its first run.\n\nNow the logic added in commit ee9be06770 (\"perl: detect new files in\nMakeMaker builds\", 2012-07-27) is extended to regeneratio\nperl/perl.mak if there's any change to \"perl -V\".\n\nThis will in some cases redundantly trigger perl/perl.mak to be\nre-made, e.g. if @INC is modified in ways the build process doesn't\ncare about through sitecustomize.pl, but the common case is that we\njust do the right thing and re-generate perl/perl.mak when needed.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n\nMaybe this'll set some sort of record for a v2 submission, but anyway,\nthis should clearly be >> not >, we don't want to overwrite the list\nof *.pm files we just added.\n\n Makefile | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/Makefile b/Makefile\nindex 9f8b35ad41..485c453ca2 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1851,6 +1851,7 @@ perl/perl.mak: perl/PM.stamp\n \n perl/PM.stamp: FORCE\n \t@$(FIND) perl -type f -name '*.pm' | sort >$@+ && \\\n+\t$(PERL_PATH) -V >>$@+ && \\\n \t{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; } && \\\n \t$(RM) $@+\n \n-- \n2.11.0\n\n"},{"id":"315667","messageId":"39b203e9-c3a9-80c3-ec24-649e04ef5620@atlas-elektronik.com","threadId":"45533","inReplyTo":"20170329133359.5992-1-avarab@gmail.com","subject":"Re: [PATCH v2] perl: regenerate perl.mak if perl -V changes","fromName":"","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2017-03-29T13:36:37Z","receivedAt":"2017-03-29T13:36:50Z","isPatch":true,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 29.03.2017 um 15:33 schrieb Ævar Arnfjörð Bjarmason:\n> Change the perl/perl.mak build process so that the file is re-made if\n> the output of \"perl -V\" changes.\n> \n> Before this change updating e.g. /usr/bin/perl to a new major version\n> would cause the next \"make\" command to fail, since perl.mak has\n> hardcoded paths to perl library paths retrieved from its first run.\n> \n> Now the logic added in commit ee9be06770 (\"perl: detect new files in\n> MakeMaker builds\", 2012-07-27) is extended to regeneratio\n\ns/regeneratio/regenerate/\n\n> [...]\n\n\n/S\n-- \n----------------------------------------------------------------\n/dev/random says: HELP! I need a tagline. HELP! Not just any tagline.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\" \nGPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF"},{"id":"315668","messageId":"20170329135703.18860-1-avarab@gmail.com","threadId":"45533","inReplyTo":"39b203e9-c3a9-80c3-ec24-649e04ef5620@atlas-elektronik.com","subject":"[PATCH v3] perl: regenerate perl.mak if perl -V changes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-29T13:57:03Z","receivedAt":"2017-03-29T13:57:19Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change the perl/perl.mak build process so that the file is regenerated\nif the output of \"perl -V\" changes.\n\nBefore this change updating e.g. /usr/bin/perl to a new major version\nwould cause the next \"make\" command to fail, since perl.mak has\nhardcoded paths to perl library paths retrieved from its first run.\n\nNow the logic added in commit ee9be06770 (\"perl: detect new files in\nMakeMaker builds\", 2012-07-27) is extended to regenerate\nperl/perl.mak if there's any change to \"perl -V\".\n\nThis will in some cases redundantly trigger perl/perl.mak to be\nre-made, e.g. if @INC is modified in ways the build process doesn't\ncare about through sitecustomize.pl, but the common case is that we\njust do the right thing and re-generate perl/perl.mak when needed.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n\nOn Wed, Mar 29, 2017 at 3:36 PM, wrote:\n> Am 29.03.2017 um 15:33 schrieb Ævar Arnfjörð Bjarmason:\n> [...]\n>> Now the logic added in commit ee9be06770 (\"perl: detect new files in\n>> MakeMaker builds\", 2012-07-27) is extended to regeneratio\n>\n> s/regeneratio/regenerate/\n>\n>> [...]\n>\n>\n> /S\n\nThanks!\n\n\n Makefile | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/Makefile b/Makefile\nindex 9f8b35ad41..485c453ca2 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1851,6 +1851,7 @@ perl/perl.mak: perl/PM.stamp\n \n perl/PM.stamp: FORCE\n \t@$(FIND) perl -type f -name '*.pm' | sort >$@+ && \\\n+\t$(PERL_PATH) -V >>$@+ && \\\n \t{ cmp $@+ $@ >/dev/null 2>/dev/null || mv $@+ $@; } && \\\n \t$(RM) $@+\n \n-- \n2.11.0\n\n"},{"id":"315694","messageId":"20170329181228.n4t77pashdnirl3a@sigill.intra.peff.net","threadId":"45533","inReplyTo":"20170329135703.18860-1-avarab@gmail.com","subject":"Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-29T18:12:29Z","receivedAt":"2017-03-29T18:12:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 29, 2017 at 01:57:03PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> Change the perl/perl.mak build process so that the file is regenerated\n> if the output of \"perl -V\" changes.\n> \n> Before this change updating e.g. /usr/bin/perl to a new major version\n> would cause the next \"make\" command to fail, since perl.mak has\n> hardcoded paths to perl library paths retrieved from its first run.\n\nThis is one of those things that has been bugging me for years, but it\ncomes up so rarely that I have never dug into it.\n\n> Now the logic added in commit ee9be06770 (\"perl: detect new files in\n> MakeMaker builds\", 2012-07-27) is extended to regenerate\n> perl/perl.mak if there's any change to \"perl -V\".\n\nNice. This fix is way simpler than I feared.\n\n> This will in some cases redundantly trigger perl/perl.mak to be\n> re-made, e.g. if @INC is modified in ways the build process doesn't\n> care about through sitecustomize.pl, but the common case is that we\n> just do the right thing and re-generate perl/perl.mak when needed.\n\nI think that's fine. There's a related bug that the generation of\nperl/perl.mak via recursive-make is sometimes racy. So that _might_\ntrigger more often as a result of this, but I think the solution is to\nfix that race, not try to pretend it won't happen. :)\n\n-Peff\n"},{"id":"315705","messageId":"CACBZZX70oXn7McjavzvK5S30EXjXQhLixhb=WYbKCKYXVo1KBA@mail.gmail.com","threadId":"45533","inReplyTo":"20170329181228.n4t77pashdnirl3a@sigill.intra.peff.net","subject":"Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-29T21:09:28Z","receivedAt":"2017-03-29T21:10:01Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Mar 29, 2017 at 8:12 PM, Jeff King wrote:\n> On Wed, Mar 29, 2017 at 01:57:03PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Change the perl/perl.mak build process so that the file is regenerated\n>> if the output of \"perl -V\" changes.\n>>\n>> Before this change updating e.g. /usr/bin/perl to a new major version\n>> would cause the next \"make\" command to fail, since perl.mak has\n>> hardcoded paths to perl library paths retrieved from its first run.\n>\n> This is one of those things that has been bugging me for years, but it\n> comes up so rarely that I have never dug into it.\n\nGlad to help. I've only run into this once a couple of days ago, made\na mental note to fix it, and then I saw that thread...\n\n>> Now the logic added in commit ee9be06770 (\"perl: detect new files in\n>> MakeMaker builds\", 2012-07-27) is extended to regenerate\n>> perl/perl.mak if there's any change to \"perl -V\".\n>\n> Nice. This fix is way simpler than I feared.\n>\n>> This will in some cases redundantly trigger perl/perl.mak to be\n>> re-made, e.g. if @INC is modified in ways the build process doesn't\n>> care about through sitecustomize.pl, but the common case is that we\n>> just do the right thing and re-generate perl/perl.mak when needed.\n>\n> I think that's fine. There's a related bug that the generation of\n> perl/perl.mak via recursive-make is sometimes racy. So that _might_\n> trigger more often as a result of this, but I think the solution is to\n> fix that race, not try to pretend it won't happen. :)\n\nWe'll also redundantly trigger if you upgrade to a minor new perl\nversion, but I think that's squarely in \"who cares\" territory. This'll\nonly impact people working on git, and *occasionally* they might get a\n100 ms hit when running make, as opposed to a cryptic error where\nthey'll likely stare at it for a bit before running \"make clean\".\n\nIf we were being more pedantic we could only bust the cache on major\nperl version upgrades:\n\n perl -e 'print substr($], 0, 5), \"\\n\"' >>PM.stamp+\n\nOr use Config.pm:\n\n perl -MConfig -e 'print @Config{qw(api_revision api_version)},\n\"\\n\"' >>PM.stamp+\n\nBut I think overall leaning on the side of busting the cache more\noften to avoid cryptic errors is the right choice, and we should use\n\"perl -V\".\n"},{"id":"315706","messageId":"xmqq7f37airn.fsf@gitster.mtv.corp.google.com","threadId":"45533","inReplyTo":"CACBZZX70oXn7McjavzvK5S30EXjXQhLixhb=WYbKCKYXVo1KBA@mail.gmail.com","subject":"Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-29T21:13:32Z","receivedAt":"2017-03-29T21:13:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> We'll also redundantly trigger if you upgrade to a minor new perl\n> version, but I think that's squarely in \"who cares\" territory.\n> ...\n> But I think overall leaning on the side of busting the cache more\n> often to avoid cryptic errors is the right choice, and we should use\n> \"perl -V\".\n\nI'd throw it into \"better safe than sorry\" category. I think we all\nlike the approach this patch takes. Let's queue it and merge it\ndown soonish.\n\nThanks.\n\n"},{"id":"315714","messageId":"CAH8yC8mkndAWP46M2L7TX8HF_y4xa5X29-Q--bA6Prurpya48Q@mail.gmail.com","threadId":"45533","inReplyTo":"CACBZZX70oXn7McjavzvK5S30EXjXQhLixhb=WYbKCKYXVo1KBA@mail.gmail.com","subject":"Re: [PATCH v3] perl: regenerate perl.mak if perl -V changes","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2017-03-29T22:22:26Z","receivedAt":"2017-03-29T22:22:31Z","isPatch":true,"sender":{"key":"noloader@gmail.com","avatar":null},"body":">>> Now the logic added in commit ee9be06770 (\"perl: detect new files in\n>>> MakeMaker builds\", 2012-07-27) is extended to regenerate\n>>> perl/perl.mak if there's any change to \"perl -V\".\n>>\n>> Nice. This fix is way simpler than I feared.\n>>\n>>> This will in some cases redundantly trigger perl/perl.mak to be\n>>> re-made, e.g. if @INC is modified in ways the build process doesn't\n>>> care about through sitecustomize.pl, but the common case is that we\n>>> just do the right thing and re-generate perl/perl.mak when needed.\n>>\n>> I think that's fine. There's a related bug that the generation of\n>> perl/perl.mak via recursive-make is sometimes racy. So that _might_\n>> trigger more often as a result of this, but I think the solution is to\n>> fix that race, not try to pretend it won't happen. :)\n>\n> We'll also redundantly trigger if you upgrade to a minor new perl\n> version, but I think that's squarely in \"who cares\" territory. This'll\n> only impact people working on git, and *occasionally* they might get a\n> 100 ms hit when running make, as opposed to a cryptic error where\n> they'll likely stare at it for a bit before running \"make clean\".\n\n+1, I don't mind extra config or build times as long as things \"just\nwork\" for the common case.\n\nI was trying to figure out the use case that I was seeing. I was\nenvisioning someone with Perl 4 in /usr/local who complained it would\nbreak some one-off setup. In the common case, the guy running Perl 4\nshould do the extra work, not the majority of users operating under\nthe common case.\n\nJeff\n"}]}