See the responsibilities sections of an Alien module in the Alien documentation:
> On installation, make sure the required package is there, otherwise install > it. This is handled at the Alien::libtermkey install. You detect or install libtermkey (in a perl-local directory) and are able to provide the configuration information needed to use libtermkey. > On usage, make sure the required package is there, else croak. The module needing libtermkey for its install and/or operation does a 'use Alien::libtermkey'. If it doesn't croak, then you can query the Alien::libtermkey for build/run time configuration info. Be sure to add Alien::libtermkey to the dependency information for the module. --Chris On Thu, Dec 19, 2013 at 7:03 PM, Paul LeoNerd <leon...@leonerd.org.uk> wrote: > On Thu, 19 Dec 2013 22:19:59 +0000 > Paul "LeoNerd" Evans <leon...@leonerd.org.uk> wrote: > >> 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. > > Actually a third idea comes to mind: > > * Subclass Module::Build, so that I can perform a regular dynamic > 'requires' on Alien::libtermkey if it turns out I need to. The > subclassing then exists in order to delay needing to know the > compiler/linker arguments until actual ./Build time. By now, it can > rely on having Alien::libtermkey installed if required, so can ask > it for arguments. > > They all feel equally messy and non-ideal in some way or other > though. :( > > Advice? > > -- > Paul "LeoNerd" Evans > > leon...@leonerd.org.uk > ICQ# 4135350 | Registered Linux# 179460 > http://www.leonerd.org.uk/
