Re^4: Perl/ClearQuest or CQPerl/DBI on XP 64-bit

Path problems, I mean, the dlls may have some hardcoded path values of expected perl?

CQ Perl is a 5.8.6 build. I don't know if Rational took an AS release and glued some modules to it, or built it from source themselves.

I'll try both advices, using 32-bit AS perl 5.8.9 and if it fails, copying the AS modules' binaries over into the CQ Perl tree. Solution with AS perl is always preferred because of easier maintenance.

Thanks, Roman.

Comment on Re^4: Perl/ClearQuest or CQPerl/DBI on XP 64-bit

Replies are listed 'Best First'.
Re^5: Perl/ClearQuest or CQPerl/DBI on XP 64-bit by BrowserUk (Patriarch) on Aug 05, 2009 at 18:36 UTC
Path problems, I mean, the dlls may have some hardcoded path values of expected perl? If that were the case, it would be very bad practice. And one I've never encountered with any Perl/CPAN created dlls. There's no guarantees that IBM/Rational haven't done something like that, but it would be ... um ... untypical if they have. For the AS perl approach, I would probably try: Install the AS Perl (to match the CQPerl version) in a separate directory structure; Then copy the entire CQPerl `<CQPerl>\lib` & `<CQPerl>\site\lib` directories over the top of the equivalents installed by the AS perl--and then test thoroughly! If that checks out okay, you can then disable the CQPerl installation--remove it from your path, and enable the AS Perl install and you should then have everything that came with the CQPerl and then ability to use PPM to maintain the installation. For everything except the CQ stuff. When a new release of CQPerl comes along, you'd have to install it (without letting it become a part of your path), and then repeat the copyover process from the new subtrees to your AS perl installation. It would require you document the process (in case you get hit by a bus), but it shouldn't be too onerous to do. A simple batch file using `xcopy` ought to do it. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP PCW	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Perl/ClearQuest or CQPerl/DBI on XP 64-bit
by BrowserUk (Patriarch) on Aug 05, 2009 at 18:36 UTC

Path problems, I mean, the dlls may have some hardcoded path values of expected perl?

If that were the case, it would be very bad practice. And one I've never encountered with any Perl/CPAN created dlls. There's no guarantees that IBM/Rational haven't done something like that, but it would be ... um ... untypical if they have.

For the AS perl approach, I would probably try:

Install the AS Perl (to match the CQPerl version) in a separate directory structure;
Then copy the entire CQPerl <CQPerl>\lib & <CQPerl>\site\lib directories over the top of the equivalents installed by the AS perl--and then test thoroughly!

If that checks out okay, you can then disable the CQPerl installation--remove it from your path, and enable the AS Perl install and you should then have everything that came with the CQPerl and then ability to use PPM to maintain the installation. For everything except the CQ stuff.

When a new release of CQPerl comes along, you'd have to install it (without letting it become a part of your path), and then repeat the copyover process from the new subtrees to your AS perl installation. It would require you document the process (in case you get hit by a bus), but it shouldn't be too onerous to do. A simple batch file using xcopy ought to do it.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW

[reply]
[d/l]
[select]