[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: checking in links to source control

From: John Minnihan
Subject: Re: checking in links to source control
Date: Wed, 12 Sep 2001 20:04:49 -0700
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010628

address@hidden wrote:

On Wed, Sep 12, 2001 at 11:41:34AM -0400, Jeff King wrote:

From: Edward Peschko [mailto:address@hidden
Sent: Monday, September 10, 2001 4:34 PM
To: Jeff King
Cc: address@hidden
Subject: Re: checking in links to source control

I want developers to see - locally - all of the perl libraries
cross project.
When I do a release, I want people to do a simple 'cvs checkout'
to get the
entire project, and have it *work on the spot*. I want them to be able to
'cd lib' into any project and get to the point where the
libraries are stored.

And controlling the perl libraries in a separate module from your other
projects will accomplish just that. Is having to do "cvs checkout project"
really more difficult and complicated than "cvs checkout project", "cvs
checkout lib"? Is "cd ..\lib" more difficult than "cd lib"?

Like I said, I'm already planning on doing this. But I want a standard way of
getting to those libraries, no matter where in the project I am.

Suppose the libraries are two steps up from a project, in '../../lib'? Or three steps up? I can't standardize on any 'use lib' statement then, I'd have
to resort to $FindBin::bin trickery (as was stated earlier).

Of course you can. This is trivial. Simply push the starting point for the libs
onto @INC and then merrliy go about issuing your use statements.  For example:

push (@INC, "/top/dir1/dir2/perlLibs/");

use Top-of-libs::subLevel-1::subLevel-2::coolLib;

This can also be accomplished using the -I switch to the invoking script which presumes to use the perl libs. In that way, you needn't embed the push alll over your scripts.

John Minnihan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]