Re: EUMM and Module::Build installations - Oh God, Help!
--- David Golden [EMAIL PROTECTED] wrote:
I think that if you 'use lib qq{$ROOT/lib/perl5}' then the
architecture directory gets added automatically. (According to
'perldoc lib').
Yes, that's correct. I still don't think those belong in the same
directory, but that's just me :)
Maybe I just don't understand what you're trying to do well enough to
see why architecture specific directories are a problem. (XY
problem?)
It might *be* an XY problem. We already has a directory layout for
external modules and we were trying to get CPAN to install to that
layout rather than try reorganize all of our dependencies and hope that
nothing broke.
As note, we went with the reorganization, despite other useful
suggestions from here. Going the 'INSTALL_BASE' route was a one-time
pain (we hope :)
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
EUMM and Module::Build installations - Oh God, Help!
At work, we ship our dependencies with our code. As it turns out, everyone installs these dependencies in slightly different ways because no one can *quite* figure out how to configure CPAN to handle this for us. What we would like, and having it work for both EUMM and Module::Build, is to make our installation look like this: $ROOT/lib/ $ROOT/arch/lib $ROOT/bin/ $ROOT/man/man1/ $ROOT/man/man3/ (We've gotten close to the above, but the .packlist files keep getting shoved in /opt/csw/lib/perl/site_perl/auto/... and CPAN screams at us). Is there some script out there which will properly configure CPAN::Config to give us fine-grained control over all of this? Is there something I've missed in the above? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: EUMM and Module::Build installations - Oh God, Help!
On Fri, 2007-12-21 at 03:36 -0800, Ovid wrote: Is there some script out there which will properly configure CPAN::Config to give us fine-grained control over all of this? Is there something I've missed in the above? local::lib is close, although it just changes the PREFIX (for EUMM and MB). http://search.cpan.org/~apeiron/local-lib-1.001000/lib/local/lib.pm Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: EUMM and Module::Build installations - Oh God, Help!
On Dec 21, 2007 6:36 AM, Ovid [EMAIL PROTECTED] wrote: At work, we ship our dependencies with our code. As it turns out, everyone installs these dependencies in slightly different ways because no one can *quite* figure out how to configure CPAN to handle this for us. What we would like, and having it work for both EUMM and Module::Build, is to make our installation look like this: $ROOT/lib/ $ROOT/arch/lib $ROOT/bin/ $ROOT/man/man1/ $ROOT/man/man3/ (We've gotten close to the above, but the .packlist files keep getting shoved in /opt/csw/lib/perl/site_perl/auto/... and CPAN screams at us). Is this not just --install_base (M::B) or INSTALL_BASE (recent EU::MM)? If the packlist is showing up in the wrong place, it may just be a bug. David
Re: EUMM and Module::Build installations - Oh God, Help!
--- David Golden [EMAIL PROTECTED] wrote:
$ROOT/lib/
$ROOT/arch/lib
$ROOT/bin/
$ROOT/man/man1/
$ROOT/man/man3/
Is this not just --install_base (M::B) or INSTALL_BASE (recent
EU::MM)?
No, --install_base looks like this:
$ROOT/lib/perl5/$Config{archname}
$ROOT/lib/perl5
$ROOT/bin
$ROOT/man/man1
$ROOT/man/man3
Which means that you have architecture specific stuff in your lib/perl5
directory. So for a mac you might have something like:
$ROOT/lib/perl5/darwin-2level/Encode/Alias.pm
I don't know that someone could get Perl to try to load a package named
package darwin-2level::Encode::Alias since that's not a legal package
name, but I don't know that all architectures could have names which
aren't legal package names. I'd prefer them to be in separate
directories.
That being said, we've bit the bullet and rearranged our libraries to
fit '--install-base'. There's some short term pain there, but in the
long run, it seems like a win.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Re: EUMM and Module::Build installations - Oh God, Help!
On Dec 21, 2007 4:25 PM, Ovid [EMAIL PROTECTED] wrote:
No, --install_base looks like this:
$ROOT/lib/perl5/$Config{archname}
$ROOT/lib/perl5
$ROOT/bin
$ROOT/man/man1
$ROOT/man/man3
Which means that you have architecture specific stuff in your lib/perl5
directory. So for a mac you might have something like:
$ROOT/lib/perl5/darwin-2level/Encode/Alias.pm
I don't know that someone could get Perl to try to load a package named
package darwin-2level::Encode::Alias since that's not a legal package
name, but I don't know that all architectures could have names which
aren't legal package names. I'd prefer them to be in separate
directories.
I think that if you 'use lib qq{$ROOT/lib/perl5}' then the
architecture directory gets added automatically. (According to
'perldoc lib').
Maybe I just don't understand what you're trying to do well enough to
see why architecture specific directories are a problem. (XY
problem?)
David
Re: EUMM and Module::Build installations - Oh God, Help!
# from Ovid # on Friday 21 December 2007 03:36: What we would like, and having it work for both EUMM and Module::Build, is to make our installation look like this: $ROOT/lib/ $ROOT/arch/lib $ROOT/bin/ $ROOT/man/man1/ $ROOT/man/man3/ 1. Why like that? (vs a more typical tree that you would see in e.g. /usr/local where arch is not toplevel) 2. Have you tried hacking some overrides into Config.pm? (and setting a -Ipath -MConfig for that via PERL5OPT) 3. What settings are you using to get this far? What about INSTALL_BASE? I've found prefix install-dirs (used in combination) to be a bit more predictable. But, I've pondered the idea that maybe just yanking the files straight out of blib would possibly be much simpler. Note: install-dirs core vs site will give you fits because it tends to get set in the (?:M|B)(?:uild|akefile)\.PL by the dist author. For further reading: http://scratchcomputing.com/svn/stowpan/trunk Currently, my stow tree has 163 .packlist files, 1562 *.pm files and looks like: $ cd /usr/local/stow/cpan/; find -maxdepth 3 -type d ./bin ./lib ./lib/perl ./lib/perl/5.8.8 ./lib/perl/5.8 ./man ./man/man1 ./man/man3 ./share ./share/perl ./share/perl/5.8.8 Most of the .ix, .so, and .bs files, and all of the '.packlist's are in ./lib/perl/5.8.8/auto though there's this one weirdball: $ tree -a /usr/local/stow/cpan/share/perl/5.8.8/auto /usr/local/stow/cpan/share/perl/5.8.8/auto `-- Compress `-- Zlib `-- autosplit.ix Disclaimer: this was not a 100% fresh install -- some of that was moved into here from existing files in /usr/local and there have been some snags in stowpan that I haven't had the patience to work-through yet. Also, this is built on top of a debian Config.pm -- most others are bound to be far less workable for stowpan. --Eric -- Ignorance more frequently begets confidence than does knowledge. -- Charles Darwin --- http://scratchcomputing.com ---
