Alien::Build - Build external dependencies for use in CPAN


    version 2.80


     my $build = Alien::Build->load('./alienfile');
     $build->set_stage('/foo/mystage');  # needs to be absolute
     # files are now in /foo/mystage, it is your job (or
     # ExtUtils::MakeMaker, Module::Build, etc) to copy
     # those files into /usr/local


    This module provides tools for building external (non-CPAN)
    dependencies for CPAN. It is mainly designed to be used at install time
    of a CPAN client, and work closely with Alien::Base which is used at

    This is the detailed documentation for the Alien::Build class. If you
    are starting out you probably want to do so from one of these


      A broad overview of Alien-Build and its ecosystem.


      For users of an Alien::libfoo that is implemented using Alien::Base.
      (The developer of Alien::libfoo should provide the documentation
      necessary, but if not, this is the place to start).


      If you are writing your own Alien based on Alien::Build and


      If you have a common question that has already been answered, like
      "How do I use alienfile with some build system".


      This is for the brave souls who want to write plugins that will work
      with Alien::Build + alienfile.


      If you are concerned that Aliens might be downloading tarballs off
      the internet, then this is the place for you. This will discuss some
      of the risks of downloading (really any) software off the internet
      and will give you some tools to remediate these risks.

    Note that you will not usually create a Alien::Build instance directly,
    but rather be using a thin installer layer, such as Alien::Build::MM
    (for use with ExtUtils::MakeMaker) or Alien::Build::MB (for use with
    Module::Build). One of the goals of this project is to remain installer



     my $build = Alien::Build->new;

    This creates a new empty instance of Alien::Build. Normally you will
    want to use load below to create an instance of Alien::Build from an
    alienfile recipe.


     my $build = Alien::Build->load($alienfile);

    This creates an Alien::Build instance with the given alienfile recipe.


     my $build = Alien::Build->resume($alienfile, $root);

    Load a checkpointed Alien::Build instance. You will need the original
    alienfile and the build root (usually _alien), and a build that had
    been properly checkpointed using the checkpoint method below.


    There are three main properties for Alien::Build. There are a number of
    properties documented here with a specific usage. Note that these
    properties may need to be serialized into something primitive like JSON
    that does not support: regular expressions, code references of blessed

    If you are writing a plugin (Alien::Build::Plugin) you should use a
    prefix like "plugin_name" (where name is the name of your plugin) so
    that it does not interfere with other plugin or future versions of
    Alien::Build. For example, if you were writing
    Alien::Build::Plugin::Fetch::NewProtocol, please use the prefix

     sub init
       my($self, $meta) = @_;
       $meta->prop( plugin_fetch_newprotocol_foo => 'some value' );
         some_hook => sub {
           my($build) = @_;
           $build->install_prop->{plugin_fetch_newprotocol_bar} = 'some other value';
           $build->runtime_prop->{plugin_fetch_newprotocol_baz} = 'and another value';

    If you are writing a alienfile recipe please use the prefix my_:

     use alienfile;
     meta_prop->{my_foo} = 'some value';
     probe sub {
       my($build) = @_;
       $build->install_prop->{my_bar} = 'some other value';
       $build->install_prop->{my_baz} = 'and another value';

    Any property may be used from a command:

     probe [ 'some command %{.meta.plugin_fetch_newprotocol_foo}' ];
     probe [ 'some command %{.install.plugin_fetch_newprotocol_bar}' ];
     probe [ 'some command %{.runtime.plugin_fetch_newprotocol_baz}' ];
     probe [ 'some command %{.meta.my_foo}' ];
     probe [ 'some command %{.install.my_bar}' ];
     probe [ 'some command %{.runtime.my_baz}' ];


     my $href = $build->meta_prop;
     my $href = Alien::Build->meta_prop;

    Meta properties have to do with the recipe itself, and not any
    particular instance that probes or builds that recipe. Meta properties
    can be changed from within an alienfile using the meta_prop directive,
    or from a plugin from its init method (though should NOT be modified
    from any hooks registered within that init method). This is not
    strictly enforced, but if you do not follow this rule your recipe will
    likely be broken.


      This is a hint to an installer like Alien::Build::MM or
      Alien::Build::MB, that the library or tool contains architecture
      dependent files and so should be stored in an architecture dependent
      location. If not specified by your alienfile then it will be set to


      True if cryptographic digest should be checked when files are fetched
      or downloaded. This is set by Digest negotiator plugin.


      Some plugins (Alien::Build::Plugin::Build::Autoconf for example)
      support installing via DESTDIR. They will set this property to true
      if they plan on doing such an install. This helps Alien::Build find
      the staged install files and how to locate them.

      If available, DESTDIR is used to stage install files in a sub
      directory before copying the files into blib. This is generally
      preferred method if available.


      Regular expression for the files that should be copied from the
      DESTDIR into the stage directory. If not defined, then all files will
      be copied.


      Same as destdir_filter except applies to build_ffi instead of build.


      This properties contains the cryptographic digests (if any) that
      should be used when verifying any fetched and downloaded files. It is
      a hash reference where the key is the filename and the value is an
      array reference containing a pair of values, the first being the
      algorithm ('SHA256' is recommended) and the second is the actual
      digest. The special filename * may be specified to indicate that any
      downloaded file should match that digest. If there are both real
      filenames and the * placeholder, the real filenames will be used for
      filenames that match and any other files will use the placeholder.

       $build->meta_prop->{digest} = {
         'foo-1.00.tar.gz' => [ SHA256 => '9feac593aa49a44eb837de52513a57736457f1ea70078346c60f0bfc5f24f2c1' ],
         'foo-1.01.tar.gz' => [ SHA256 => '6bbde6a7f10ae5924cf74afc26ff5b7bc4b4f9dfd85c6b534c51bd254697b9e7' ],
         '*'               => [ SHA256 => '33a20aae3df6ecfbe812b48082926d55391be4a57d858d35753ab1334b9fddb3' ],

      Cryptographic signatures will only be checked if the check_digest
      meta property is set and if the Digest negotiator plugin is loaded.
      (The Digest negotiator can be used directly, but is also loaded
      automatically if you use the digest directive is used by the


      Environment variables to override during the build stage.


      Environment variable values will be interpolated with helpers.

       meta->prop->{env_interpolate} = 1;
       meta->prop->{env}->{PERL} = '%{perl}';


      Set to true if source code package is available locally. (that is not
      fetched over the internet). This is computed by default based on the
      start_url property. Can be set by an alienfile or plugin.


      Hash reference. Contains information about the platform beyond just


	Refers to the type of flags that the compiler accepts. May be
	expanded in the future, but for now, will be one of:


	  On Windows when using Microsoft Visual C++


	  Virtually everything else, including gcc on windows.

	The main difference is that with Visual C++ -LIBPATH should be used
	instead of -L, and static libraries should have the .LIB suffix
	instead of .a.


	$^O is frequently good enough to make platform specific logic in
	your alienfile, this handles the case when $^O can cover platforms
	that provide multiple environments that Perl might run under. The
	main example is windows, but others may be added in the future.








	Note that cygwin and msys are considered unix even though they run
	on windows!


	Contains a non-negative integer of available (possibly virtual)
	CPUs on the system. This can be used by build plugins to build in
	parallel. The environment variable ALIEN_CPU_COUNT can be set to
	override the CPU count.

	Contains a normalized name for the architecture of the current
	Perl. This can be used by fetch plugins to determine which binary
	packages to download. The value may be one of the following, but
	this list will be expanded as needed.


	  32-bit ARM soft-float


	  32-bit ARM hard-float


	  64-bit ARM


	  32-bit PowerPC (big-endian)


	  64-bit PowerPC (big-endian)


	  32-bit Intel (i386, i486, i686)


	  64-bit Intel (AMD64)


	  Unable to detect architecture. Please report this if needed.


      Build in a different directory from the where the source code is
      stored. In autoconf this is referred to as a "VPATH" build. Everyone
      else calls this an "out-of-source" build. When this property is true,
      instead of extracting to the source build root, the downloaded source
      will be extracted to an source extraction directory and the source
      build root will be empty. You can use the extract install property to
      get the location of the extracted source.


      True if a network fetch is available. This should NOT be set by an
      alienfile or plugin. This is computed based on the
      ALIEN_INSTALL_NETWORK environment variables.


      The default or start URL used by fetch plugins.


     my $href = $build->install_prop;

    Install properties are used during the install phase (either under
    share or system install). They are remembered for the entire install
    phase, but not kept around during the runtime phase. Thus they cannot
    be accessed from your Alien::Base based module.


      The prefix as understood by autoconf. This is only different on
      Windows Where MSYS is used and paths like C:/foo are represented as
      /C/foo which are understood by the MSYS tools, but not by Perl. You
      should only use this if you are using
      Alien::Build::Plugin::Build::Autoconf in your alienfile. This is set
      during before the build hook is run.


      The location of the downloaded archive (tar.gz, or similar) or
      directory. This will be undefined until the archive is actually


      This property contains optional details about a downloaded file. This
      property is populated by Alien::Build core. This property is a hash
      reference. The key is the path to the file that has been downloaded
      and the value is a hash reference with additional detail. All fields
      are optional.


	This, if available, with the cryptographic signature that was
	successfully matched against the downloaded file. It is an array
	reference with a pair of values, the algorithm (typically something
	like SHA256) and the digest.


	This, if available, will be the URL protocol used to fetch the
	downloaded file.


      Environment variables to override during the build stage. Plugins are
      free to set additional overrides using this hash.


      The location of the last source extraction. For a "out-of-source"
      build (see the out_of_source meta property above), this will only be
      set once. For other types of builds, the source code may be extracted
      multiple times, and thus this property may change.



      Hash containing information on a previously installed Alien of the
      same name, if available. This may be useful in cases where you want
      to reuse the previous install if it is still sufficient.



	The prefix for the previous install. Versions prior to 1.42
	unfortunately had this in typo form of preifx.



	The runtime properties from the previous install.


      Directory with patches, if available. This will be undef if there are
      no patches. When initially installing an alien this will usually be a
      sibling of the alienfile, a directory called patch. Once installed
      this will be in the share directory called _alien/patch. The former
      is useful for rebuilding an alienized package using af.


      The install time prefix. Under a destdir install this is the same as
      the runtime or final install location. Under a non-destdir install
      this is the stage directory (usually the appropriate share directory
      under blib).


      The build root directory. This will be an absolute path. It is the
      absolute form of ./_alien by default.


      The stage directory where files will be copied. This is usually the
      root of the blib share directory.


      After the probe step this property may contain the plugin class that
      performed the system probe. It shouldn't be filled in directly by the
      plugin (instead if should use the hook property probe_class, see
      below). This is optional, and not all probe plugins will provide this


      After the probe step this property may contain the plugin instance id
      that performed the system probe. It shouldn't be filled in directly
      by the plugin (instead if should use the hook property
      probe_instance_id, see below). This is optional, and not all probe
      plugins will provide this information.


     my $href = $build->plugin_instance_prop($plugin);

    This returns the private plugin instance properties for a given plugin.
    This method should usually only be called internally by plugins
    themselves to keep track of internal state. Because the content can be
    used arbitrarily by the owning plugin because it is private to the
    plugin, and thus is not part of the Alien::Build spec.


     my $href = $build->runtime_prop;

    Runtime properties are used during the install and runtime phases
    (either under share or system install). This should include anything
    that you will need to know to use the library or tool during runtime,
    and shouldn't include anything that is no longer relevant once the
    install process is complete.


      The version of Alien::Build used to install the library or tool.


      Alternate configurations. If the alienized package has multiple
      libraries this could be used to store the different compiler or
      linker flags for each library. Typically this will be set by a plugin
      in the gather stage (for either share or system installs).


      The compiler flags. This is typically set by a plugin in the gather
      stage (for either share or system installs).


      The static compiler flags. This is typically set by a plugin in the
      gather stage (for either share or system installs).


      The command name for tools where the name my differ from platform to
      platform. For example, the GNU version of make is usually make in
      Linux and gmake on FreeBSD. This is typically set by a plugin in the
      gather stage (for either share or system installs).


      The name DLL or shared object "name" to use when searching for
      dynamic libraries at runtime. This is passed into FFI::CheckLib, so
      if your library is something like or archive.dll you
      would set this to archive. This may be a string or an array of
      strings. This is typically set by a plugin in the gather stage (for
      either share or system installs).


      This property contains two sub properties:


         $build->runtime_prop->{ffi_checklib}->{share} = [ ... ];

	Array of additional FFI::CheckLib flags to pass in to find_lib for
	a share install.


	Array of additional FFI::CheckLib flags to pass in to find_lib for
	a system install.

	Among other things, useful for specifying the try_linker_script

         $build->runtime_prop->{ffi_checklib}->{system} = [ try_linker_script => 1 ];

      This is typically set by a plugin in the gather stage (for either
      share or system installs).


      [version 2.53]

      This property is an array reference of C code that will be passed
      into Inline::C to make sure that appropriate headers are
      automatically included. See "auto_include" in Inline::C for details.


      The install type. This is set by AB core after the probe hook is
      executed. Is one of:


	For when the library or tool is provided by the operating system,
	can be detected by Alien::Build, and is considered satisfactory by
	the alienfile recipe.


	For when a system install is not possible, the library source will
	be downloaded from the internet or retrieved in another appropriate
	fashion and built.


      The library flags. This is typically set by a plugin in the gather
      stage (for either share or system installs).


      The static library flags. This is typically set by a plugin in the
      gather stage (for either share or system installs).


      The version of the Perl module used to install the alien (if
      available). For example if Alien::curl is installing libcurl this
      would be the version of Alien::curl used during the install step.


      The final install root. This is usually they share directory.


      The version of the library or tool. This is typically set by a plugin
      in the gather stage (for either share or system installs).


     my $href = $build->hook_prop;

    Hook properties are for the currently running (if any) hook. They are
    used only during the execution of each hook and are discarded after. If
    no hook is currently running then hook_prop will return undef.


      The name of the currently running hook.

    version (probe)

      Probe and PkgConfig plugins may set this property indicating the
      version of the alienized package. Not all plugins and configurations
      may be able to provide this.

    probe_class (probe)

      Probe and PkgConfig plugins may set this property indicating the
      plugin class that made the probe. If the probe results in a system
      install this will be propagated to system_probe_class for later use.

    probe_instance_id (probe)

      Probe and PkgConfig plugins may set this property indicating the
      plugin instance id that made the probe. If the probe results in a
      system install this will be propagated to system_probe_instance_id
      for later use.




    Save any install or runtime properties so that they can be reloaded on
    a subsequent run in a separate process. This is useful if your build
    needs to be done in multiple stages from a Makefile, such as with
    ExtUtils::MakeMaker. Once checkpointed you can use the resume
    constructor (documented above) to resume the probe/build/install]


     my $dir = $build->root;

    This is just a shortcut for:

     my $root = $build->install_prop->{root};

    Except that it will be created if it does not already exist.


     my $type = $build->install_type;

    This will return the install type. (See the like named install property
    above for details). This method will call probe if it has not already
    been called.


     my $rule = $build->download_rule;

    This returns install rule as a string. This is determined by the
    environment and should be one of:


      Warn only if fetching via non secure source (secure sources include
      https, and bundled files, may include other encrypted protocols in
      the future).


      Require that any downloaded source package have a cryptographic
      signature in the alienfile and that signature matches what was


      Require that any downloaded source package is fetched via secure


      Require that any downloaded source package is either fetched via a
      secure source or has a cryptographic signature in the alienfile and
      that signature matches what was downloaded.


      Require that any downloaded source package is both fetched via a
      secure source and has a cryptographic signature in the alienfile and
      that signature matches what was downloaded.

    The current default is warn, but in the near future this will be
    upgraded to digest_or_encrypt.



    Set the final (unstaged) prefix. This is normally only called by
    Alien::Build::MM and similar modules. It is not intended for use from
    plugins or from an alienfile.



    Sets the stage directory. This is normally only called by
    Alien::Build::MM and similar modules. It is not intended for use from
    plugins or from an alienfile.


     my $hash = $build->requires($phase);

    Returns a hash reference of the modules required for the given phase.
    Phases include:


      These modules must already be available when the alienfile is read.


      These modules are used during either a system or share install.


      These modules are used during the build phase of a share install.


      These modules are used during the build phase of a system install.



    This loads the appropriate modules for the given phase (see requires
    above for a description of the phases).


     my $install_type = $build->probe;

    Attempts to determine if the operating system has the library or tool
    already installed. If so, then the string system will be returned and a
    system install will be performed. If not, then the string share will be
    installed and the tool or library will be downloaded and built from

    If the environment variable ALIEN_INSTALL_TYPE is set, then that will
    force a specific type of install. If the detection logic cannot
    accommodate the install type requested then it will fail with an



    Download the source, usually as a tarball, usually from the internet.

    Under a system install this does not do anything.


     my $res = $build->fetch;
     my $res = $build->fetch($url, %options);

    Fetch a resource using the fetch hook. Returns the same hash structure
    described below in the fetch hook documentation.

    [version 2.39]

    As of Alien::Build 2.39, these options are supported:


       my $res = $build->fetch($url, http_headers => [ $key1 => $value1, $key2 => $value 2, ... ]);

      Set the HTTP request headers on all outgoing HTTP requests. Note that
      not all protocols or fetch plugins support setting request headers,
      but the ones that do not should issue a warning if you try to set
      request headers and they are not supported.



     my $bool = $build->check_digest($path);

    Checks any cryptographic signatures for the given file. The file is
    specified by $path which may be one of:


      Containing the path to the file to be checked.


      Containing the path to the file to be checked.


      A Hash reference containing information about a file. See the fetch
      hook for details on the format.

    Returns true if the cryptographic signature matches, false if
    cryptographic signatures are disabled. Will throw an exception if the
    signature does not match, or if no plugin provides the correct
    algorithm for checking the signature.


     my $decoded_res = $build->decode($res);

    Decode the HTML or file listing returned by fetch. Returns the same
    hash structure described below in the decode hook documentation.


     my $sorted_res = $build->prefer($res);

    Filter and sort candidates. The preferred candidate will be returned
    first in the list. The worst candidate will be returned last. Returns
    the same hash structure described below in the prefer hook


     my $dir = $build->extract;
     my $dir = $build->extract($archive);

    Extracts the given archive into a fresh directory. This is normally
    called internally to Alien::Build, and for normal usage is not needed
    from a plugin or alienfile.



    Run the build step. It is expected that probe and download have already
    been performed. What it actually does depends on the type of install:


      The source is extracted, and built as determined by the alienfile
      recipe. If there is a gather_share that will be executed last.


      The gather_system hook will be executed.



    Run the test phase



    Clean files from the final install location. The default implementation
    removes all files recursively except for the _alien directory. This is
    helpful when you have an old install with files that may break the new

    For a non-share install this doesn't do anything.


     $build->system($command, @args);

    Interpolates the command and arguments and run the results using the
    Perl system command.



    Send a message to the log. By default this prints to STDOUT.


     my $meta = Alien::Build->meta;
     my $meta = $build->meta;

    Returns the meta object for your Alien::Build class or instance. The
    meta object is a way to manipulate the recipe, and so any changes to
    the meta object should be made before the probe, download or build



     my $href = $build->meta->prop;

    Meta properties. This is the same as calling meta_prop on the class or
    Alien::Build instance.


     Alien::Build->meta->add_requires($phase, $module => $version, ...);

    Add the requirement to the given phase. Phase should be one of:






     my $interpolator = $build->meta->interpolator;
     my $interpolator = Alien::Build->interpolator;

    Returns the Alien::Build::Interpolate instance for the Alien::Build


     my $bool = $build->meta->has_hook($name);
     my $bool = Alien::Build->has_hook($name);

    Returns if there is a usable hook registered with the given name.


     $build->meta->register_hook($name, $instructions);
     Alien::Build->meta->register_hook($name, $instructions);

    Register a hook with the given name. $instruction should be either a
    code reference, or a command sequence, which is an array reference.


     $build->meta->default_hook($name, $instructions);
     Alien::Build->meta->default_hook($name, $instructions);

    Register a default hook, which will be used if the alienfile does not
    register its own hook with that name.


     $build->meta->around_hook($hook_name, $code);
     Alien::Build->meta->around_hook($hook_name, $code);

    Wrap the given hook with a code reference. This is similar to a Moose
    method modifier, except that it wraps around the given hook instead of
    a method. For example, this will add a probe system requirement:

       probe => sub {
         my $orig = shift;
         my $build = shift;
         my $type = $orig->($build, @_);
         return $type unless $type eq 'system';
         # also require a configuration file
         if(-f '/etc/foo.conf')
           return 'system';
           return 'share';


     $build->meta->after_hook($hook_name, sub {
       my(@args) = @_;

    Execute the given code reference after the hook. The original arguments
    are passed into the code reference.


     $build->meta->before_hook($hook_name, sub {
       my(@args) = @_;

    Execute the given code reference before the hook. The original
    arguments are passed into the code reference.


     Alien::Build->meta->apply_plugin($name, @args);

    Apply the given plugin with the given arguments.


    Alien::Build responds to these environment variables:


      The default log class used. See Alien::Build::Log and


      Override the logic in Alien::Build::Plugin::PkgConfig::Negotiate
      which chooses the best pkg-config plugin.


      semicolon separated list of plugins to automatically load after
      parsing your alienfile.


      semicolon separated list of plugins to automatically load before
      parsing your alienfile.


      Perl source file which can override some global defaults for
      Alien::Build, by, for example, setting preload and postload plugins.


      This value determines the rules by which types of downloads are
      allowed. The legal values listed under "download_rule", plus default
      which will be the default for the current version of Alien::Build.
      For this version that default is warn.


      If set to true (the default), then network fetch will be allowed. If
      set to false, then network fetch will not be allowed.

      What constitutes a local vs. network fetch is determined based on the
      start_url and local_source meta properties. An alienfile or plugin
      could override this detection (possibly inappropriately), so this
      variable is not a substitute for properly auditing of Perl modules
      for environments that require that.


      If set to share or system, it will override the system detection
      logic. If set to default, it will use the default setting for the
      alienfile. The behavior of other values is undefined.

      Although the recommended way for a consumer to use an Alien::Base
      based Alien is to declare it as a static configure and build-time
      dependency, some consumers may prefer to fallback on using an Alien
      only when the consumer itself cannot detect the necessary package. In
      some cases the consumer may want the user to opt-in to using an Alien
      before requiring it.

      To keep the interface consistent among Aliens, the consumer of the
      fallback opt-in Alien may fallback on the Alien if the environment
      variable ALIEN_INSTALL_TYPE is set to any value. The rationale is
      that by setting this environment variable the user is aware that
      Alien modules may be installed and have indicated consent. The actual
      implementation of this, by its nature would have to be in the
      consuming CPAN module.


      This environment variable will be manipulated during a destdir


      This environment variable can be used to override the program name
      for pkg-config when using the command line plugin:

    ftp_proxy, all_proxy

      If these environment variables are set, it may influence the Download
      negotiation plugin Alien::Build::Plugin::Download::Negotiate. Other
      proxy variables may be used by some Fetch plugins, if they support


    The intent of the Alien-Build team is to support the same versions of
    Perl that are supported by the Perl toolchain. As of this writing that
    means 5.16 and better.

    Please feel encouraged to report issues that you encounter to the
    project GitHub Issue tracker:

    Better if you can fix the issue yourself, please feel encouraged to
    open pull-request on the project GitHub:

    If you are confounded and have questions, join us on the #native
    channel on The Alien-Build developers frequent this
    channel and can probably help point you in the right direction. If you
    don't have an IRC client handy, you can use this web interface:


    Alien::Build::Manual::AlienAuthor, Alien::Build::Manual::AlienUser,
    Alien::Build::Manual::Contributing, Alien::Build::Manual::FAQ,

    alienfile, Alien::Build::MM, Alien::Build::Plugin, Alien::Base, Alien


    Alien::Base was originally written by Joel Berger, the rest of this
    project would not have been possible without him getting the project
    started. Thanks to his support I have been able to augment the original
    Alien::Base system with a reliable set of tools (Alien::Build,
    alienfile, Test::Alien), which make up this toolset.

    The original Alien::Base is still copyright (c) 2012-2020 Joel Berger.
    It has the same license as the rest of the Alien::Build and related
    tools distributed as Alien-Build. Joel Berger thanked a number of
    people who helped in in the development of Alien::Base, in the
    documentation for that module.

    I would also like to acknowledge the other members of the PerlAlien
    github organization, Zakariyya Mughal (sivoais, ZMUGHAL) and mohawk
    (ETJ). Also important in the early development of Alien::Build were the
    early adopters Chase Whitener (genio, CAPOEIRAB, author of
    Alien::libuv), William N. Braswell, Jr (willthechill, WBRASWELL, author
    of Alien::JPCRE2 and Alien::PCRE2) and Ahmad Fatoum (a3f, ATHREEF,
    author of Alien::libudev and Alien::LibUSB).

    The Alien ecosystem owes a debt to Dan Book, who goes by Grinnz on IRC,
    for answering question about how to use Alien::Build and friends.


    Author: Graham Ollis <>


    Diab Jerius (DJERIUS)

    Roy Storey (KIWIROY)

    Ilya Pavlov

    David Mertens (run4flat)

    Mark Nunberg (mordy, mnunberg)

    Christian Walde (Mithaldu)

    Brian Wightman (MidLifeXis)

    Zaki Mughal (zmughal)

    mohawk (mohawk2, ETJ)

    Vikas N Kumar (vikasnkumar)

    Flavio Poletti (polettix)

    Salvador Fandiño (salva)

    Gianni Ceccarelli (dakkar)

    Pavel Shaydo (zwon, trinitum)

    Kang-min Liu (劉康民, gugod)

    Nicholas Shipp (nshp)

    Juan Julián Merelo Guervós (JJ)

    Joel Berger (JBERGER)

    Petr Písař (ppisar)

    Lance Wicks (LANCEW)

    Ahmad Fatoum (a3f, ATHREEF)

    José Joaquín Atria (JJATRIA)

    Duke Leto (LETO)

    Shoichi Kaji (SKAJI)

    Shawn Laffan (SLAFFAN)

    Paul Evans (leonerd, PEVANS)

    Håkon Hægland (hakonhagland, HAKONH)

    nick nauwelaerts (INPHOBIA)

    Florian Weimer


    This software is copyright (c) 2011-2022 by Graham Ollis.

    This is free software; you can redistribute it and/or modify it under
    the same terms as the Perl 5 programming language system itself.