Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 111139
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: MAUKE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.4214
Fixed in: 0.4220



Subject: Module::Build fails to bootstrap if PREFIX is set in environment
Download (untitled) / with headers
text/plain 1.4k
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?
Download (untitled) / with headers
text/plain 1.8k
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
Download (untitled) / with headers
text/plain 1.9k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.