Project Organization

[chance]

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 ?

 

[Ben Liddicott]

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

 

[Ben Morrow]

[please stop top-posting]


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

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

 

[Ben Liddicott]

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

[please stop top-posting]

[There is more than one way to do it. I do it this way.]

 

[Ben Morrow]

[please stop top-posting]

[There is more than one way to do it. I do it this way.]

*plonk*

 

[Ben Liddicott]

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

[please stop top-posting]

[There is more than one way to do it. I do it this way.]

*plonk*

 

[John J. Trammell]

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*

 

[Tad McClellan]

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*

 

[Anno Siegel]

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