After an initial rejection due to networking CPAN.pm failures (reports on which have been fed back into RT and will hopefully be fixed before 5.8.8), Stephen Steneker's second submission of his Perl CamelPack 5.8.7 passed all 9 points and he claims the reward of a vertical metre of beer.
Stephen (back row centre in this picture) is the co-ordinator of Sydney.pm, but this will be his first ever CPAN upload. He even went the extra step of producing us a 5.6.1 version of the CamelPack for version dependency testing purposes.
In typical Australia fashion and in an excellent use of the "you may steal mercilessly" rule, he simply bundled together ActivePerl 5.8.7, the Bloodshed Dev-C editor (which installs at the same time a working MinGW environment), and Microsoft's nmake. And It Just Works (and even maintains compatibility with ActivePerl's PPM binary packages)
To avoid licensing issues, rather than embed the installers in his main installer, his installer downloads them on the fly during the install and they Do The Right Thing. This also means that the CamelPack comes in at only 345k.
If a little crude, his solution worked well, was pulled together quickly, and should be easily repeatable for new Perl versions. And happily for me, I get to deliver his beer in person since I plan to be in town for the February Sydney.pm meeting.
He just edged out Carl Franks' Vanilla Perl. (which I won't link to because he has bandwidth issues where it is hosted)
Carl took the opposite approach with Vanilla and compiled gcc, a set of unix tools, and perl itself all from scratch specifically for Windows, and then wrapped it up in a unified installer (total size about 15meg).
However, he was tripped up by the same networking problem (related to passive FTP and the Windows firewall) that caught Stephen out, and also suffered from a badly crashing gzip.exe. In the end, it may have actually come down to timezones, with Carl simply running out of ability to avoid sleep just as Stephen was waking up and starting on the problems from his initial rejection.
In the end, I suspect it will turn out that BOTH Perl distributions will live on and be useful. Stephen is keen to solve the problem of integrating CPAN with binary installs and solve the libfoo.dll problem (and was already working on it) so the CamelPack could well become an ideal "end user" Perl installation.
And because Vanilla Perl contains only the core Perl modules, and not the extra ActivePerl modules, it will serve as an ideal Perl install to run inside of Win32 PITA images, for testing CPAN distributions on Windows.
All in all, the competition was a resounding success, and now we should truly be able to install modules directly from CPAN across linux, mac, and Win32, without any undue pain. Well worth a metre of beer!
P.S. Photos of the beer presentation to follow :)
While PXPerl seems to have "frozen" at the moment (the guy is a student after all). I would rather have seen someone step in to help on that one as I see this having the most "potential" as it is indepedent.
I would much rather have the MingW install over the DEV-C++. Why install something like an IDE when 99.9% of the end users will never use it? Too much cruft.
Re:
Aristotle on 2006-01-25T17:55:12
I agree. That was the angle I was thinking of and might have tried myself, had I a Windows machine to actually do this on. (Ie. set up MingW, compile Perl with it, then package the lot together with an installer.)
The ActiveState + Dev-C++ solution is good for contests (you get to win fast), but loads of bloat in practice.
Re: ActiveState + Dev-C++
bart on 2006-01-25T21:11:51
I like the compatibility with PPM. In cases where you don't succeed in building an XS module yourself (for example because of dependency on external libriries which is not for newbies in C compilers), then you can always use a prebuilt PPM distribution, which is nice.
But I sincerely dislike the idea that this installer installs an IDE for C++, just in order to compile XS modules.
BTW Intrepid on Perlmonk told me earlier today he has built complex XS modules with MinGW to work with ActivePerl. If you know what you're doing, it's not too hard, that's what he says. Unfortunately, I don't.
So the direction I'd like to see the most, is ActivePerl or a binary compatible perl, combined with MinGW for the C compiler, creating PPM compatible DLLs.Re: ActiveState + Dev-C++
stennie on 2006-01-25T21:34:41
Would be great if someone can interpret what actually needs to be bundled for MinGW and how to configure it to work with ActivePerl or other win32 environments. Much prefer just installing the compiler, if that's all that is needed!
I couldn't make easy sense of the MinGW mess, while DevC++ "Just Worked":
http://www.mingw.org/
https://sourceforge.net/project/showfiles.php?group_id=2435
Cheers,
Stephen
Re: Hmmmm
stennie on 2006-01-25T21:15:29
Agree with comments on creating a "minimal" installer, based on a vanilla build of perl (or pxperl) and gcc/mingw toolchain. I'd love to do so, but am not interested in signing myself up for the ongoing build and testing of distinct binary releases... as that's yet another distro that can fall by the wayside. Aside from that, I only boot into Windows for testing;-).
In the interests of expediency, I simply packaged up some reliable (and maintained) tools in the most straightforward way possible. I would consider this solution a "proof of concept" that can surely be improved (for example, with options to install minimal or more complete development environments).
I would welcome anyone to try to get the PXPerl community going (original author seems to have vanished after a early build, forums are not getting replies?).. and would be happy to see more support for creating a more comprehensive Windows installer. I considered a few alternative perl installers, but in general these wanted to install even more bloat by default: apache, mod_perl, or even php.
Before attempting an installer, I had already noted several posts on PXPerl from Adam asking if / how he could assist in getting that across the line, and I suspect this challenge arose from his frustration in lack of response there.
Further notes on what I considered:
http://stennie.org/camelpack/
Suggestions welcome!
Cheers,
Stephen
Re:
Aristotle on 2006-01-25T22:48:07
Creating a new distribution, it seems to me, wouldn’t be a huge issue, if only there was an easy way for people beside the original author to repeat the process – ie. a build script, the one thing that PXPerl clearly lacks.
Re: Hmmmm
Alias on 2006-01-26T12:43:01
Well, not only that, but a managed to get a couple of people to look at simply taking it over the moving ahead on their own, or even to create a screencast of how to get MinGW set up with it.
None of them were able to do it.
If someone else is able to make it work, that would be great.
Re: Hmmmm
bart on 2006-01-27T00:03:36
Are you saying you don't know how to get MinGW to work for PXPerl? Well, it works for me. I did have to delete a command line option, one that gcc for MinGW (?) apparently didn't support. The command line options that I have left are(Use configure_pxperl, a script with a Tk GUI, to select the MinGW gcc compiler first.)-g -O3 -fno-strict-aliasing
Re: CamelPack doesn't work for me....
dagolden on 2006-03-15T22:58:20
Check out UnxUtils.
