I keep reading this, and I'm still lost for an explanation of what the Vanilla and Strawberry projects are aiming to achieve?

As a Win32 Perl user,

1. I can already build my own perl

   I actively sic choose to use Active State Perl for various reasons.

   • They've already solved most of the problems.
   • They've added value in the form of all the must have modules they bundle with their distributions.
   • They've added value in the form of their html-ised documentation sets which are 1000% more usable that perldoc.
   • They've added value in the form of the PPM manager.

     Whilst I can build most modules myself, having a quick, simple and convenient 'just do it' install for the more complex or tricky modules is a huge time saver.

     Why expend time and energy re-discovering all the problems and solutions to installing packages on win32 for every installation, when the problems have already been solved and are available for one-step installation?

2. I can already build my own modules, with or without the use of CPAN.pm

   I can use the CPAN shell. I choose not to, because it carries with it so much baggage that simply does nothing for me.

   For the vast majority of modules, I can manually download, build, test and install them--including 1 or 2 small dependencies before the CPAN shell has finished configuring itself, which it seems to need to do every time?

On those occasions I fail to be able to build a module, (most recently Devel::FastProf), the root cause seems to be much more to do with the way the authors write their modules to make use of inherently *nix-only features of the Perl source code, or by directly accessing parts of the Perl runtime bypassing the good work done the developers to isolate OS dependencies by virtualising them.

I guess what I am saying is, I certainly have the time, and (some of), the skills that would allow me to contribute to this project, but I am at a loss to understand what it is that you envisage that I, and other win32 users, would gain from this effort?

Also, what does the overall Perl community gain from the TPF funding this project?

The bottom line is, you are asking for someone to apply for a TPF grant, and therefore raise a grant application, but it's not at all clear to me what the objectives of the project are? Who is it intended to help and how?

I also think that a much clearer brief is required. In this short thread we've already seen that there is more than one opinion as to the direction that should be pursued. Your brief justification of the motivation for Vanilla & Strawberry

The aim is to provide CPAN authors a Win32 Perl platform that is similar in use and style to the Unix Perls, to make it easier for them to port to Win32, and to provide a suitable basic Perl platform for experienced Perl developers that prefer to install from CPAN, instead of using binary packages

Leaves me uneasy that it wouldn't benefit Win32 Perl users much. Despite the almost obligatory "I don't/only/have to use Win32" disclaimer, the biggest problem facing Win32 Perl users is that the vast majority of Perl developers don't want to develop on Win32, and this project sounds like yet another attempt to make win32 look as much like *nix as possible to allow reluctant but willing CPAN authors to more easily test and bug fix their modules on the win32 platform. Maybe that is the right way to go, but based on my own limited experience of trying to build the 'awkward squad' of modules on Win32, the problems go deeper than the compiler, CRT or build utilities.

As an example of what I mean, the problem I encountered with Devel::FastProf was that although the MSVC CRT has perfectly normal C getc() routine, once you've bypassed various errors to do with simple unixisms, the base Perl headers files are converting the getc() used in the source, to a call to

FastProf.xs(97) : warning C4013: 'PerlSIO_getc' undefined; assuming ex
+tern returning int
[download]

And the PerlIO/SIO subsystem doesn't appear to provide this routine. I've tried to unwind the macros to work out why getc() is redefined as PerlSIO_getc(), when that routine does not appear to exist anywhere in the entire Perl source tree, not just the Win32 part, without success.

I imagine that any *nix programmer that encountered this problem when trying to port their module to Win32 would probably take one look, blame it on a broken MS C compiler/CRT and understandably give up, but the problem lies within the the perl sources. Does anyone anywhere use the whole PerlSIO subsystem? What was the purpose of that layer of headers files? And was it ever achieved/completed?

And this is not an isolated incident. Many of the other problems of compiling code written to run on GCC with the MS compiler come down to compiler settings. Things like declaring for loop variables inline, which gcc allows even though it isn't part of the C standard, have to be explicitly enabled using the MS compilers.

My point is, I am not at all sure that simply moving to a perl distribution that builds with gcc is going to fix very much, or help Win32-reluctant module developers to more easily port their modules. And unless Strawberry also included all, (or at least most), of the value added features that come with the AS distributions, then Win32 Perl users, (as opposed to developers), are going to be very reluctant to adopt it. It would be of little benefit to anyone if the only people that made use of Vanilla/Strawberry Perl were only developers looking to simplify the porting of their modules to Win32, because it is quite likely that the results of their efforts would not work for the majority of Win32 users.

Please don't misunderstand me, I would hate to be seen as dismissive of any attempt to make Perl more Win32 friendly. Indeed, I would love to be a part of such an effort and dog knows if there was a little income to be earnt from such efforts it certainly would not go amiss. My fear is that, as I understand the direction outlined here, (which of course my be a completely different thing from the intent), it may not, even probably would not, do much to help in this regard, and that any monies that the TPF feels are justified in making Perl more Win32 friendly/complete might be better directed.

Maybe Strawberry is only the starting point and would enable/encourage more people to become actively involved in making Perl work better on Win32? I think I am the wrong person to make that judgement and so I would encourage an expanded discussion of the overall goals and the best way of achieving them, to help convince me, and others, that this is the right way to go.