Regarding the copying of AS PPDs into CQ installation. Wouldn't there be some path problem
I'm not sure what you mean by "path problem"? You would have to move/copy the files (manually) extracted from the AS .zips into the appropriate places with the CQPerl subtrees. This is generally not hard to do manually, though it begs to be automated.
as well as version mismatch problem?
So long as you fetch the AS .zip compatible with the build of CQPerl, it should be fine. Eg. If the CQPerl reports it's version as 5.8.x then get the zips from here.
In general (though not guarenteed), dlls built with any compiler, for a given major release of Perl will interoperate correctly,
Or I should pick AS perl 5.8.6, just like the CQ perl is?
Are you saying that CQPerl is just a binary copy of AS Perl with some extra packages added? If so, does it come with ppm, or ppm-shell?
If so, then just using that to install the extra packages you want would be by far the simplest option.
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.
| [reply]
[d/l]
[select] |
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.
| [reply] |
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.
| [reply]
[d/l]
[select] |
cqperl is an IBM Rational maintained and slimmed down distribution.
The best method is to get the module source from CPAN, compile with cqperl, and install either via copy or MSI with dependency on clearquest. This is especially true if you need to centrally distribute.
I don't suggest doing things like "use lib..." because the code's in the schema and this will cause problems with cross-platform interop.
| [reply] |