I just went to CPAN and pulled Scalar::Util. It took less than 10 seconds to download via my dial-up connection. And doing the prayer-in-four-parts took almost exactly the same amount of time. And that included me mis-typing the name once. There is no reason why AS' autobuild process couldn't download the latest/required version of module dependancies. That's a procedural problem for AS, not a problem for users.

It sucks that perfectly workable modules are getting flagged as unbuildable by the AS process, especially for want of the latest version of a module, (in this case developed by an AS developer?), that they already know builds correctly as they ship it with later versions of their own distributions.

However, the version I just downloaded and built was Scalar::Util v1.17. The latest version available on cpan is v1.18. This fails to build under AS 5.8.6 because of an unresolved external

   Creating library blib\arch\auto\List\Util\Util.lib and object blib\
+arch\auto\List\Util\Util.exp
Util.obj : error LNK2019: unresolved external symbol _Perl_seed refere
+nced in function _XS_List__Util_shuffle
blib\arch\auto\List\Util\Util.dll : fatal error LNK1120: 1 unresolved 
+externals
[download]

And that comes down to my having 5.8.6 rather the 5.8.8. A change 26054, was made to Scalar::Util::shuffle to address a problem whereby dprof would "break" shuffle. That change included calling Perl_seed(), which (apparently) was not previously exported. So change 26836 was required to export Perl_seed and fix the linker error.

My point is, this is standard version control ripples and I don't see how that would be fixed by using a different compiler?

Vanilla/Strawberry Perl may make it easier and simpler for developers to get set up to test code on Win32, but unless the vast majority of users also move to using it, the only benefit woudl be in the statistics of successful Win32 builds--which would be pretty useless unless users can benefit. It could even make things worse, as I could see the standard response to questions about build problems of packages on win32 being "it works with Vanilla Perl, so it must be Active State that is broken", which wouldn't help many users.

I could see the standard response to questions about build problems of packages on win32 being "it works with Vanilla Perl, so it must be Active State that is broken", which wouldn't help many users.

It wouldn't help many users of ActiveState Perl, you mean. If ActiveState is broken and something else works, isn't that an improvement for users in general? Maybe some friendly co-opetition would improve ActiveState, too.

As to the Scalar::Util thing -- it has more to do with the fact that ActiveState's auto-build procedure uses their earliest 5.8 Perl release as the the basis for PPM generation without any upgrades to any modules in core. 8xx PPM's are supposed to be ones that will work with the earliest 5.8 Perl released by ActiveState -- which was several years ago. So anyone depending on ActiveState-built PPM's has to accept a 3-year lag in compatibility.

It's compounded by the fact that Perl can't easily replace core modules on Windows if they are in-use. demerphq has recently patched ExtUtils::Install to use the Win32 API to do this on Windows (and the old files are removed at the next reboot). That's great news for VanillaPerl, but doesn't help ActiveState as, again, they're stuck with ExtUtils::Install from 5.8.0.

The inability to rely upon any upgrades to core modules in 5.8 is a major flaw in my opinion. I'm sure there have been substantial bug-fixes to numerous core modules from 5.8.0 to 5.8.8. But any distribution that depends on certain behavior of upgraded modules will fail a dependency version requirements checks for building a PPM or may not behavior properly if the dependency version is ignored.

A good example of that is File::Spec and company. Look at the Changes file and look at how many Win32 bug fixes there have been in the last year alone. There are a lot. Any any code which relies upon those bugs being fixed can't require a modern File::Spec and still pass ActiveState's PPM build process.

The point is that this is not "standard version control ripples" as you put it. This is a fundamental difference in the philosophy of module packaging, distribution and support. Both are valid and they just serve different "customers" who have different wants.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

demerphq has recently patched ExtUtils::Install to use the Win32 API to do this on Windows (and the old files are removed at the next reboot). That's great news for VanillaPerl, but doesn't help ActiveState as, again, they're stuck with ExtUtils::Install from 5.8.0.

Not so. The latest build of ActiveState perl has EU::MM-6.30, which includes EU::I-1.33 - all of which is stock-standard perl 5.8.8.

Cheers,
Rob

It's compounded by the fact that Perl can't easily replace core modules on Windows if they are in-use. The inability to rely upon any upgrades to core modules in 5.8 is a major flaw in my opinion

