ClearCase/Windows comes with a bundled Perl build. Unfortunately this is a prehistoric 5.001 version dating to circa 1994 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 decision; use the badly limited but preinstalled version or maintain their own. A large proportion of users have chosen the old ("ccperl") version because they think setting up their own perl build is unpalatable. In this document I'll try to show ways of using a modern perl without great cost.

The UNIX situation is similar to Windows; 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 all PC software that it exists only to serve the current user on the current machine, 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 which cooperates with it.

People tend to have concerns about using a networked Windows Perl such as (a) its speed and (b) availability over the network. ClearCase users can dismiss (b) in most cases because they've already made a commitment to a network architecture employing 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 is generally insignificant. After all, even the network perl takes less than a 10th of a second to start up. Of course, 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.]

The ActiveState Perl build, modified for a network install, is the recommended configuration. It's free, requires no local installation or configuration, comes with many non-core modules such as the entire Win32:: hierarchy, requires no compiler or build expertise, and gets frequent updates. Discussed in HOW TO SET UP A NETWORKED WIN32 ACTIVESTATE PERL. Also, many additional CPAN modules are available at the ActiveState module site and PPM can be used to add more.

There are many other possible perl interop configurations, of course. Some of these are detailed at deprecated variants.