Anyone who has been following my progress on Alien::Base knows that in the past few months I have been struggling to nail down the final problem, namely Mac’s library name problem. The short story is, on Mac, the library has the full path to the module baked into the library during compilation. My problem is that I don’t tell it the correct path during compilation. Why?

I wanted installing an Alien::Base module to feel as much like installing a regular Perl module. This means following the canonical perl Build.PL, ./Build, ./Build test, ./Build install, incantations that we are all used to. Further I wanted each step to act as normal. To do this, the ./Build step is the one that fetches the library source, configures it compiles it, and then “installs” it to a directory inside the temporary build directory of the Alien::Base-based installer module (this location was set during configure using the --prefix flag). This is so that the user can invoke tests that use the library before installing it to the proper permanent (user-space) location during the ./Build install phase. This is supposed to be the path of least astonishment.

That brings us back to Mac, because the library needs to know its full install path before it is built, and the best I can tell it is the temporary “install” directory, I cannot make the finally installed library function correctly. I have tried to compensate by using tools which can change the location inside the compiled binary library, but there are huge drawbacks to this too, which I will not go into here. Needless to say, it involves parsing and changing directives inside arbitrary Makefiles. It doesn’t work, at least not well enough.

This has lead to stagnation in the Alien::Base project as I have been letting this problem percolate through the old gray matter. Finally, after a few months, I think I might have an idea. Its not my favorite, and it will involve some rewriting, but I think it stays closest to the original goals.

The new plan is now this. ./Build will now fetch, configure and build the library; the --prefix will now point to the final installed location. I will still make attempts to have ./Build test work as expected, at least on most platforms, but this is no longer a priority. I can hear you all crying, “but we need testing!”. Yes and I would like to give it to you, however tests for Alien::Base-based modules essentially come down to testing that the library was properly built (I can still make it run make test or make check) and that it is properly provisioned to Perl. It is this provisioning that is the problem, if I use a temporary/intermediate directory, I can make those tests pass, but its not testing the real world. If I don’t use a temporary directory, you can’t test for provisioning, but it never really was, so at least its not lying to you.

Finally ./Build install would first invoke the usual Perl installation, then run whatever make install-type command that is established for the module, copying the files from the build directory into the designated File::ShareDir-findable location under the Alien::Base-based module’s installed directory tree.

The upside to this procedure is that it will now allow the Makefile to properly handle the location handling, especially for Mac where this is a larger concern than I originally expected.

That said, thank you all for your patience. I really needed this time to consider this second path. I look forward to any comments you may have!

N.B. The source for Alien::Base is available through my GitHub page.

Hello again Perl world!

After a wonderful vacation, I came back to discover that I had far more work to do than I had realized. I have only just started to claw out of the heap and arrive at a place where I have had some time for Perl-ing.

First of all I need to apologize. I missed my Grant Report this month. While this is no excuse, there also was nothing to report. I do hope to keep honing in on the few remaining problems that Alien::Base has developed, but I am increasingly believing that a few of my initial assumptions may have been too flawed, possibly requiring a little bit of rewrite. That said, what I really need is someone who has a longer beard than I (metaphorically) to help me understand some Makefile/linking stuff to help me over the hump.

That brings me to some more interesting things. I had almost gotten my additions to vti’s PerlTuts running before my vacation, and now they have finally hit; thats right, live science tutorials in Perl are coming! For now its only a few pages on my plotting extension and PDL constructors, but believe me, that was the hard part.

Finally, this weekend I added up a few more features to Galileo, these include such novel features as deleting pages and easy links to adding users and pages. For those of you who don’t know (many I’m sure), Galileo is my attempt at a fully CPAN installable content management system (website). Its runs on Mojolicious and uses websockets for real-time updating wherever possible. Please take a look and let me know if you have any issues; especially if you use the (still untested, sorry) environment variables for controlling file locations.

Cheers!