ClearCase/Windows comes with a bundled Perl build. Unfortunately this is a prehistoric 5.001 version dating to circa 1993 and not only is it old and buggy, it (a) is missing many standard modules and (b) has some bugs which were not in vanilla 5.001 but are unique to this port. So people writing Perl scripts to work with ClearCase for Windows are faced with a tough decision; use the badly limited but preinstalled version or maintain their own at unknown cost. In this document I'll try to show some ways of making the latter option more palatable.

The situation is similar on UNIX where CC comes with a slightly newer (5.002) but similarly flawed build. However, the UNIX-side solution is easier and better known; build your own, share it via NFS, and you're there. Windows is more difficult due to the lack of a free compiler, the basic assumption of Windows software that it exists in a private universe, the registry, etc.

I won't go into how to set up Perl for UNIX; it's a complex topic, well covered by the existing docs, about which I have no remarkable expertise. For the same reasons I won't discuss methods of supporting Perl in an integrated way between different UNIX architectures such as Solaris, HP-UX, and Linux. Rather, I assume the existence of a successful UNIX Perl installation and discuss various ways of getting a Win32 build to cooperate with it.

Of course the concerns with a networked Windows Perl are (a) speed and (b) availability over the network. We can dismiss (b) in most cases because by using ClearCase you've already made a commitment to a network architecture and at least one file/VOB server. If your WIN32 Perl is served from the same machine there's little additional exposure. Regarding performance: I did a benchmark on Win2K SP2, comparing ActiveState Perl build 629 running locally with the same AS build on a Sun Ultra-10 workstation running Solaris 8 using Samba 2.2.1a over Fast (100Mbit) Ethernet:

C:\>type benchnet.pl
use Benchmark;
timethese (shift, {
    Local       => sub { system 'C:/Perl/bin/perl -v >NUL' },
    Network     => sub { system '//fileserver/perl/bin/perl -v >NUL' },
});

C:\>perl H:\pl\benchnet.pl 1000
Benchmark: timing 1000 iterations of Local, Network...
     Local: 13 wallclock secs ( 0.33 usr +  0.57 sys =  0.90 CPU) @ 1111.11/s (n
=1000)
   Network: 27 wallclock secs ( 0.33 usr +  0.58 sys =  0.91 CPU) @ 1096.49/s (n
=1000)

My take on this is that the network doesn't add an undue amount of pain. Since the constant startup time for most Perl/CC scripts is dominated by the linear run time of transactions with CC databases, the fact that the network version takes twice as long to start up may be insignificant. After all, even the network perl takes less than a 10th of a second to start up. However, your mileage may vary and in particular the difference may be greater for older Windows (e.g. NT4) versions. On the other hand there are faster servers than an Ultra10 running Samba. [Note: in a later retry I measured 6-to-1 startup cost rather than the 2-to-1 above. So even my mileage varies. No idea why.]

Various possible configurations are discussed below. They're listed in reverse order of desirability (i.e. the Networked ActiveState at the end is most highly recommended):

Ccperl 5.001

Use of the bundled ccperl mentioned above. Reasons to avoid it are given above. This document is about alternatives to ccperl. The day may come when Rational updates ccperl to something modern, at which point it will be more viable and this case will look more like the following:

Local-only Modern Perl

A completely standalone but modern Win32 install on every PC. This is relatively easy to do and we won't discuss how to do it. The problem with this model is that even moderately advanced Perl programs will want to use a few modules. If any programs need non-core modules or if any core modules need a bugfix, you're faced with visiting and updating each system.

The typical choice is to install ActiveState Perl on each client, perhaps even getting it onto a standard disk image used to build new PC's. It may be possible to have an automatically updated local Perl install using SMS or similar. This solution is left for Windows experts.

Use of other Perl builds such as those bundled with Cygwin or MKS Toolkit fall into this same category. There are differences between these Perls of course but that's an orthogonal subject.

Local With Network Modules

A local modern install which derives add-on modules from a common network location. Similar to the above but searches a standard network place for modules before looking locally. This buys most of the performance advantages of a local install with much better maintainability. Discussed in HOW TO SET UP A LOCALLY-INSTALLED WIN32 PERL WITH NETWORKED ADD-ON MODULES .

Standard Networked

A fully network build which requires no local installation or configuration, built directly from the original Perl source. This version includes just the core-Perl modules, the same set that comes with a UNIX build. A compiler is required. Discussed in HOW TO BUILD A STANDARD NETWORKED WIN32 PERL.

ActiveState Networked

The ActiveState Perl build, modified for a network install. Like the Standard build it requires no local installation or configuration but the ActiveState version comes with many non-core modules such as the entire Win32:: hierarchy. Discussed in HOW TO SET UP A NETWORKED WIN32 ACTIVESTATE PERL. This is the best alternative in many ways; ActiveState issues updates frequently and thus it's easy to keep up with Perl technology. It doesn't require a compiler. Many popular add-on modules are bundled and PPM can be used to add more.