Why is Parrot afraid of Perl?

Reading time: 2 minutes

Or – provocative title aside – why does Parrot want to move away from Perl in its build process?

Yesterday, Jim Keenan asked me a question about a Windows bug in some Perl code used in Parrot configuration.  My suggestion was to use a function from IPC::Cmd instead, since IPC::Cmd is core in Perl 5.10 and thus already well-tested across a wide range of platforms.

In his reply, he mentioned that Parrot configuration targets Perl 5.8 with only core modules (except things distributed with the Parrot source) and he added this as well:

And, in fact, the Parrot leadership has set the goal of getting every bit of Perl 5 code out of the Parrot distribution.  See, e.g., https://trac.parrot.org/parrot/ticket/619

I’m sure there’s more to the issue, but as I don’t follow Parrot discussions all that closely, my first reaction is that it seems unwise to me. ((Unless the goal is to have Parrot completely bootstrap itself from existing Parrot binaries, which might actually be a decent thing.))

The advantage of Perl for configuration is that it’s already portable – so you can configure the same way on Windows as you would on Unix.  Take away Perl and then you’re stuck with MSYS or cygwin, or other ports of Unix tools to Windows, none of which are as easy to use as, say, installing Strawberry Perl.

That Parrot ticket suggests using autoconf.  Really?!?  Google for “autoconf windows”.  Here’s a example of what you get: I hate autoconf.  Plus, you need Perl for autoconf anyway, so this approach layers a unix-y tool on top of Perl to build makefiles to build Parrot.  That’s a lot of places for things to break across platforms.

I’d rather just have Perl.

In fact, I’ll go further in my rant and point out that even Perl can’t be automatically configured on Windows because it depends on shell scripts.  Instead, configurations are maintained and edited by hand in the Perl source, and anyone building on Windows has to hand edit them again  for any local customization.

I think that one of the reasons that Strawberry Perl has kept its momentum and frequent releases is that the build process got coded up into Perl::Dist, so that all the custom configuration needed to build a Windows Perl binary could be automated with Perl.

So, maybe as an “outsider” to the Parrot project my opinion doesn’t count for much, but I think if they really want to be more portable and more automated, they should be looking to use more Perl, not less.

•      •      •

If you enjoyed this or have feedback, please let me know by or