Bug #111139 for Module-Build: Module::Build fails to bootstrap if PREFIX is set in environment

Tue Jan 12 19:34:17 2016 MAUKE [...] cpan.org - Ticket created

Subject:

Module::Build fails to bootstrap if PREFIX is set in environment

I have a freshly perlbrew'd 5.22.1, which I activated with 'perlbrew use ...'. I then ran 'cpan Module::Runtime' to install Module::Runtime. Module::Runtime uses Module::Build, so that was built/tested/installed first. Then Module::Runtime failed because Module::Build couldn't be loaded. This confused me. I then tried to install Module::Build directly, but I noticed that the "make install" step simply built the module without actually installing anything. (WTF?) I finally noticed that 'make install' skipped the install part because the files already existed at the target location, which was under ~/usr/lib/site_perl/, not under ~/perl5/perlbrew/perls/... (and that install location wasn't in my @INC either). So Module::Build boostrap-installs itself into a wrong location where it can't be found. As it turns out, I have a PREFIX variable in my environment set to "$HOME/usr". Module::Build::Compat uses that environment variable to set the prefix, which is why it breaks. ExtUtils::MakeMaker ignores that variable, so EUMM based modules install correctly. I checked the manual and neither Module::Build nor Module::Build::Compat document that the PREFIX environment variable has such a disastrous impact. I checked the ExtUtils::MakeMaker documentation, too, and it says nothing about it, because the generated Makefile ignores the environment variable (it sets its own PREFIX). Can you make Module::Build stop reading my unrelated environment variables?

Sat Aug 06 17:19:17 2016 LEONT [...] cpan.org - Correspondence added

On Tue Jan 12 19:34:17 2016, MAUKE wrote: Show quoted text

> I have a freshly perlbrew'd 5.22.1, which I activated with 'perlbrew > use ...'. I then ran 'cpan Module::Runtime' to install > Module::Runtime. Module::Runtime uses Module::Build, so that was > built/tested/installed first. Then Module::Runtime failed because > Module::Build couldn't be loaded. This confused me. > > I then tried to install Module::Build directly, but I noticed that the > "make install" step simply built the module without actually > installing anything. (WTF?) > > I finally noticed that 'make install' skipped the install part because > the files already existed at the target location, which was under > ~/usr/lib/site_perl/, not under ~/perl5/perlbrew/perls/... (and that > install location wasn't in my @INC either). So Module::Build boostrap- > installs itself into a wrong location where it can't be found. > > As it turns out, I have a PREFIX variable in my environment set to > "$HOME/usr". Module::Build::Compat uses that environment variable to > set the prefix, which is why it breaks. ExtUtils::MakeMaker ignores > that variable, so EUMM based modules install correctly. > > I checked the manual and neither Module::Build nor > Module::Build::Compat document that the PREFIX environment variable > has such a disastrous impact. I checked the ExtUtils::MakeMaker > documentation, too, and it says nothing about it, because the > generated Makefile ignores the environment variable (it sets its own > PREFIX). > > Can you make Module::Build stop reading my unrelated environment > variables?

Sorry for the slow reply, somehow this flew under my radar. I think the solution is to simple empty-define PREFIX (and 26 other variables) in the Makefile, so that they're only seen if they're overriden as make arguments and not when they're from the background environment. Leon

Sat Aug 06 17:19:17 2016 The RT System itself - Status changed from 'new' to 'open'

Mon Mar 27 18:03:08 2017 LEONT [...] cpan.org - Correspondence added

On Sat Aug 06 17:19:17 2016, LEONT wrote: Show quoted text

> On Tue Jan 12 19:34:17 2016, MAUKE wrote:

> > I have a freshly perlbrew'd 5.22.1, which I activated with 'perlbrew > > use ...'. I then ran 'cpan Module::Runtime' to install > > Module::Runtime. Module::Runtime uses Module::Build, so that was > > built/tested/installed first. Then Module::Runtime failed because > > Module::Build couldn't be loaded. This confused me. > > > > I then tried to install Module::Build directly, but I noticed that > > the > > "make install" step simply built the module without actually > > installing anything. (WTF?) > > > > I finally noticed that 'make install' skipped the install part > > because > > the files already existed at the target location, which was under > > ~/usr/lib/site_perl/, not under ~/perl5/perlbrew/perls/... (and that > > install location wasn't in my @INC either). So Module::Build > > boostrap- > > installs itself into a wrong location where it can't be found. > > > > As it turns out, I have a PREFIX variable in my environment set to > > "$HOME/usr". Module::Build::Compat uses that environment variable to > > set the prefix, which is why it breaks. ExtUtils::MakeMaker ignores > > that variable, so EUMM based modules install correctly. > > > > I checked the manual and neither Module::Build nor > > Module::Build::Compat document that the PREFIX environment variable > > has such a disastrous impact. I checked the ExtUtils::MakeMaker > > documentation, too, and it says nothing about it, because the > > generated Makefile ignores the environment variable (it sets its own > > PREFIX). > > > > Can you make Module::Build stop reading my unrelated environment > > variables?

> > Sorry for the slow reply, somehow this flew under my radar. I think > the solution is to simple empty-define PREFIX (and 26 other variables) > in the Makefile, so that they're only seen if they're overriden as > make arguments and not when they're from the background environment. > > Leon

This was fixed in 0.4220 :-) Leon

Mon Mar 27 18:03:09 2017 LEONT [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Mar 27 18:03:09 2017 LEONT [...] cpan.org - Fixed in 0.4220 added