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. At this point, how does the C library "libtermkey"'s Makefile, manage to find unibilium, to link against it? The pkg-config that libtermkey's Makefile invokes cannot itself find the unibilium.pc file because it's hidden in Perl's @INC dir. 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? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
