Hey Chris, I think this is actually the usual approach, although it does have a cost for distributions as an extra package must be built separately. The costs are to build infrastructure (more packages need to be built), developer workload, and to mirrors (bandwidth). As an example, there are 3 packages in Debian [0] that match "libalien-(.*)-perl" - the small number of packages means that in practice, the cost isn't too bad. Someone once pointed out to me that Debian in particular is sometimes used in embedded computing scenarios, and that each package increases the metadata in the Debian packages list, which must be stored whether or not the package is installed (this is how Debian identifies available packages). For each package, it's probably not a big deal, but in the aggregate, it means more stuff can't be installed or won't fit on a given CD or DVD.
It would be nice if we had a better solution (one that did not require the cost of a "dummy" Alien module, which results in a pretty empty-looking package on distributions with binary-only packages, such as Debian). But, again, this seems to have been the usual approach we followed historically. I suppose one option is to have something similar to (or perhaps even as an extension of) Module::Install, where the necessary code to find a module is copied into inc/ and thus available at build time, but not required to be installed. This code could then put the linker options somewhere where the Perl module could pick them up later. I suppose there are other options as well, like a shared library that can do this sort of thing, I don't know. But given that that does not seem to be a readily available option at the moment, I would suggest that yes, you proceed with an Alien module. I would, however, suggest that you try to coordinate with downstream distributions where you can/have interest, as you might be able to make some simple changes now to make their lives easier. Debian in particular has a few PDL modules in use [1], though I'm not sure if your change would affect it. Cheers, Jonathan [0] http://packages.debian.org/search?keywords=libalien [1] http://packages.debian.org/search?keywords=libpdl On Sun, Jan 19, 2014 at 4:25 PM, Chris Marshall <devel.chm...@gmail.com> wrote: > I would like to factor out the explicit detection and configuration of > the PDL build process on external libraries (such as PROJ4, HDF5, > FFTW3,...) into corresponding Alien::PROJ4 or similar distributions. > The job of these Alien::XXX modules is to check for XXX. or install > XXX, and provide configuration to the perl module that does a 'use > Alien::XXX'. The Alien::XXX module would then provide the needed > information on how to build against the XXX dependency for the perl > module (usually an XS based module). > > It seems to me that the logical thing would be to have linux package > dependencies for PDL on Alien::XXX and then the package for Alien::XXX > would have a dependency on the underlying XXX library/dependency. > This would be for a binary install. Is this a reasonable approach > from the considerations of linux packaging? > > --Chris
