|
in reply to Re: How to handle Cross-platform Perl, modules, and versioning
in thread How to handle Cross-platform Perl, modules, and versioning
Abigail,
>>Assuming the various versions of Perl weren't configured by monkeys typing random characters,
Unfortunately, that's the way it's been for all of my clients. :)
Also, I need to have a central repository for the custom libraries. It's not a good idea to take on the maintenance
of updating code on 11 platforms if you do not have to.
My system was initially setup for a hybrid environment of
5.005_03 and 5.6.1. I have to reference some custom libraries that were written for 5.005_03. Furthermore, I
have to backup to make sure my system fully supports 5.005_03 on all 11 platforms.
Note: The system is centrally located, so any changes on the UNIX/Linux side of the house will affect all of those platforms.
After making changes on aix due to referencing higher versions IO 5.6.1 library problems, my system started working correctly on Perl 5.005_03. Solaris is still running Perl 5.6.1. That is all it has installed. Other than the old Perl executable I previously mentioned.
So,when I tried running the same code on Solaris, it barfed
because of the Perl 5.6.1 system is expecting Perl 5.6.1 versions of IO to be in PERL5LIB. Perl is in many different
locations on the various UNIX/Linux platforms, but in the
same place for the 5 Windows + Netware platforms.
One question is can I have Perl switch on the libraries
on the fly with a BEGIN statement? Something like:
use Config;
$PLATFORM = $Config{'osname'};
if (($PLATFORM =~ /^MSWin32/i) ||
($PLATFORM =~ /^solaris/i)) {
# use Perl 5.6.1 libraries
BEGIN {
@PERL_SHARE = (
"/foo/custom/perl/lib/Custom_mods5.6.1",
);
unshift(@INC, @PERL_SHARE);
};
}
else {
# use Perl 5.005_03 libraries
BEGIN {
@PERL_SHARE = (
"/foo/custom/perl/lib/Custom_mods5.005_03",
);
unshift(@INC, @PERL_SHARE);
};
}
Does this make more sense? The question is, what would
the best practice be??
-P0w3rK!d
|
Re: Re: Re: How to handle Cross-platform Perl, modules, and versioning
by BrowserUk (Patriarch) on Apr 15, 2003 at 21:53 UTC
|
That won't work as-is because both BEGIN{} blocks will be executed before the if statement is even compiled.
If performance or memory is a consideration, unless you are using %Config for other things as well, you would be better off using $^O to test for the OS. It contain sthe same info as $Config{'osname'} but without the overhead of loading Config.pm.
Also, why are you putting a single scalar into an array and then unshifting the array?
This ought to come pretty close to what you are trying to do I think. (NB:untested)
BEGIN{
# UPDATE: Corrected typo pointed out my [Abigail-II] below.
unshift @INC, $^O =~ m[^(?:MSWin32|solaris)$]i
? '/foo/custom/perl/lib/Custom_mods5.6.1'
: '/foo/custom/perl/lib/Custom_mods5.005_03';
}
Though that is probably better coded as
(Also partially untested) BEGIN{
use lib $^O =~ m[^(?:MSWin32|solaris)$]i
? '/foo/custom/perl/lib/Custom_mods5.6.1'
: '/foo/custom/perl/lib/Custom_mods5.005_';
}
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply]
[d/l]
[select] |
|
|
I would discourage that kind of test. Once you update the version of perl on Solaris, for example, you're screwed... I'd rather go for checking the version of perl.
Of course, the best thing would be a clean install. See my other post.
| [reply] |
|
|
Makes sense to me but i don't live in the world of running perl on 11 platforms, so I had to assume that the OP knows what he's doing in that regard.
I'd amazed--and mighty impressed--if all the differences between those 11 platforms can be differenciated by either the OP's test or that of just the version. I know that perl is highly portable, but I was sure that the real test would probably be more complicated than the example the OP supplied, and I don't have the cross-systems experince to even guess what it would really look like.
I read the OP's code somewhat differently to you--and I don't know which of us is closer--in as mach as I took the ".../Custom_mods..." to mean that each machine/platform had a standard install, but that they wanted to share their in-house modules from specific places. Maybe that makes sense in thier environment?
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply]
[d/l] |
|
|
|
|
| [reply]
[d/l]
[select] |
|
|
s/@ENV/@INC/. I said it was untested:)...corrected. Thanks.
With regard to the use of the BEGIN block, in truth, the OP was using BEGIN{} so it didn't cross my mind to change that.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] |
|
|
The BEGIN block was someone elses code that was never
"adjusted". I like the way you did this. Thanks. I will adopt your wisdom into my code :)
-P0w3rK!d
| [reply] |
Re: How to handle Cross-platform Perl, modules, and versioning
by jonadab (Parson) on Apr 15, 2003 at 21:50 UTC
|
Also, I need to have a central repository for the custom libraries.
Sure, but only custom libraries should be there. There
should not, for example, be copies of core modules in
there. That would create headaches.
I have to reference some custom libraries that were written for 5.005_03
If the custom libraries will also run under more recent
versions, I don't see the problem. If they won't, then
of course they have to be fixed so that they will.
So,when I tried running the same code on Solaris, it barfed because of the Perl 5.6.1 system is expecting Perl 5.6.1 versions of IO to be in PERL5LIB
Yes, that's what it should expect. If that system
has 5.6.1, then its PERL5LIB should be the one for
5.6.1 also. That's basic consistency. If you are
changing PERL5LIB to point to a central directory,
then all the systems using that directory need to
have the same version of Perl. Otherwise, if they
have different versions of Perl, they must also have
different versions of PERL5LIB.
what would the best practice be?
The best practice would be to write your code so that
it doesn't matter which version of Perl it runs under,
simply by not relying on version-specific hacks.
I still don't understand your problem with modules; for
any given module you are trying to use, there are three
possibilities: it will run fine under either version
of Perl, it won't run at all under some versions, or
a different version of it is needed depending on the
Perl version. In the first (ideal) case, there should
be no problem. In the second case, it should be
obvious that you can't use that module. In the third
case, you must install the right version of the module
on each system for the version of Perl that is there.
In no event should any of your code ever be looking
for specific versions of a module. Write your code
generally, without version-specific hacks, so that
any (supported) version of the module will
just work.
(If the module changed its API between
versions, you should either not use that module (my
first inclination) or if you absolutely must use it
write a wrapper module so that you don't have to use
it directly; install the correct version of the
wrapper module on each system for the version of
the wrapped module that is there. All versions of
the wrapper module should present the same API to
the rest of your code.)
Some of my assumptions may be way off base; I had a
hard time following your description of your problem,
but as best I understand it, it _sounds_ like the
custom modules aren't really your problem, but some
core modules that you (or the custom modules) use.
It sounds from some parts of your explanation like
some installations are getting versions of the core
modules that are wrong for the version of Perl and/or
for eachother. This implies that someone at your site
has messed with the core modules in an inappropriate
way. It's hard to be more specific without knowing
more details about your setup, except to say that each
installation of Perl should have its own installation
of the core modules, and any custom modules that are
to be shared across multiple versions of Perl must
be able to work correctly with whichever versions of
Perl (and thus the core modules) they happen to get.
for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
| [reply]
[d/l] |
|
|
>>Some of my assumptions may be way off base;
Some are, but thanks for working through the
problem for me in an unbiased manner. You helped
me realize that the problem is directly related
to IO::handle, Filehandle.pm and the custom library "logfile.pm", which references them.
>>I had a hard time following your description of
>>your problem, but as best I understand it, it _sounds_ >>like the custom modules aren't really your problem,
>> but some core modules that you (or the custom modules) >>use. This implies that someone at your site has
>>messed with the core modules in an inappropriate way.
Perl is in bad shape on all of the UNIX systems. I am
trying to rectify that.
Thanks for your help :)
-P0w3rK!d
| [reply] |
|
|
