develooper Front page | perl.perl5.porters | Postings from May 2003

Re: $VERSION Update and Questions

Thread Previous | Thread Next
Brian Ingerson
May 2, 2003 18:24
Re: $VERSION Update and Questions
Message ID:
On 03/05/03 01:41 +0200, Abigail wrote:
> On Thu, May 01, 2003 at 08:58:11PM -0400, John Peacock wrote:
> > Matthew O. Persico wrote:
> > >
> > >Wow, you are brave. Why pick 5.005_03 instead of 5.6.0 as a limit? 
> > >Wouldn't it probably simplify lots of your code to not have to deal with 
> > >5.005 format vs 5.6 format?
> > 
> > There are still poor unenlightened souls who cannot easily upgrade past 
> > 5.005_03 because their platform vendor can't be bothered to rewrite the 
> > custom apps using a more modern Perl (like Cobalt RAQ's) or because their 
> > local admin won't admit a newer Perl might be better.  I was suprised to 
> > discover how easy it was to make the XS code work with 5.005_03 (we can all 
> > be thankful that the Compatibility Police are so vigilant).
> This is valid if you are a true believer of the "There shall be only one
> perl on your system" philosophy. I used to believe that, but I no longer
> think that's realistic. What if you write a threaded piece of code, are
> you going to "support those whose platform vendor can't be bothered to
> rewrite custom apps using a threaded perl"? Same for 64bit integers or
> pointers, perlio or not, Perl malloc or system malloc, etc.
> I've seen many systems that have several Java environments running on
> the same host - some different, some equivalent. Often it's because
> an application either comes with its own environment, or because it's
> demanding a specific environment. In my experience, it works better than
> juggling all possible requirements from a bunch of applications into a
> single environment.
> I think this should be the case for Perl too. It should not be a problem
> to have 5.005_03, 5.6.1 and 5.8.0 running on the same box. Technically,
> it's not a problem. It's just the mindset of people.

On some collaborative projects, I check a Perl sourceball into my vcs
project directory, along with every module needed by the project. Then I
have a shell script called 'profile' that sets a bunch of project
specific environment variables. I also write a Makefile that is capable
of building Perl and installing modules.

To build the entire project arena, one does something like:

    cvs checkout thingy
    cd thingy/
    source profile
    make setup

This will build all the software that the project needs including Perl.
I generally like to install Perl right inside the project directory
itself. ( prefix=thingy/local )

And I don't just do this for Perl. I also do it for Apache, mod_perl,
MySQL, whatever.

This way I ensure that everyone is using the exact same version of
everything. You can have everything running under your home directory.
You don't collide with other projects' perls. And if you want to delete
everything you just say:

    rm -fr thingy/


I almost never use /usr/bin/perl for development. I consider it
part of the OS :)

Same with Python and Ruby.

Neil Watkiss (ActiveState guy I collab with often) came up with a nice

    > find /usr/lang/ -type d -maxdepth 2

Yes. That's how many languages we have on our dev box!

He also wrote a clever little switching script that lets you say:

    > lang perl 5.7.1

It adjusts the PATH variable, and stripped out old /usr/lang/perl paths.

Cheers, Brian

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About