ExtUtils::InstallPaths tries to make install path resolution as easy as
possible.
When you want to install a module, it needs to figure out where to install
things. The nutshell version of how this works is that default installation
locations are determined from ExtUtils::Config, and they may be individually
overridden by using the install_path attribute. An install_base attribute lets
you specify an alternative installation root like /home/foo and prefix does
something similar in a rather different (and more complicated) way. destdir lets
you specify a temporary installation directory like /tmp/install in case you
want to create bundled-up installable packages.
ExtUtils::LibBuilder is a tool to build C libraries.
This utility is designed to write a Makefile for an extension module from a
Makefile.PL. It is based on the Makefile.SH model provided by Andy Dougherty
and the perl5-porters.
It splits the task of generating the Makefile into several subroutines that
can be individually overridden. Each subroutine returns the text it wishes to
have written to the Makefile.
MakeMaker is object oriented. Each directory below the current directory that
contains a Makefile.PL is treated as a separate object. This makes it possible
to write an unlimited number of Makefiles with a single invocation of
WriteMakefile().
ExtUtils::Manifest provides a number of utilities to write and check a MANIFEST
file. At present the list includes mkmanifest, manicheck, filecheck, fullcheck,
skipcheck, manifind, maniread, manicopy, and maniadd.
ExtUtils::ParseXS will compile XS code into C code by embedding the
constructs necessary to let C functions manipulate Perl values and creates
the glue necessary to let Perl access those functions. The compiler uses
typemaps to determine how to map C function parameters and variables to Perl
values.
ExtUtils::XSBuilder is a set modules to parse C header files and create XS
glue code and documentation out of it. Ideally this allows to "write" an
interface to a C library without coding a line. Since no C-API is ideal,
some adjustments are necessary most of the time. So to use this module you
must still be familiar with C and XS programming, but it removes a lot of
stupid work and copy&paste from you. Also when the C API changes, most
of the time you only have to rerun XSBuilder to get your new Perl API.
XS++ is just a thin layer over plain XS, hence to use it you are
supposed to know, at the very least, C++ and XS. This means that
you will need typemaps for both the normal XS pre-processor xsubpp
and the XS++ pre-processor xspp.
File-HStore is a very minimalist perl library to store files on a
filesystem using a very simple hash-based storage.
File-HStore is nothing more than a simple wrapper interface to a
storage containing a specific directory structure where files are hold
based on their hashes. The name of the directories is based on the
first two bytes of the hexadecimal form of the digest. The file is
stored and named with its full hexadecimal form in the corresponding
prefixed directory.
The current version is supporting the SHA-1 and SHA-2 (256 bits)
algorithm. The FAT (Free Archive Toolkit) format is also supported and
it is composed of the date of submission plus the SHA-2 real digest
part.
This class implements a simple state machine pattern, allowing you to
quickly build rules-based state machines in Perl. As a simple
implementation of a powerful concept, it differs slightly from an ideal
DFA model in that it does not enforce a single possible switch from one
state to another. Rather, it short circuits the evaluation of the rules
for such switches, so that the first rule to return a true value will
trigger its switch and no other switch rules will be checked. (But see the
strict attribute and parameter to new().) It differs from an NFA model in
that it offers no back-tracking. But in truth, you can use it to build a
state machine that adheres to either model--hence the more generic FSA
moniker.
File::Assets is a tool for managing JavaScript and CSS assets in a (web)
application. It allows you to "publish" assests in one place after having
specified them in different parts of the application (e.g. throughout request
and template processing phases).