I don't get this? I install upgrades to core modules all the time and I never have to re-boot afterwards. What is this all about?

---

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

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

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

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

There is no reason why AS' autobuild process couldn't download the latest/required version of module dependancies. That's a procedural problem for AS, not a problem for users.

You assert there is no reason, and yet here we are without AS autobuild support for vast quantities of things. It is a problem for users because AS are the defacto gatekeepers for what is and is not supported on Windows. Lets look at just the CPAN packages that start with "P".

http://ppm.activestate.com/BuildStatus/5.8-P.html

Vast swaths of modules no longer work in the autobuild system, the grand irony being that Windows is the platform with the WORST support in the PPM autobuild system, and Mac OS X being the best, when one would think given their relative userbases, Windows would be the best supported.

Looking at some common things from that list...

PAR does not work, PDL does not work, PGP does not work, my new PITA testing project does not work, POE (which has NO non-core deps by default) does not work, PPI (which has almost no non-core deps) does not work, and thus most of Perl:: does not work, Plucene does not work, POSY doesn't, Process doesn't, Perl-GPS doesn't, plus dozens of less well used modules.

Many of these use plain ordinary pure Perl code with proper platform-neutral File::Spec usage.

Although it may APPEAR there is no reason, there most certainly is. And despite efforts to fix the autobuild system, it is increasingly appearing that these are systematic faults, inherent to the design of the PPM system itself, and may well be unfixable without breaking back-compatibility.

I and others have raised this problem a number of times, via the online forms, emails, and even in person at OSCON. I've spent a year in the rediculous position that as the AUTHOR of PPI I cannot install it on my own Windows laptop so I can do demonstrations during my PPI talk.

Or at least, I cannot without a vast amount of work, installing the compiler and make myself, then downloading the entire chain of 20 distributions manually and hand-installing all of them.

The point of installers is to install things.

And as long as everything Just Worked, the PPM system was a perfectly acceptable solution.

But despite gozer's and other people's efforts, it has now reached a point where the problems have become too much for me. When something like this goes wrong, I am in a position where there is nothing at all I can do to fix the problem, other than to bitch to ActiveState. And I hate to bitch about things which I can't fix myself if needed.

So if there are prodedural problems inside of ActiveState PPM system that I cannot fix, that even THEY might not be able to fix, then it is clear to me that what the Perl community needs is a way to at least have the OPTION to help itself in these situations.

The CamelPack has helped solve the short term problem by at least making it easy to set up a compiler and a make with AP.

Vanilla has provided an excellent research distribution so we can look at Win32 problems very close to and in the Perl core, and look at problems in the toolchain without creating an expectation that it is useful for authors or developers.

Strawberry is the next step, and is about making a minimal but complete and bug free distribution. It's the third step of an unknown number.

This is NOT about compilers, and this isn't about wanting to make Win32 Perl more like Unix. This is about wanting Win32 Perl to be like Perl on every other one of the 100+ platforms, from Plan 9 to Nokia mobile phones.

Windows Is No Special Flower.

The low level common Perl modules should be able to build and install portably on all platforms (or as many as possible), and from there normal Perl developers should not have to care which specific platform they are on if they are not doing anything exotic. It should Just Work.

Windows is not special, it just presents some challenges, much as every other platform has presented some challenges.

And I think the Perl community as a whole deserves at least the option to face those challenges themselves, rather than loading all the work and all the pressure, and all the cost onto one company.

It's not fair to ActiveState and it's not fair to the Perl community.

Adam. Please do not see my questions and calls for consultation in this thread as dissention to the basic motives of your OP. Indeed I am enthused to be a participant in addressing the underlying causes of the problems you are trying to address.

Please see Re^9: [JOB] The Perl Foundation seeks Windows Developer for some explanation of my requests of further information/consultation before commiting to support the project. I would like to be a part of the solution, (on the TPF dime or not, though it certainly would help), but I remain unconvinced that as described, that the project would achieve it's goals in the long term.

Half of what you say in the above post encourages me; but the other half leaves me unsure as to whether the project as described would achieve anything long term to address the underlying causes of Win32 incompatibilities.

---

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

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

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

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