Many Perl distributions use a Build.PL file instead of a Makefile.PL file to
drive distribution configuration, build, test and installation. Traditionally,
Build.PL uses Module::Build as the underlying build system. This module provides
a simple, lightweight, drop-in replacement.
Whereas Module::Build has over 6,700 lines of code; this module has less than
70, yet supports the features needed by most pure-Perl distributions.
Nuxi CloudABI is an application binary interface for UNIX-like operating
systems built around the concept of capability-based security. In a
nutshell, it means that you can run processes directly on top of a UNIX
kernel while keeping complete control over the actions the process is
allowed to perform.
This port installs a set of header files that contain the definitions
that describe the ABI itself: all of the constants, types, structures
and system calls.
Provides a simple but, hopefully, extensible way of having 'plugins'
for your module. Obviously this isn't going to be the be all and
end all of solutions but it works for me.
Essentially all it does is export a method into your namespace that
looks through a search path for .pm files and turn those into class
names.
Optionally it instantiates those classes for you.
More Opcodes information from opnames.h and opcode.h
The canonical list of operator names is the contents of the array
PL_op_name, defined and initialised in file opcode.h of the Perl
source distribution (and installed into the perl library).
Each operator has both a terse name (its opname) and a more verbose or
recognisable descriptive name. The opdesc function can be used to
return a description for an OP.
MooseX::Types::Signal exports a type, Signal, that recognizes valid signals
on your platform. The underlying type is a non-negative number, but there is
a coercion from strings to numbers that recognizes signals by name.
There are also more restrictive types, PerlSignal and UnixSignal. UnixSignal
only understands signals that are in your system's signal.h header file.
PerlSignal only understands signals that are in Perl's %Config hash. Signal
is either/or, with preference to UnixSignal over PerlSignal when coercing.
Often you want to create components that can be added to a class arbitrarily.
MouseX::Traits makes it easy for the end user to use these components. Instead
of requiring the user to create a named class with the desired roles applied,
or apply roles to the instance one-by-one, he can just create a new class from
yours with with_traits, and then instantiate that.
POEx::Role::SessionInstantiation provides a nearly seamless
integration for non-POE objects into a POE environment. It does this
by handling the POE stuff behind the scenes including allowing per
instances method changes, session registration to the Kernel, and
providing some defaults like setting an alias if supplied via the
attribute or constructor argument, or defining a _default that warns
if your object receives an event that it does not have.
This role exposes your class' methods as POE events.
The Params::Validate module allows you to validate method or function
call parameters to an arbitrary level of specificity. At the simplest
level, it is capable of validating the required parameters were given
and that no unspecified additional parameters were passed in. It is
also capable of determining that a parameter is of a specific type,
that it is an object of a certain class hierarchy, that it possesses
certain methods, or applying validation callbacks to arguments.
Pragmatic implements a default import method for processing pragmata before
passing the rest of the import to Exporter.
Perl automatically calls the import method when processing a use statement for a
module. Modules and use are documented in perlfunc and perlmod.
(Do not confuse Pragmatic with pragmatic modules, such as less, strict and the
like. They are standalone pragmata, and are not associated with any other
module.)
This module iterates over files and directories to identify ones
matching a user-defined set of rules. The API is based heavily on
File::Find::Rule, but with more explicit distinction between matching
rules and options that influence how directories are searched. A
Path::Iterator::Rule object is a collection of rules (match criteria)
with methods to add additional criteria. Options that control
directory traversal are given as arguments to the method that
generates an iterator.