|There's more than one way to do things|
Re: Disappointed with latest Strawberry Perlby adamk (Chaplain)
|on Jan 02, 2008 at 11:51 UTC||Need Help??|
a) Why would Strawberry Perl *not* include the PPM utility ?
Mainly because I'm mentally still in a "Strawberry Perl is the Anti-ActivePerl" place.
Also because I personally haven't had the chance to see if they co-exist cleanly and if it can be done in a suitably zero-conf way.
Fortunately, since the entire build architecture is open source (and increasingly easy to use) you are welcome to build your own experimental distribution and work out for us what is needed to make them co-exist cleanly.
b) Why would Strawberry Perl *not* include the g77 compiler ?
Because nothing that needs g77.exe is sufficiently important to justify building it in, unlike say the extra GNU make, which we bundle for Wx, which is sufficiently important.
PDL is an important module, but providing extra stuff to help install it is somewhat outside the scope of Strawberry.
It's also not in because it wasn't important enough for someone to suggested it when I asked in my blog for suggestions of what to bundle. I have some dim memories about g77 in the distant past, but I totally forgot about it (further evidence it's not important enough).
Will it be in Chocolate? I'm quite certain it will.
Will it be in Strawberry? Probably not, although it might be worth bundling in if it small and only adds 50k to the size of the download.
Someone would also need to write Perl::Dist::Inno::install_g77 for me.
With respect to your additional observation, I'm aware that there are patches available for Vista support of some parts of the toolchain.
However, I'm simply not going to use them because 1) I STRONGLY prefer official releases 2) There's been exactly zero testing done with them.
I'm not in such a hurry to add support for Vista (or anything else) that I'm willing to use anything other than official tested releases of toolchain components.
This is how people like RedHat get themselves into such bad situations on such a regular basis. They deviate from the official path, almost always with negative results (I would consider unofficial patches for security issues though).
Once the new Perl::Dist releases start becoming available, there's a whole ton of people who should be able to start rolling distributions and kicking the tires of various features to see if they work or not.
And if they do, well then we can help provide pressure upstream to the originating projects to get fixes into the mainline releases.