Joel Berger

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.