On Monday, June 10, 2002, at 04:28 , Sharan Hiremath wrote:
[..]
> I am using around 15 CPAN modules in my perl utility. I want to bundle
> all
> these modules including my own modules as one installable. (Basically to
> make installation simple).
my complements to your plan!
> How can I do this?
>
> I tried to use %INC and get all loaded modules. made a tar out of all
> these.
this mostly sorta woulda worked - assuming that you remembered to
pick up all the stuff that would be associated with the requirements
a) all of the *.al files
b) all of the *.bs files
c) all of the *.pm files
d) all of the *.pod files
.....
which is why most of us don't try that strategy - since, well, most
of us went this way and forgot at least one or more of them, because
we forgot that FOO::BAR actually needed BOB::BAZ and ....
{ so the good news is that you are in good company... }
> wrote a small utility to copy all these files to Perl lib directory.
a part of the problem here is resolving the chain of dependencies.
Your module requires say modules X,Y,Z - and they have the pre-req's
of modules M,N,J - ......
So a first phase is to make sure that you know all of your dependencies
which you seem to have done - and then to resolve the 'rest of the
chain below' - so that you can start with the documentation solution.
At this point you have to sort out which of the four basic
strategies your 'customer' will allow:
a) CPAN.pm - and Bundle.pm = cf their pod
b) they read your docs and install your pre-requisites
from their own build of the code - because they want to
check all of your pre-requisite code first.
{ hence even if you offer them c/d below - they pre-empted you }
c) they will let you do 'binary only installations'
- hence you will need multiple builds - because
they have no development tools on their machine
d) they will let you run the 'make' of multiple modules
because they have the compilers.
(a) and (c) would seem to be the easiest for the more 'trusting souls',
(b) is our more traditional model - (d) would be my preferred strategy
but rests upon "them" having build tools on the target host.
IF your target host has 'make' - but not compilers, then you can do
what I call a 'modified make build' - in which you ran the 'build' on
the target OS/Architecture - and build a tarball of those products.
let's assume for this illustration that you need the basic 'web stuff'
hence are dependent upon:
Digest-MD5-2.16
HTML-Parser-3.26
HTML-Tagset-3.03
MIME-Base64-2.12
URI-1.18
libnet-1.11
libwww-perl-5.64
you of course ran through and did a build in each of those "sub
directories"
for each of the code lines - and create a tarball of each at this
'compiled'
side of the game so that you wind up with
Digest-MD5-2.16.build.tar.Z
HTML-Parser-3.26.build.tar.Z
HTML-Tagset-3.03.build.tar.Z
MIME-Base64-2.12.build.tar.Z
URI-1.18.build.tar.Z
libnet-1.11.build.tar.Z
libwww-perl-5.64.build.tar.Z
roll those up with your code - into a Really BIG tarball - in this
case 'build' should be a 'tag' indicating OS and Architecture - nothing
like trying to slam Solaris8 Sparc binaries onto a Solaris 2.6 x86 box.
Now have your "installer" code at the top level which checks to see that
a) the version of each required pre-req is at least
the value you need....
b) if not - unwrap the tarballs
chdir into the directory
run make install
until all of your pre-req's are resolved
then run 'make install' on your traget.
In the classic (d) solution you would haul along only the original
modules in their unbuilt format and still want to go through the
"is this is the version I need" installation process.
HTH
[..]
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
