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.