On Mon, Jan 6, 2014 at 5:32 PM, Paul "LeoNerd" Evans <leon...@leonerd.org.uk> wrote: > On Mon, 6 Jan 2014 17:21:04 -0500 > Chris Marshall <devel.chm...@gmail.com> wrote: > >> Hi Paul- >> >> I'm a bit confused by the discussion so far. Alien modules are to >> provide external dependencies "wrapped up" for perl modules to use >> and not, in general, as a way to resolve C library dependencies. >> Once installed, an Alien module should provide all the information >> needed to use the library from/with perl without any other tools >> being involved. >> >> The only issue with the non-standard library location is that you >> need to have the right location for the various compile and link >> parts of install and execution for the perl module depending on the >> provided Alien library. In general, different platforms all have >> different default and not-so-default locations for system package >> installs. Even in the case of a root user install, the specific >> paths may need to be adjusted for the given platform type and/or >> local configuration. >> >> Here is a scenario that I think represents the case of interest >> below and how it might be implemented. >> >> I have a perl module MyXS that depends on library A and library B >> (through the fact that library A uses library B). In that case, >> the MyXS install would have a dependency on Alien::A, which, when >> satisfied, allows the MyXS configuration to determine everything >> about what is needed to use the library A bindings for its work. >> >> Since library A depends on library B, it might make sense to have >> an Alien::B module whose job it is to install/detect library B and >> to provide the needed information to Alien::A. NOTE: Alien::A >> will be providing whatever is needed on the library B configuration >> side to MyXS. This is all determined by what and how the libraries >> are to be used. >> >> It should also be possible to have OtherXS need library B and to >> have it as a direct dependency in CPAN which would configure or >> install with the needed information to support perl development or >> bindings using library B. > > So, ignore Alien and perl and everything for a moment. > > uniblium exists. > libtermkey depends on unibilium. uses pkg-config to find it. > > This works fine when root is installing it in a real place. > This works fine when non-root is installing it somewhere they made up > (e.g. $HOME/lib and $HOME/include), and sets PKG_CONFIG_PATH > appropriately. > > Now consider Alien. > > Alien::unibilium installs unibilium into the only place it knows how > - namely, somewhere in Perl's @INC dir.
Alien::unibilium provides the library and/or configuration to *perl*. > At this point, how does the C library "libtermkey"'s Makefile, manage > to find unibilium, to link against it? The user would have to set the PKG_CONFIG_PATH appropriately, perhaps even from an option in the Alien::unibilium CPAN install process. > The pkg-config that libtermkey's Makefile invokes cannot itself find > the unibilium.pc file because it's hidden in Perl's @INC dir. Not if PKG_CONFIG_PATH is set by the user. > I currently can't see how Alien::libtermkey /can/ provide a totally > hassle-free self-contained "just do it" installation of libtermkey and > its own C-level dependencies, because of this fact. > > This surely limits Alien wrappings to only being useful for C libraries > that don't themselves have other C-level dependencies. > > Unless I have missed something - how does anyone else do this? I think you missed my example above where Alien::libtermkey could be Alien::A and Alien::unibilium would be Alien::B (I think). Again, Alien modules are for *perl* to access external dependencies and not for other external dependencies to access eachother---you've already given a bunch of examples of the standard pkg-config use in builds. --Chris
