ExtUtils::MakeMaker / @INC
Tina Mueller
i'm trying to find out in which directory a module
is installed. if it is installed into the default
location, i could look up the paths in %Config,
but if PREFIX is changed, i probably would have
to take all the install dirs from %Config and
remove $Config{prefix}.
however, i hope there is an easier way, as i'm not
sure which of the many %Config keys i have to take.
i'm distributing an application, that means i wrote
a package, let's say MyPackage. in this package there
is the script itself, script.pl (and some config files), and i'm
installing them via EXE_FILES, INSTALLSCRIPT and INST_SCRIPT.
I'm asking the user for the PREFIX and save it into $PREFIX.
The script requires some additional modules from CPAN,
e.g. XML::Simple. to make it
as easy as possible for the user to install (they might not
be familiar with installing modules or perl at all),
i packed the required module tar files into my package,
and them i'm calling
"perl Makefile.PL PREFIX=$PREFIX;make;make install"
for every module that is not installed.
now in script.pl i have to use lib "...", so
that it finds MyPackage and XML::Simple;
normally it would be necessary to say:
use lib "$PREFIX/site-perl/...";
use lib "$PREFIX/site-perl/5.6.1";
use lib "$PREFIX/site-perl/5.6.1/i586-linux";
and so on.
i managed to get around that by setting
INSTALLARCHLIB, INSTALLSITELIB, and INSTALLSITEARCH to $PREFIX, too,
so that MyPackage is directly under $PREFIX and i can just say:
use lib $PREFIX;
use MyPackage;
how can i force XML::Simple (and the other modules) to be
installed there, too?
just calling perl Makefile.PL PREFIX=$PREFIX INSTALLARCHLIB=$PREFIX ...
for every module?
i'm wondering if this will safely work for all modules, or
if i missed something.
appreciating any hints, tina
followp to c.l.p.modules
--
http://www.tinita.de/ \ enter__| |__the___ _ _ ___
http://Movies.tinita.de/ \ / _` / _ \/ _ \ '_(_-< of
http://PerlQuotes.tinita.de/ \ \ _,_\ __/\ __/_| /__/ perception
Tina Mueller
> i'm trying to find out in which directory a module
> is installed. if it is installed into the default
> location, i could look up the paths in %Config,
> but if PREFIX is changed, i probably would have
> to take all the install dirs from %Config and
> remove $Config{prefix}.
> however, i hope there is an easier way, as i'm not
> sure which of the many %Config keys i have to take.
[probably too long explanation snipped...]
i guess i can do:
use lib "$PREFIX/lib/$Config{version}";
use lib "$PREFIX/lib/site_perl";
or do:
use lib map {
my $l=$_;
$l=~s#\Q$Config{prefix}/$Config{installstyle}#$PREFIX/lib#;$l
} @INC;
just still wondering if this will work on any perlversion/system...
regards, tina
brian d foy
<use...@tinita.de> wrote:
> The script requires some additional modules from CPAN,
> e.g. XML::Simple. to make it
> as easy as possible for the user to install (they might not
> be familiar with installing modules or perl at all),
> i packed the required module tar files into my package,
> and them i'm calling
> "perl Makefile.PL PREFIX=$PREFIX;make;make install"
was DIR not doing the right thing?
if I can look at the actual distribution I could try a few
things---I did this sort of thing once (once!) several years
ago.
--
brian d foy, com...@panix.com
Anno Siegel
If a CPAN module is installed with "PREFIX=$PREFIX",
use lib $PREFIX, "$PREFIX/lib/perl5/site_perl";
should find it in all cases. Other subdirectories are taken care of
by "use lib" or the search process. (Me don't know, me don't care)
> and so on.
>
> i managed to get around that by setting
> INSTALLARCHLIB, INSTALLSITELIB, and INSTALLSITEARCH to $PREFIX, too,
> so that MyPackage is directly under $PREFIX and i can just say:
> use lib $PREFIX;
> use MyPackage;
>
> how can i force XML::Simple (and the other modules) to be
> installed there, too?
> just calling perl Makefile.PL PREFIX=$PREFIX INSTALLARCHLIB=$PREFIX ...
> for every module?
>
> i'm wondering if this will safely work for all modules, or
> if i missed something.
I'd be interested in a definite answer to that one too, but I don't
think it's necessary.
> appreciating any hints, tina
It appears that some modules take pains to have themselves installed
in the site_perl directory, and that doesn't seem to work well with
private installs. However, I think adding a single library isn't too
bad a workaround. That way, you'd catch your own stuff in "$PREFIX/"
plus all modules you install with "PREFIX=$PREFIX".
Anno
Tina Mueller
> Tina Mueller <use...@tinita.de> wrote in comp.lang.perl.misc:
>>
>> that it finds MyPackage and XML::Simple;
>> normally it would be necessary to say:
>> use lib "$PREFIX/site-perl/...";
>> use lib "$PREFIX/site-perl/5.6.1";
>> use lib "$PREFIX/site-perl/5.6.1/i586-linux";
> If a CPAN module is installed with "PREFIX=$PREFIX",
> use lib $PREFIX, "$PREFIX/lib/perl5/site_perl";
> should find it in all cases. Other subdirectories are taken care of
> by "use lib" or the search process. (Me don't know, me don't care)
ok, if this covers all systems, this would work.
i guess i was on the wrong track, because i thought
this differs from system to sytem, but if there are only
these two possibilities...
i tested on my system (Linux 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002,
SuSE 8.0), and $PREFIX looks like this:
lib/
perl5/
5.8.0/
site_perl/
man/...
however, on another machine with the same system and linux distribution,
but with perl 5.6.1, it looks like this:
lib/
5.6.1/
site_perl/
share/...
so i think i'm going with your suggestion:
use lib $PREFIX, "$PREFIX/lib/perl5/site_perl";
thanks, tina
Tina Mueller
> In article <tinh98nss$1fe$ti...@news01.tinita.de>, Tina Mueller
> <use...@tinita.de> wrote:
>> The script requires some additional modules from CPAN,
>> e.g. XML::Simple. to make it
>> as easy as possible for the user to install (they might not
>> be familiar with installing modules or perl at all),
>> i packed the required module tar files into my package,
>> and them i'm calling
>> "perl Makefile.PL PREFIX=$PREFIX;make;make install"
> was DIR not doing the right thing?
oh, i didn't know of that.
i was actually looking for something like BUNDLE.
i looked into CPAN::MakeMaker, and the docs said,
i just needed to have a directory "BUNDLE" with the
tarballs in it, and it would take care of installing
them, but id didn't, so i switched back to ExtUtils.
but i don't know if i'm using DIR correctly.
i have a directory "dist" in my package, and
in Makefile.PL i'm untaring the tarballs and say:
WriteMakefile(
...
DIR => ['dist/Bit-Vector-6.3', 'dist/...'],
);
calling make generates a blib for every distribution
in dist, but make install doesn't install them.
> if I can look at the actual distribution I could try a few
> things---I did this sort of thing once (once!) several years
> ago.
i created a test package that looks like this:
$ cat MANIFEST
Package/Module.pm
Package/Objects/Object.pm
Makefile.PL
dist/Bit-Vector-6.3.tar.gz
MANIFEST
Makefile.PL:
# untaring dist/*.tar.gz
WriteMakefile(
DIR => ["dist/Bit-Vector-6.3"],
NAME => 'Package',
VERSION_FROM => 'Package/Module.pm',
PREREQ_PM => { # I probably don't need that
'Bit::Vector' => 6.3,
},
);
perl Makefile.PL PREFIX=/tmp/mylib ; make
builds Package and Bit::Vector,
but
make install
just installs Package/Module.pm and Package/Objects/Object.pm.
renaming "dist" to "lib" doesn't help either, it installs
the whole Bit::Vecor-6.3 directory.
regards, tina
Tina Mueller
> Anno Siegel <anno...@lublin.zrz.tu-berlin.de> wrote:
>> Tina Mueller <use...@tinita.de> wrote in comp.lang.perl.misc:
>>>
>>> now in script.pl i have to use lib "...", so
>>> that it finds MyPackage and XML::Simple;
>>> normally it would be necessary to say:
>>> use lib "$PREFIX/site-perl/...";
>>> use lib "$PREFIX/site-perl/5.6.1";
>>> use lib "$PREFIX/site-perl/5.6.1/i586-linux";
>> If a CPAN module is installed with "PREFIX=$PREFIX",
>> use lib $PREFIX, "$PREFIX/lib/perl5/site_perl";
>> should find it in all cases. Other subdirectories are taken care of
>> by "use lib" or the search process. (Me don't know, me don't care)
> ok, if this covers all systems, this would work.
hmmm, i just tried on another machine:
perl 5.005_03, Linux 2.2.10
tina@sco1:/tmp/Bit-Vector-6.3 > export PREFIX=/tmp/mylib
tina@sco1:/tmp/Bit-Vector-6.3 > perl Makefile.PL PREFIX=$PREFIX
...
tina@sco1:/tmp/Bit-Vector-6.3 > make
...
tina@sco1:/tmp/Bit-Vector-6.3 > make install
...
(this gives an error:
/bin/sh: /tmp/mylib/lib/perl5/5.00503/i586-linux/perllocal.pod: Datei oder Verzeichnis nicht gefunden
make: [doc_site_install] Error 1 (ignored)
)
then $PREFIX looks like this:
lib/
perl5/
site_perl/
5.005/
i586-linux/
Bit/
tina@sco1:/tmp/Bit-Vector-6.3 > perl -wle'
use lib "$ENV{PREFIX}","$ENV{PREFIX}/lib/perl5/site_perl";
use Bit::Vector'
Can't locate Bit/Vector.pm in @INC (@INC contains: /tmp/mylib /tmp/mylib/lib/perl5/site_perl /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 .) at -e line 3.
BEGIN failed--compilation aborted at -e line 3.
including the 5.005 directory works.
so there must be a generic method to find out which lib to use()...
(but anyway i guess can go with the suggestion for now because
this will be shipped to only one customer at the moment, and i
can require perl >= 5.6.1 to be installed.)
regards, tina
brian d foy
<use...@tinita.de> wrote:
> brian d foy <com...@panix.com> wrote:
> > In article <tinh98nss$1fe$ti...@news01.tinita.de>, Tina Mueller
> > <use...@tinita.de> wrote:
>
> >> The script requires some additional modules from CPAN,
> >> e.g. XML::Simple. to make it
> >> as easy as possible for the user to install
> > was DIR not doing the right thing?
> calling make generates a blib for every distribution
> in dist, but make install doesn't install them.
looking at the Makefile, I see that PREFIX is passed through
to the other Makefiles, but the install target in the top
level Makefile does not change into the other directories
to install those.
if you look at the targets for test and clean you see how they
pass through to the other directories, and that install does not
do that.
you can fix that adding another command line to the install
target. in the postamble you can sneak in something like
install::
-cd dist/foo && \$(TEST_F) Makefile && make install
-cd dist/bar && \$(TEST_F) Makefile && make install
this should probably be fixed in ExtUtils::* though. if you
specify DIR, it should install those too.
Murat Ünalan
> >> "perl Makefile.PL PREFIX=$PREFIX;make;make install"
I count this a hack. That scares my pants off. Please, don't do that. On any
strict "Micrsoft enviroment" there is no "make", but "nmake".
Couldn't you use CPAN for that ? CPAN offers an alternativ repository
location (cdrom etc) if an internet connection is not viable.
Cheers,
Murat
Tina Mueller
>> >> and them i'm calling
>> >> "perl Makefile.PL PREFIX=$PREFIX;make;make install"
> I count this a hack. That scares my pants off. Please, don't do that. On any
> strict "Micrsoft enviroment" there is no "make", but "nmake".
i know, this is just a workaround. and this application
will at the moment be used on only one linux machine, anyway.
> Couldn't you use CPAN for that ? CPAN offers an alternativ repository
> location (cdrom etc) if an internet connection is not viable.
if there's a possibility to just call CPAN without prompting
the user for any input (user might not know anything about
perl), then this would be fine; i guess i should have a
closer look into CPAN.pm.
thanks, tina
Slaven Rezic
> "Murat Ünalan" <murat....@gmx.de> wrote:
> >> >> and them i'm calling
> >> >> "perl Makefile.PL PREFIX=$PREFIX;make;make install"
>
> > I count this a hack. That scares my pants off. Please, don't do that. On any
> > strict "Micrsoft enviroment" there is no "make", but "nmake".
>
> i know, this is just a workaround. and this application
> will at the moment be used on only one linux machine, anyway.
>
> > Couldn't you use CPAN for that ? CPAN offers an alternativ repository
> > location (cdrom etc) if an internet connection is not viable.
>
> if there's a possibility to just call CPAN without prompting
> the user for any input (user might not know anything about
> perl), then this would be fine; i guess i should have a
> closer look into CPAN.pm.
>
This should be possible if there is a pre-generated
~/.cpan/CPAN/MyConfig.pm (which you could supply).
Regards,
Slaven
--
Slaven Rezic - sla...@rezic.de
Visualize XML files in a Tk text widget:
http://search.cpan.org/search?mode=module&query=Tk::XMLViewer
Tina Mueller
> In article <tinh9a9wa$24e$ti...@news01.tinita.de>, Tina Mueller
> <use...@tinita.de> wrote:
>> brian d foy <com...@panix.com> wrote:
>> > In article <tinh98nss$1fe$ti...@news01.tinita.de>, Tina Mueller
>> > <use...@tinita.de> wrote:
>>
>> >> The script requires some additional modules from CPAN,
>> >> e.g. XML::Simple. to make it
>> >> as easy as possible for the user to install
>> > was DIR not doing the right thing?
>> calling make generates a blib for every distribution
>> in dist, but make install doesn't install them.
> looking at the Makefile, I see that PREFIX is passed through
> to the other Makefiles, but the install target in the top
> level Makefile does not change into the other directories
> to install those.
if i look into dist/Bit-Vector.../Makefile, i see that
PREFIX is still set to /usr/local. and no install-target.
> if you look at the targets for test and clean you see how they
> pass through to the other directories, and that install does not
> do that.
> you can fix that adding another command line to the install
> target. in the postamble you can sneak in something like
> install::
> -cd dist/foo && \$(TEST_F) Makefile && make install
> -cd dist/bar && \$(TEST_F) Makefile && make install
'make' said: "missing seperator".
i changed to "cd dist/foo && ..." and then it didn't complain,
ran make, but not make install.
i guess i'll ask the user for their make program if
i don't find make in $PATH and then install the modules
manually, maybe even into the default PREFIX, with getting
root. as my module
itself has no extensions, i don't even need to "make install"
for that, just copy the .pm's into the appropriate directories.
Tina Mueller
> Tina Mueller <use...@tinita.de> writes:
>>
>> if there's a possibility to just call CPAN without prompting
>> the user for any input (user might not know anything about
>> perl), then this would be fine; i guess i should have a
>> closer look into CPAN.pm.
>>
> This should be possible if there is a pre-generated
> ~/.cpan/CPAN/MyConfig.pm (which you could supply).
great! i just have to fiddle around with it a bit,
because it requires Bit-Vector...tar.gz and CHECKSUMS to be in
the directory authors/id/S/ST/STBEY.
i set urllist to file://localhost/currentdir/dist/.
maybe there's also a possibility to omit the authors/id... directory.
(maybe i can ask you about that on wednesday berliner.pm... =)
brian d foy
<use...@tinita.de> wrote:
> brian d foy <com...@panix.com> wrote:
> > In article <tinh9a9wa$24e$ti...@news01.tinita.de>, Tina Mueller
> > <use...@tinita.de> wrote:
>
> >> brian d foy <com...@panix.com> wrote:
> >> > In article <tinh98nss$1fe$ti...@news01.tinita.de>, Tina Mueller
> >> > <use...@tinita.de> wrote:
> >>
> >> >> The script requires some additional modules from CPAN,
> >> >> e.g. XML::Simple. to make it
> >> >> as easy as possible for the user to install
>
> >> > was DIR not doing the right thing?
>
> >> calling make generates a blib for every distribution
> >> in dist, but make install doesn't install them.
>
> > looking at the Makefile, I see that PREFIX is passed through
> > to the other Makefiles,
> if i look into dist/Bit-Vector.../Makefile, i see that
> PREFIX is still set to /usr/local. and no install-target.
indeed it is. the header at the top of the Makefile says it
was called with the right arguments, but that is a bug.
the problem is really in ExtUtils::MakeMaker::eval_from_x().
sub eval_in_x {
my($self,$dir) = @_;
chdir $dir or Carp::carp("Couldn't change to directory $dir: $!");
{
package main;
do './Makefile.PL';
};
...
}
Notice the "do './Makefile.PL" that does not pass the arguments from
the current Makefile.PL!
I overrode this in my test Makefile.PL.
sub ExtUtils::MakeMaker::eval_in_x
{
my( $self, $dir) = @_;
chdir $dir or Carp::carp("Couldn't change to directory $dir: $!");
system("perl ./Makefile.PL @ARGV");
}
After inspecting the dist Makefile (more carefully this time ;), I
see that the right things are set. This might have side-effects, or
the absence of side-effects that throws off the MakeMaker voodoo.
This does not fix the 'make install' problem, but with the appropriate
postamble you can get the Makefile to recurse into the directories *and*
make you dinner while it does it.
So I have entered a ticket for this:
http://rt.cpan.org/NoAuth/Bug.html?id=1991
Kurt Starsinic also asked about this earlier on the MakeMaker mailing
list. People seem to think it is a bug.
http://archive.develooper.com/make...@perl.org/msg00071.html
Tina Mueller
> In article <tinh9cjjm$1sm$ti...@news01.tinita.de>, Tina Mueller
> <use...@tinita.de> wrote:
>> brian d foy <com...@panix.com> wrote:
>>
>> > looking at the Makefile, I see that PREFIX is passed through
>> > to the other Makefiles,
>> if i look into dist/Bit-Vector.../Makefile, i see that
>> PREFIX is still set to /usr/local. and no install-target.
> indeed it is. the header at the top of the Makefile says it
> was called with the right arguments, but that is a bug.
> the problem is really in ExtUtils::MakeMaker::eval_from_x().
> sub eval_in_x {
> my($self,$dir) = @_;
> chdir $dir or Carp::carp("Couldn't change to directory $dir: $!");
> {
> package main;
> do './Makefile.PL';
> };
> ...
> }
> Notice the "do './Makefile.PL" that does not pass the arguments from
> the current Makefile.PL!
this is strange. do() should pass @ARGV,
and if i write a debug message in the dist Makefile.PL
i can see that @ARGV is set with the right PREFIX.
> I overrode this in my test Makefile.PL.
> sub ExtUtils::MakeMaker::eval_in_x
> {
> my( $self, $dir) = @_;
> chdir $dir or Carp::carp("Couldn't change to directory $dir: $!");
>
> system("perl ./Makefile.PL @ARGV");
> }
yep, this works. maybe one should at least change "perl" to $^X... =)
i guess with the do() something is not called, but i couldn't
figure out yet, what it is...
> After inspecting the dist Makefile (more carefully this time ;), I
> see that the right things are set. This might have side-effects, or
> the absence of side-effects that throws off the MakeMaker voodoo.
> This does not fix the 'make install' problem, but with the appropriate
> postamble you can get the Makefile to recurse into the directories *and*
> make you dinner while it does it.
=)
> So I have entered a ticket for this:
> http://rt.cpan.org/NoAuth/Bug.html?id=1991
ah, great. i'll try your patch will the actual distribution.
> Kurt Starsinic also asked about this earlier on the MakeMaker mailing
> list. People seem to think it is a bug.
> http://archive.develooper.com/make...@perl.org/msg00071.html
good to know; i didn't think there is a mailing list for that;
thanks for the help,
Tina Mueller
> ah, great. i'll try your patch will the actual distribution.
ok, i made two subs in Makefile.PL:
sub ExtUtils::MakeMaker::eval_in_x {
my( $self, $dir) = @_;
chdir $dir or Carp::carp("Couldn't change to directory $dir: $!");
system("$^X ./Makefile.PL PREFIX=$PREFIX INSTALLARCHLIB=$PREFIX INSTALLSITELIB=$PREFIX INSTALLSITEARCH=$PREFIX");
}
sub MY::postamble {
my $string = "";
$string .= "install ::\n\t-cd $_ && \\\$(TEST_F) Makefile && make install\n"
for @dirs; # @dirs was generated by looking
# which modules need to be installed
$string
}
this looks a little bit like a hack, but it works fine (hope there are
no side effects, though) and should
work for all linux systems and maybe even for windows...
regards, tina
Ilya Zakharevich
brian d foy
> the problem is really in ExtUtils::MakeMaker::eval_from_x().
Yes. I first reported this bug many years ago.
> sub eval_in_x {
...
> do './Makefile.PL';
> I overrode this in my test Makefile.PL.
> system("perl ./Makefile.PL @ARGV");
I think copying the contents of @ARGV into the namespace of the
sub-Makefile.PL would give better results. E.g., some of my modules assume
that the kid Makefile.PL runs in the same interpreter as the parent.
Ilya