Skip Menu |

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

Report information
The Basics
Id: 51170
Status: open
Priority: 0/
Queue: Module-Build
People
Owner: Nobody in particular
Requestors: dolmen [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: 0.35
Fixed in: (no value)

History Show all quoted text
  Fri Nov 06 10:21:45 2009 dolmen [...] cpan.org - Ticket created
Subject: Adapt default install paths to local scheme (eg ActivePerl) when using --install_path
When using --install_path on ActivePerl 1003, Module::Build 0.35 uses the following default mapping: lib=$install_path/lib/perl5 arch=$install_path/lib/perl5/$Config{archname} However this scheme does not match the scheme that PPM uses for installing modules: lib=$install_path/lib arch=$install_path/lib So, to install modules from source we have to manually specify path mappings: perl Build.PL --install_base "%MYBASE%" --install_path "lib=%MYBASE%\lib" --install_path "arch=%MYBASE%\lib" This breaks the purpose of --install_base which is to set all paths at once. This problem does not apply to install in standard directories (perl/vendor/site). -- Olivier Mengué - http://o.mengue.free.fr/
  Fri Nov 06 13:16:17 2009 dagolden [...] cpan.org - Correspondence added
On Fri Nov 06 10:21:45 2009, DOLMEN wrote: Show quoted text
> This breaks the purpose of --install_base which is to set all paths at
once. My understanding is that the purpose of --install_base is to set the *base* of a predetermined hierarchy of installation paths. Given that any change would have to be coordinated with ExtUtils::MakeMaker, I'm skeptical that this is something to change at this point. The alternative approach you describe seems like the right way.
  Fri Nov 06 13:16:19 2009 The RT System itself - Status changed from 'new' to 'open'
  Wed Nov 11 02:13:23 2009 mschwern [...] cpan.org - Correspondence added
I agree with David. install_base exists so provide a set of simple, predictable, generally well behaved set of install locations. This is in direct contrast to MakeMaker's PREFIX which tries to guess based on the local install and is wildly unpredictable. Case in point, how would Module::Build guess the user's intent to install in a PPM compatible location? I'm sure we could come up with some heuristics, and I'm sure they'd introduce wacky edge cases that would muck up the simplicity of install_base. And changing the defaults to put both lib and arch into $install_base/lib is right out. We assume we're installing into a shared location and Perl politely puts its modules into their own directories to avoid cluttering lib. And not putting arch-specific files into a versioned directory prevents multiple incompatible versions of Perl from sharing a lib. I suspect the layout PPM is using is an artifact of ActiveState owning their whole directory tree. (MakeMaker used to have heuristics to guess if you were installing in a private Perl tree. They caused surprises and were removed.) Finally, I suspect this problem only arises if you're building a PPM which is far from the common case. Simply running "perl Build.PL" should be sufficient to DTRT and install a module for a normal ActiveState install. You can set default Module::Build switches in a .modulebuildrc. http://search.cpan.org/perldoc/Module-Build/lib/Module/Build.pm#Default_Options_File_%28.modulebuildrc%29
  Thu Nov 12 05:16:20 2009 dolmen [...] cpan.org - Correspondence added
Le Mer. Nov. 11 02:13:23 2009, MSCHWERN a écrit : Show quoted text
> I agree with David. install_base exists so provide a set of simple, > predictable, generally well behaved set of install locations. This is > in direct contrast to MakeMaker's PREFIX which tries to guess based on > the local install and is wildly unpredictable. > > Case in point, how would Module::Build guess the user's intent to > install in a PPM compatible location? I'm sure we could come up with > some heuristics, and I'm sure they'd introduce wacky edge cases that > would muck up the simplicity of install_base.
I understand the rationale. Show quoted text
> I suspect the layout PPM is using is an > artifact of ActiveState owning their whole directory tree.
I confirm. Show quoted text
> Finally, I suspect this problem only arises if you're building a PPM > which is far from the common case. Simply running "perl Build.PL" > should be sufficient to DTRT and install a module for a normal > ActiveState install.
The problem is not building PPM. My distribution is an application (not just a module) that I prefer to install in a separate directory (not in 'site'). In this directory I want to install both PPM and my in-development code (for which 'Build install' is faster than building a PPM and installing it). The problem I have is to make "Build.PL install" easy for the developper who would like to test the application. --install_path is standard. But forgetting to set arch/lib is easy for the developper. Show quoted text
> You can set default Module::Build switches in a .modulebuildrc.
This does not work in my use case because I would have to give an absolute path to set lib/arch. But I want to set them only for the distribution I'm working on. Not for any distribution I install (most will go in 'site'). Also .modulebuildrc is a common a user setting so it would apply to all installed Perls: ActivePerl and Strawberry. My distribution is in the DarkPAN, so I can do any dirty things I want in Build.PL. So, is there a way to force in my Build.PL that 'lib' and 'arch' are $install_path/lib? An other thing I would like to do is to fail install if 'lib' and 'arch' are not in @INC. How could I implement this? -- Olivier Mengué - http://o.mengue.free.fr/
  Thu Nov 12 07:51:45 2009 dagolden [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #51170] Adapt default install paths to local scheme (eg ActivePerl) when using --install_path
Date: Thu, 12 Nov 2009 07:50:54 -0500
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
2009/11/12 Olivier 'dolmen' Mengué via RT <bug-Module-Build@rt.cpan.org>: Show quoted text
> My distribution is in the DarkPAN, so I can do any dirty things I want > in Build.PL. So, is there a way to force in my Build.PL that 'lib' and > 'arch' are $install_path/lib? > An other thing I would like to do is to fail install if 'lib' and 'arch' > are not in @INC. How could I implement this?
Anything that you would put on the command line you can also put in the arguments to new(). So in your Build.PL, just figure out your paths, die if they aren't in @INC, and you should be able to add this to new(): install_path => { lib => $your_lib arch => $your_arch } Those should override the defaults. Please try it and let me know. (The code for this inside Module::Build is pretty complicated and I'm answering from vague memory rather than looking it up.) The other alternative would be to use a subclass of Module::Build instead, but I suspect some form like the above should do what you want.