So, here is the scenario. I have a largeish perl module with some XS code in which needs to compile against a C library that may well not be installed on the user's machine. I know I happen to have it installed myself. Most of the CPAN smoketest machines won't have it installed. In this particular example, the main module is called Tickit, and the underlying C library it will require is called libtermkey.
The solution so I gather is an Alien module. But how exactly is it supposed to work? The current way I have here is that Tickit's Build.PL script will first ask pkg-config (via ExtUtils::PkgConfig) if libtickit is installed. If so, all well and good, we can apply the extra compiler/linker arguments it provides to the Module::Build constructor, so the code gets compiled and linked correctly. However, if not we'll instead have to pull in Alien::libtermkey, and that presents a problem. I cannot interrupt the Build.PL process here and recursively invoke the CPAN client a second time to install Alien::libtermkey, such that I can now ask it instead to tell me its compiler/linker arguments. There's no point emitting a simple late dynamic build_requires on Alien::libtermkey, because I need to know at configure time what the compiler/linker arguments need to be. Instead I have two choices: * Forcibly install Alien::libtermkey /anyway/ by listing it under configure_requires, before I had any chance to ask pkg-config if such was in fact necessary. This feels wasteful. * Have Alien::libtermkey's Build.PL check using pkg-config whether the library is already installed; and if so do no real work other than to provide a lightweight wrapper around that. My current feeling is that honestly both possibilities suck, it's just a matter of picking which sucks less. Currently I am using the first alternative, and in addition some careful use of not -actually- declaring configure_requires in my real Build.PL file that I personally execute, but only having it meta_merge'ed in at the end. This issue has come to light because recent versions of Module::Build or one of its tree of dependencies have now taken objection to that, silently failing to produce me a META.yml/json file if I attempt to meta_merge such a key. So maybe I have misunderstood the whole idea? Maybe the Alien wrapper module is supposed to do "something" when it is installed, even if installing it simply creates the Alien/libterkey.pm file which says "Hey, so you already have that installed, I'll just wrap pkg-config". Is that the intention here? Currently my Alien::libtermkey distribution definitely pulls with it the underlying libtermkey source tarball, and compiles and installs it in lib/ even if a system one is already installed. Maybe that's wrong? Can someone explain this situation? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
