«

So anybody out there have any advice on how to organize a
big perl project?

Pretty much all I'm looking for is philosophical banter on
merits of

1) setting PERLIB

2) setting PERL5LIB

3) perl -Idirs

4) 'use lib "../dir/dir";',
followed my 'use module;' (which resides in '../dir/dir/')

5) something I don't know about

I've got all my stuff checked in to a CVS repository,
and I want multiple experimental implementations to
be able to work at the same time, so absolute paths are
ruled out.

This feels like an instance where having Makefiles and
associated cruft is actually an advantage. Maybe its just
a mental block my part though.

Right now, I'm using method (4), which feels like putting
the the -I flag (to gcc) in a C file. just feels kinda
icky and wrong.

any better way to do this ?

--
I used to think government was a necessary evil.
I'm not so sure about the necessary part anymore.

My philosophy is always 5:

If it comes with the distribution, leave it where it is.
If it belongs with an application, even if it is a file which might
conceiveably be of use in other applications, put it with the application
script.

This insulates you from version incompatibilities, though it does mean you
have to patch everywhere if there is a bug in a module.

You will also never have to mess around with environment variables, and you
get what MS call "xcopy deploy", which is unix-like tarball distribution
capability: You can just tar up the directories and plop them somewhere
else, with a reasonable assurance that all will be well.

On your points:
1) Don't set PERLIB except in a shellscript which knows exactly which perl
script it is going to call, and unsets it afterwards. Don't set PERLIB for
scripts which are Perl 5 only.
2) As 1, but don't set for Perl 4 obviously.
3) For shellscripts only, in my opinion
4) This can be useful if you have done work in a BEGIN block to locate where
the LIB dir is. You may have taken it from the command line for example, or
from a config file. It can also be useful if you have per-application
libraries which can't be kept with the script for some reason. Then you just
say use lib '/etc/lib/myapplib'; and put your libs there.



Cheers,
Ben Liddicott



<> wrote in message
news:bpf4ip$msc$...
> So anybody out there have any advice on how to organize a
> big perl project?
>
> Pretty much all I'm looking for is philosophical banter on
> merits of
>
> 1) setting PERLIB
>
> 2) setting PERL5LIB
>
> 3) perl -Idirs
>
> 4) 'use lib "../dir/dir";',
> followed my 'use module;' (which resides in '../dir/dir/')
>
> 5) something I don't know about

[please stop top-posting]

"Ben Liddicott" <> wrote:
> <> wrote in message
> news:bpf4ip$msc$...
> > So anybody out there have any advice on how to organize a
> > big perl project?
> >
> > Pretty much all I'm looking for is philosophical banter on
> > merits of
> >
> > 1) setting PERLIB
> >
> > 2) setting PERL5LIB
> >
> > 3) perl -Idirs
> >
> > 4) 'use lib "../dir/dir";',
> > followed my 'use module;' (which resides in '../dir/dir/')

This Won't Work unless your program is always started from the same
working directory.

> > 5) something I don't know about
>
> My philosophy is always 5:
>
> If it comes with the distribution, leave it where it is.
> If it belongs with an application, even if it is a file which might
> conceiveably be of use in other applications, put it with the application
> script.

It won't be found unless the application is started from its installed
directory... you need to use FindBin to find where the program file
is, and then use lib with that path.

> On your points:
> 1) Don't set PERLIB except in a shellscript which knows exactly which perl
> script it is going to call, and unsets it afterwards.

....or in your .profile &c to point to a personal perl lib under your
home directory.

Another alternative: for platform-specific programs, you can read a
config file in /etc / read a value out of the Windows registry /
etc. as appropriate to find the right directory.

I would have said that something involving 'use lib' is going to be
right, unless you have a small wrapper shell script (say, generated at
install time) that knows absolute paths to everything. In that case,
the only difference between using PERL5?LIB and -I is that if your
program invokes perl again then PERL5?LIB will be passed but -I won't:
which is appropriate depends on the application.

Ben

--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] *

Good point.

My latest is a demon which chdir's to it's bin directory in a BEGIN block. I
forgot that this doesn't work in the general case.

I do think one should search the script directory first, nevertheless.

Cheers,
Ben Liddicott

"Ben Morrow" <> wrote in message
news:bpft41$ai$...
> [please stop top-posting]
[There is more than one way to do it. I do it this way.]
>
> "Ben Liddicott" <> wrote:
(...)
> > > 4) 'use lib "../dir/dir";',
> > > followed my 'use module;' (which resides in '../dir/dir/')
>
> This Won't Work unless your program is always started from the same
> working directory.
>
> > > 5) something I don't know about
> >
> > My philosophy is always 5:
> >
> > If it comes with the distribution, leave it where it is.
> > If it belongs with an application, even if it is a file which might
> > conceiveably be of use in other applications, put it with the
application
> > script.
>
> It won't be found unless the application is started from its installed
> directory... you need to use FindBin to find where the program file
> is, and then use lib with that path.

"Ben Liddicott" <> wrote:
> "Ben Morrow" <> wrote in message
> news:bpft41$ai$...
> > [please stop top-posting]
> [There is more than one way to do it. I do it this way.]

*plonk*

--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces molit animos, tristesque mentes erigit. |
Musica vel ipsas arbores et horridas movet feras. |

It's rather rude to plonk people publicly. It makes you look like a rude
person.

I might care, but you do this all the time, and for equally trivial reasons;
so I don't.

If anyone else wants to plonk, plink or plunk me for top-posting, please do
so now, but quietly so as not to annoy the other posters.

And yes, I do think you are reading this message. I don't think you could
resist seeing if I responded.

Cheers,
Ben Liddicott

"Ben Morrow" <> wrote in message
news:bpg4p7$6pp$...
> "Ben Liddicott" <> wrote:
> > "Ben Morrow" <> wrote in message
> > news:bpft41$ai$...
> > > [please stop top-posting]
> > [There is more than one way to do it. I do it this way.]
>
> *plonk*

On Wed, 19 Nov 2003 16:38:11 -0000, Ben Liddicott
<> TOFU-ed:
> If anyone else wants to plonk, plink or plunk me for top-posting,
> please do so now, but quietly so as not to annoy the other posters.
>

*plop*

Ben Liddicott <> wrote:

> If anyone else wants to plonk, plink or plunk me for top-posting, please do
> so now, but quietly so as not to annoy the other posters.


If you want to top-post please do it quietly so as not to annoy
the other posters. (or do you get to annoy folks but nobody
else does?)


*plonk*


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

Ben Liddicott <> wrote in comp.lang.perl.misc:
> It's rather rude to plonk people publicly. It makes you look like a rude
> person.
>
> I might care, but you do this all the time, and for equally trivial reasons;
> so I don't.
>
> If anyone else wants to plonk, plink or plunk me for top-posting, please do
> so now, but quietly so as not to annoy the other posters.

Your choice. So long.

Anno