This month featured lots of work in the latter parts of Alien::Base. These improve library detection logic, pkg-config functionality and packlist support.

I was especially pleased to get a bug report filed by bpo regular Toby Inkster. He is writing a provisional Alien::LibXML based on Alien::Base. He noticed some odd behaviors that we are still trying to work out. This feedback led to more improvements than just his, so please keep the bug reports coming!

This month I released three dev versions, the latest being released this evening. I also released Acme::Ford::Prefect again, this time the tests shouldn’t fail on CPANtesters computers who don’t actually install the dependent modules for the one that they are testing. This module is one of the “downstream” modules that are part of the test system for Alien::Base (along with Acme::Alien::DontPanic). These are needed since some of the magic happens during the final installation so tests have to occur AFTER installation of the module in question.

I was saddened this month to learn that Strawberry Perl doesn’t include a Bash interpreter with its build environment. I was under that impression since Strawberry is built on MinGW (compiler) and also includes make, that meant that it bundled MinGW’s MSYS environment. Unfortunately this isn’t true, Strawberry bundles its own make, but not the other tools provided by MSYS, like Bash, and thus it cannot run configure scripts. Oh well, I always planned on pre-built binaries for Windows, guess I’m back to that.

I know I say this regularly, but the system is very close to completion! I’m not going to claim this month again, but sometime very soon!

I wrote Galileo partially as a reason to learn DBIx::Class. For those of you who may not know, Galileo is my CMS, designed to be completely installable from CPAN.

As a scientist I’m not very proficient as a database admin. Part of what I love about DBIx::Class is that I didn’t have to learn database administration or SQL, it does that for me. Perhaps I had gotten a little overconfident.

Not too long ago, I asked for input on a new module: Module::Build::CleanInstall.

TL;DR its out there, go use it!

Edit: Module::Build::CleanInstall has been released!

Following the recent work (chronicled here) by Yanick Champoux and this StackOverflow question, I got it into my mind to try to write a Module::Build subclass which first removes all the files previously installed by a module before installing the new version. In those posts, this is motivated by File::ShareDir concerns, but this problem is more general than that.

If your new version of a module does not come with some file that a previous version did, installing the new version will not remove that file. Most of the time this is ok, but every now and again you need to know that those files don’t exist. That’s usually when you see warnings in the POD saying, “be sure to remove all previous installations …” or “only install on a fresh copy of Perl”. The author knows that a problem is possible, but the user has to fix it. Sounds bad.

What if you could just switch your build tool from Module::Build (or EU::MM) to Module::Build::CleanInstall and let that take care of it for you?

Normally once I mock up an example, I release it to CPAN and see how it goes, but this time, I thought I might solicit comments first, since perhaps there are real world considerations I haven’t thought of. Please let me know any thoughts on this idea and the proposed implementation in the comments below.