Re^2: Detect which version of perl an XS module is linked against?

BrowserUk,
But attempting to upgrade a major version (5.8.x to 5.10.x) and retain previously installed modules almost certainly won't. ...

Your best course of action would be to delete your entire perl directory tree (which you should have done in the first place) and install 5.10 again.

Note: This is not a bug in AS Perl, it is how it is designed to work.

Perhaps you missed the part where I said I de-installed AS Perl 5.8.8 before installing AS Perl 5.10.0? In fact, AS Perl 5.10.0 won't let you install when it detects a previous version. Granted, I probably should have confirmed the perl directory was wiped but if AS refused to install prior to the de-install and happily agreed after, how was I to know it did not do its job correctly?

Cheers - L~R

Comment on Re^2: Detect which version of perl an XS module is linked against?

Replies are listed 'Best First'.
Re^3: Detect which version of perl an XS module is linked against? by BrowserUk (Patriarch) on Jan 03, 2008 at 15:29 UTC
Perhaps you missed the part where I said I de-installed AS Perl 5.8.8 before installing AS Perl 5.10.0? No. I saw that. In fact, AS Perl 5.10.0 won't let you install when it detects a previous version. Really. That's strange because I have 5.8.6(AS811), 5.8.8(AS817) and 5.10 Beta all installed concurrently? Granted, I probably should have confirmed the perl directory was wiped but if AS refused to install prior to the de-install and happily agreed after, how was I to know it did not do its job correctly? I think it is optimistic to expect that an uninstall will remove stuff added to the install directories after the initial install. And if it did, it would prevent my being able to install a minor version upgrade over an existing install and so retain all the packages I already installed. Indeed, I think it would be disasterous for it to try and work out what you might have installed using CPAN, CPANPLUS, PPM, and all the various manual install mechanisms. I also keep a lot of Perl related stuff, additional docs, various home generated scripts and modules, and the perl sources within the overall Perl directory tree. What should it do with those? There are times when I prefer software to allow me to decide what I want to do. 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: Detect which version of perl an XS module is linked against? by Limbic~Region (Chancellor) on Jan 03, 2008 at 15:42 UTC
BrowserUk, I concede you make really good points. I hope you concede that the average user is just going to accept the defaults and expect it to "just work". This is my situation and I would guess that it is the same for many more users. It didn't take me long to figure out what the problem was or how to fix it. In fact, my goal in this post (updated in the root thread) is to fix a particular test in the parrot test suite - not change how AS works. OTOH, it wouldn't be incredibly difficult for AS to make this easier on the average user during install: Distinguish <install>\site\lib by version Detect if files already exist in destination directory - issue a warning requiring acknowledgement Cheers - L~R	[reply]
Re^5: Detect which version of perl an XS module is linked against? by BrowserUk (Patriarch) on Jan 03, 2008 at 16:15 UTC
There are many things I would change about the way Perl installs on Win32. Whether the AS version or the standard distribution. The major change I would make is that I would do away with the `<lib>\auto\...` directories and place all dlls generated by building XS modules into the `perl\bin`. In this way, when a new perl is installed, it would empty `perl\bin` before installing thereby forcing all XS modules to have to be re-built before use. There are also a bunch of other reasons why having all the XS-built dlls in a single place makes sense for purely Win32 reasons. Distinguishing `<install>\site\lib` by version, is the wrong way to go. 99% of what lives in Perls lib directories is Pure Perl and so unaffected by version changes. It simply isn't necessary to replace or duplicate the vast majority of it when the binaries change. The real problem is the mixing of the non Perl source parts (DLLs/SOs) with the Perl sources in the same subtree. And that's a big flaw (one of several) in the overall architecture of the Perl distributions. AS simply try to work with it as far as possible. 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]