Alien-ROOT
view release on metacpan or search on metacpan
inc/inc_Locale-Maketext-Simple/Locale/Maketext/Simple.pm view on Meta::CPAN
X is C<present>, or appending C<ed> to <_1> otherwise.
=head1 OPTIONS
All options are passed either via the C<use> statement, or via an
explicit C<import>.
=head2 Class
By default, B<Locale::Maketext::Simple> draws its source from the
calling package's F<auto/> directory; you can override this behaviour
by explicitly specifying another package as C<Class>.
=head2 Path
If your PO and MO files are under a path elsewhere than C<auto/>,
you may specify it using the C<Path> option.
=head2 Style
By default, this module uses the C<maketext> style of C<[_1]> and
C<[quant,_1]> for interpolation. Alternatively, you can specify the
C<gettext> style, which uses C<%1> and C<%quant(%1)> for interpolation.
This option is case-insensitive.
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
If you run the C<Build> script without any arguments, it runs the
C<build> action, which in turn runs the C<code> and C<docs> actions.
This is analogous to the C<MakeMaker> I<make all> target.
=item clean
[version 0.01]
This action will clean up any files that the build process may have
created, including the C<blib/> directory (but not including the
C<_build/> directory and the C<Build> script itself).
=item code
[version 0.20]
This action builds your code base.
By default it just creates a C<blib/> directory and copies any C<.pm>
and C<.pod> files from your C<lib/> directory into the C<blib/>
directory. It also compiles any C<.xs> files from C<lib/> and places
them in C<blib/>. Of course, you need a working C compiler (probably
the same one that built perl itself) for the compilation to work
properly.
The C<code> action also runs any C<.PL> files in your F<lib/>
directory. Typically these create other files, named the same but
without the C<.PL> ending. For example, a file F<lib/Foo/Bar.pm.PL>
could create the file F<lib/Foo/Bar.pm>. The C<.PL> files are
processed first, so any C<.pm> files (or other kinds that we deal
with) will get copied correctly.
=item config_data
[version 0.26]
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
C<perl Build.PL>, followed by the 'build' and 'test' actions in that directory.
Use PERL_MB_OPT or F<.modulebuildrc> to set options that should be applied
during subprocesses
=item docs
[version 0.20]
This will generate documentation (e.g. Unix man pages and HTML
documents) for any installable items under B<blib/> that
contain POD. If there are no C<bindoc> or C<libdoc> installation
targets defined (as will be the case on systems that don't support
Unix manpages) no action is taken for manpages. If there are no
C<binhtml> or C<libhtml> installation targets defined no action is
taken for HTML documents.
=item fakeinstall
[version 0.02]
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
With an optional argument specifying an action name (e.g. C<Build help
test>), the 'help' action will show you any POD documentation it can
find for that action.
=item html
[version 0.26]
This will generate HTML documentation for any binary or library files
under B<blib/> that contain POD. The HTML documentation will only be
installed if the install paths can be determined from values in
C<Config.pm>. You can also supply or override install paths on the
command line by specifying C<install_path> values for the C<binhtml>
and/or C<libhtml> installation targets.
=item install
[version 0.01]
This action will use C<ExtUtils::Install> to install the files from
C<blib/> into the system. See L<"INSTALL PATHS">
for details about how Module::Build determines where to install
things, and how to influence this process.
If you want the installation process to look around in C<@INC> for
other versions of the stuff you're installing and try to delete it,
you can use the C<uninst> parameter, which tells C<ExtUtils::Install> to
do so:
./Build install uninst=1
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
This is an action intended for use by module authors, not people
installing modules. It will generate a boilerplate MANIFEST.SKIP file
if one does not already exist.
=item manpages
[version 0.28]
This will generate man pages for any binary or library files under
B<blib/> that contain POD. The man pages will only be installed if the
install paths can be determined from values in C<Config.pm>. You can
also supply or override install paths by specifying there values on
the command line with the C<bindoc> and C<libdoc> installation
targets.
=item pardist
[version 0.2806]
Generates a PAR binary distribution for use with L<PAR> or L<PAR::Dist>.
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
This action is just like the C<clean> action, but also removes the
C<_build> directory and the C<Build> script. If you run the
C<realclean> action, you are essentially starting over, so you will
have to re-create the C<Build> script again.
=item retest
[version 0.2806]
This is just like the C<test> action, but doesn't actually build the
distribution first, and doesn't add F<blib/> to the load path, and
therefore will test against a I<previously> installed version of the
distribution. This can be used to verify that a certain installed
distribution still works, or to see whether newer versions of a
distribution still pass the old regression tests, and so on.
=item skipcheck
[version 0.05]
Reports which files are skipped due to the entries in the
F<MANIFEST.SKIP> file (See L<manifest> for details)
=item test
[version 0.01]
This will use C<Test::Harness> or C<TAP::Harness> to run any regression
tests and report their results. Tests can be defined in the standard
places: a file called C<test.pl> in the top-level directory, or several
files ending with C<.t> in a C<t/> directory.
If you want tests to be 'verbose', i.e. show details of test execution
rather than just summary information, pass the argument C<verbose=1>.
If you want to run tests under the perl debugger, pass the argument
C<debugger=1>.
If you want to have Module::Build find test files with different file
name extensions, pass the C<test_file_exts> argument with an array
of extensions, such as C<[qw( .t .s .z )]>.
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
=head1 SEE ALSO
perl(1), L<Module::Build::Cookbook>, L<Module::Build::Authoring>,
L<Module::Build::API>, L<ExtUtils::MakeMaker>
F<META.yml> Specification:
L<CPAN::Meta::Spec>
L<http://www.dsmit.com/cons/>
L<http://search.cpan.org/dist/PerlBuildSystem/>
=cut
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
=item mozilla
The distribution is licensed under the Mozilla Public
License. (L<http://opensource.org/licenses/mozilla1.0.php> or
L<http://opensource.org/licenses/mozilla1.1.php>)
=item open_source
The distribution is licensed under some other Open Source
Initiative-approved license listed at
L<http://www.opensource.org/licenses/>.
=item perl
The distribution may be copied and redistributed under the same terms
as Perl itself (this is by far the most common licensing option for
modules on CPAN). This is a dual license, in which the user may
choose between either the GPL or the Artistic license.
=item restrictive
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
my $output_file = shift;
open my $fh, ">", $output_file or die "Can't open $output_file: $!";
print $fh <<'END';
#!/usr/bin/perl
print "Hello, world!\n";
END
PL files are not installed by default, so its safe to put them in
F<lib/> and F<bin/>.
=item pm_files
[version 0.19]
An optional parameter specifying the set of C<.pm> files in this
distribution, specified as a hash reference whose keys are the files'
locations in the distributions, and whose values are their logical
locations based on their package name, i.e. where they would be found
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
distribution, you could specify your layout in your C<Build.PL> like
this:
my $build = Module::Build->new
(
module_name => 'Foo::Bar',
...
pm_files => { 'Bar.pm' => 'lib/Foo/Bar.pm' },
);
Note that the values should include C<lib/>, because this is where
they would be found in a "normal" Module::Build-style distribution.
Note also that the path specifications are I<always> given in
Unix-like format, not in the style of the local system.
=item pod_files
[version 0.19]
Just like C<pm_files>, but used for specifying the set of C<.pod>
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
An optional parameter specifying a set of files that should be used as
C<Test::Harness>-style regression tests to be run during the C<test>
action. May be given as an array reference of the files, or as a hash
reference whose keys are the files (and whose values will currently be
ignored). If the argument is given as a single string (not in an
array reference), that string will be treated as a C<glob()> pattern
specifying the files to use.
The default is to look for a F<test.pl> script in the top-level
directory of the distribution, and any files matching the glob pattern
C<*.t> in the F<t/> subdirectory. If the C<recursive_test_files>
property is true, then the C<t/> directory will be scanned recursively
for C<*.t> files.
=item use_tap_harness
[version 0.2808_03]
An optional parameter indicating whether or not to use TAP::Harness for
testing rather than Test::Harness. Defaults to false. If set to true, you must
therefore be sure to add TAP::Harness as a requirement for your module in
L</build_requires>. Implicitly set to a true value if C<tap_harness_args> is
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
stored in the args hash for that option key. When called with two arguments,
the second argument is assigned to the args hash under the key passed as the
first argument.
=item autosplit_file($from, $to)
[version 0.28]
Invokes the L<AutoSplit> module on the C<$from> file, sending the
output to the C<lib/auto> directory inside C<$to>. C<$to> is
typically the C<blib/> directory.
=item base_dir()
[version 0.14]
Returns a string containing the root-level directory of this build,
i.e. where the C<Build.PL> script and the C<lib> directory can be
found. This is usually the same as the current working directory,
because the C<Build> script will C<chdir()> into this directory as
soon as it begins execution.
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
executable bit set, then the destination file will be made executable.
=item create_build_script()
[version 0.05]
Creates an executable script called C<Build> in the current directory
that will be used to execute further user actions. This script is
roughly analogous (in function, not in form) to the Makefile created
by C<ExtUtils::MakeMaker>. This method also creates some temporary
data in a directory called C<_build/>. Both of these will be removed
when the C<realclean> action is performed.
Among the files created in C<_build/> is a F<_build/prereqs> file
containing the set of prerequisites for this distribution, as a hash
of hashes. This file may be C<eval()>-ed to obtain the authoritative
set of prerequisites, which might be different from the contents of
F<META.yml> (because F<Build.PL> might have set them dynamically).
But fancy developers take heed: do not put any fancy custom runtime
code in the F<_build/prereqs> file, leave it as a static declaration
containing only strings and numbers. Similarly, do not alter the
structure of the internal C<< $self->{properties}{requires} >> (etc.)
data members, because that's where this data comes from.
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
The supplied C<$path> should be an absolute path to install elements
of C<$type>. The return value is C<$path>.
Assigning the value C<undef> to an element causes it to be removed.
=item install_types()
[version 0.28]
Returns a list of installable types that this build knows about.
These types each correspond to the name of a directory in F<blib/>,
and the list usually includes items such as C<lib>, C<arch>, C<bin>,
C<script>, C<libdoc>, C<bindoc>, and if HTML documentation is to be
built, C<libhtml> and C<binhtml>. Other user-defined types may also
exist.
=item invoked_action()
[version 0.28]
This is the name of the original action invoked by the user. This
inc/inc_Module-Build/Module/Build/API.pod view on Meta::CPAN
Returns a hash reference indicating the C<requires> prerequisites that
were passed to the C<new()> method.
=item rscan_dir($dir, $pattern)
[version 0.28]
Uses C<File::Find> to traverse the directory C<$dir>, returning a
reference to an array of entries matching C<$pattern>. C<$pattern>
may either be a regular expression (using C<qr//> or just a plain
string), or a reference to a subroutine that will return true for
wanted entries. If C<$pattern> is not given, all entries will be
returned.
Examples:
# All the *.pm files in lib/
$m->rscan_dir('lib', qr/\.pm$/)
# All the files in blib/ that aren't *.html files
inc/inc_Module-Build/Module/Build/Authoring.pod view on Meta::CPAN
=head1 SEE ALSO
perl(1), L<Module::Build>(3), L<Module::Build::API>(3),
L<Module::Build::Cookbook>(3), L<ExtUtils::MakeMaker>(3), L<YAML>(3)
F<META.yml> Specification:
L<CPAN::META::Spec>
L<http://www.dsmit.com/cons/>
L<http://search.cpan.org/dist/PerlBuildSystem/>
=cut
inc/inc_Module-Build/Module/Build/Bundling.pod view on Meta::CPAN
In order to install a distribution using Module::Build, users must
have Module::Build available on their systems. There are two ways
to do this. The first way is to include Module::Build in the
C<configure_requires> metadata field. This field is supported by
recent versions L<CPAN> and L<CPANPLUS> and is a standard feature
in the Perl core as of Perl 5.10.1. Module::Build now adds itself
to C<configure_requires> by default.
The second way supports older Perls that have not upgraded CPAN or
CPANPLUS and involves bundling an entire copy of Module::Build
into the distribution's C<inc/> directory. This is the same approach
used by L<Module::Install>, a modern wrapper around ExtUtils::MakeMaker
for Makefile.PL based distributions.
The "trick" to making this work for Module::Build is making sure the
highest version Module::Build is used, whether this is in C<inc/> or
already installed on the user's system. This ensures that all necessary
features are available as well as any new bug fixes. This is done using
the new L<inc::latest> module.
A "normal" Build.PL looks like this (with only the minimum required
fields):
use Module::Build;
Module::Build->new(
inc/inc_Module-Build/Module/Build/Bundling.pod view on Meta::CPAN
Module::Build->new(
module_name => 'Foo::Bar',
license => 'perl',
)->create_build_script;
For I<authors>, when "Build dist" is run, Module::Build will be
automatically bundled into C<inc> according to the rules for
L<inc::latest>.
For I<users>, inc::latest will load the latest Module::Build, whether
installed or bundled in C<inc/>.
=head1 BUNDLING OTHER CONFIGURATION DEPENDENCIES
The same approach works for other configuration dependencies -- modules
that I<must> be available for Build.PL to run. All other dependencies can
be specified as usual in the Build.PL and CPAN or CPANPLUS will install
them after Build.PL finishes.
For example, to bundle the L<Devel::AssertOS::Unix> module (which ensures a
"Unix-like" operating system), one could do this:
inc/inc_Module-Build/Module/Build/Bundling.pod view on Meta::CPAN
Module::Build->new(
module_name => 'Foo::Bar',
license => 'perl',
)->create_build_script;
The C<inc::latest> module creates bundled directories based on the packlist
file of an installed distribution. Even though C<inc::latest> takes module
name arguments, it is better to think of it as bundling and making
available entire I<distributions>. When a module is loaded through
C<inc::latest>, it looks in all bundled distributions in C<inc/> for a
newer module than can be found in the existing C<@INC> array.
Thus, the module-name provided should usually be the "top-level" module
name of a distribution, though this is not strictly required. For example,
L<Module::Build> has a number of heuristics to map module names to
packlists, allowing users to do things like this:
use inc::latest 'Devel::AssertOS::Unix';
even though Devel::AssertOS::Unix is contained within the Devel-CheckOS
inc/inc_Module-Build/Module/Build/Cookbook.pm view on Meta::CPAN
use Module::Build;
my $build = Module::Build->new
(
module_name => 'Foo::Bar',
...other stuff here...
);
$build->add_build_element('dat');
$build->create_build_script;
This will find all F<.dat> files in the F<lib/> directory, copy them
to the F<blib/lib/> directory during the C<build> action, and install
them during the C<install> action.
If your extra files aren't located in the C<lib/> directory in your
distribution, you can explicitly say where they are, just as you'd do
with F<.pm> or F<.pod> files:
use Module::Build;
my $build = new Module::Build
(
module_name => 'Foo::Bar',
dat_files => {'some/dir/Bar.dat' => 'lib/Foo/Bar.dat'},
...other stuff here...
);
inc/inc_Module-Build/Module/Build/Cookbook.pm view on Meta::CPAN
}
EOF
my $build = $class->new
(
module_name => 'Foo::Bar',
...other stuff here...
);
$build->add_build_element('dat');
$build->create_build_script;
If your extra files don't go in F<lib/> but in some other place, see
L<"Adding new elements to the install process"> for how to actually
get them installed.
Please note that these examples use some capabilities of Module::Build
that first appeared in version 0.26. Before that it could
still be done, but the simple cases took a bit more work.
=head2 Adding new elements to the install process
By default, Module::Build creates seven subdirectories of the F<blib>
directory during the build process: F<lib>, F<arch>, F<bin>,
F<script>, F<bindoc>, F<libdoc>, and F<html> (some of these may be
missing or empty if there's nothing to go in them). Anything copied
to these directories during the build will eventually be installed
during the C<install> action (see L<Module::Build/"INSTALL PATHS">.
If you need to create a new custom type of installable element, e.g. C<conf>,
then you need to tell Module::Build where things in F<blib/conf/>
should be installed. To do this, use the C<install_path> parameter to
the C<new()> method:
my $build = Module::Build->new
(
...other stuff here...
install_path => { conf => $installation_path }
);
Or you can call the C<install_path()> method later:
$build->install_path(conf => $installation_path);
The user may also specify the path on the command line:
perl Build.PL --install_path conf=/foo/path/etc
The important part, though, is that I<somehow> the install path needs
to be set, or else nothing in the F<blib/conf/> directory will get
installed, and a runtime error during the C<install> action will
result.
See also L<"Adding new file types to the build process"> for how to
create the stuff in F<blib/conf/> in the first place.
=head1 EXAMPLES ON CPAN
Several distributions on CPAN are making good use of various features
of Module::Build. They can serve as real-world examples for others.
=head2 SVN-Notify-Mirror
L<http://search.cpan.org/~jpeacock/SVN-Notify-Mirror/>
John Peacock, author of the C<SVN-Notify-Mirror> distribution, says:
=over 4
=item 1. Using C<auto_features>, I check to see whether two optional
modules are available - SVN::Notify::Config and Net::SSH;
=item 2. If the S::N::Config module is loaded, I automatically
generate test files for it during Build (using the C<PL_files>
inc/inc_Module-Build/Module/Build/PPMMaker.pm view on Meta::CPAN
# This is a nasty hack because it fails if there is no >= op
if ($op eq '>=') {
$min_version = $version;
last;
}
}
# PPM4 spec requires a '::' for top level modules
$modname .= '::' unless $modname =~ /::/;
$ppd .= qq! <REQUIRE NAME="$modname" VERSION="$min_version" />\n!;
}
}
# We only include these tags if this module involves XS, on the
# assumption that pure Perl modules will work on any OS.
if (keys %{$build->find_xs_files}) {
my $perl_version = $self->_ppd_version($build->perl_version);
$ppd .= sprintf(<<'EOF', $self->_varchname($build->config) );
<ARCHITECTURE NAME="%s" />
EOF
}
foreach my $codebase (@codebase) {
$self->_simple_xml_escape($codebase);
$ppd .= sprintf(<<'EOF', $codebase);
<CODEBASE HREF="%s" />
EOF
}
$ppd .= <<'EOF';
</IMPLEMENTATION>
</SOFTPKG>
EOF
my $ppd_file = "$dist{name}.ppd";
my $fh = IO::File->new(">$ppd_file")
inc/inc_Module-Build/Module/Build/PPMMaker.pm view on Meta::CPAN
On the command line, builds a .ppd file:
./Build ppd
=head1 DESCRIPTION
This package contains the code that builds F<.ppd> "Perl Package
Description" files, in support of ActiveState's "Perl Package
Manager". Details are here:
L<http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/>
=head1 AUTHOR
Dave Rolsky <autarch@urth.org>, Ken Williams <kwilliams@cpan.org>
=head1 COPYRIGHT
Copyright (c) 2001-2006 Ken Williams. All rights reserved.
inc/inc_Module-Build/Module/Build/Platform/cygwin.pm view on Meta::CPAN
use Module::Build::Platform::Unix;
use vars qw(@ISA);
@ISA = qw(Module::Build::Platform::Unix);
sub manpage_separator {
'.'
}
# Copied from ExtUtils::MM_Cygwin::maybe_command()
# If our path begins with F</cygdrive/> then we use the Windows version
# to determine if it may be a command. Otherwise we use the tests
# from C<ExtUtils::MM_Unix>.
sub _maybe_command {
my ($self, $file) = @_;
if ($file =~ m{^/cygdrive/}i) {
require Module::Build::Platform::Windows;
return Module::Build::Platform::Windows->_maybe_command($file);
}
inc/inc_Module-Build/Module/Build/WithXSpp.pm view on Meta::CPAN
There is C<extra_compiler_flags>, too, if you need it.
=item *
You create two folders in the main distribution folder:
F<src> and F<xsp>.
=item *
You put any C++ code that you want to build and include
in the module into F<src/>. All the typical C(++) file
extensions are recognized and will be compiled to object files
and linked into the module. And headers in that folder will
be accessible for C<#include E<lt>myheader.hE<gt>>.
For good measure, move a copy of F<ppport.h> to that directory.
See L<Devel::PPPort>.
=item *
You do not write normal XS files. Instead, you write XS++ and
put it into the F<xsp/> folder in files with the C<.xsp>
extension. Do not worry, you can include verbatim XS blocks
in XS++. For details on XS++, see L<ExtUtils::XSpp>.
=item *
If you need to do any XS type mapping, put your typemaps
into a F<.map> file in the C<xsp> directory. Alternatively,
search CPAN for an appropriate typemap module (cf.
L<ExtUtils::Typemaps::Default> for an explanation).
XS++ typemaps belong into F<.xspt> files in the same directory.
=item *
In this scheme, F<lib/> only contains Perl module files (and POD).
If you started from a pure-Perl distribution, don't forget to add
these magic two lines to your main module:
require XSLoader;
XSLoader::load('My::Module', $VERSION);
=back
=head1 SEE ALSO
inc/inc_Module-Load/Module/Load.pm view on Meta::CPAN
If the argument matches only C<\w>, it could either be a module or a
file. We will try to find C<file.pm> first in C<@INC> and if that
fails, we will try to find C<file> in @INC. If both fail, we die with
the respective error messages.
=back
=head1 Caveats
Because of a bug in perl (#19213), at least in version 5.6.1, we have
to hardcode the path separator for a require on Win32 to be C</>, like
on Unix rather than the Win32 C<\>. Otherwise perl will not read its
own %INC accurately double load files if they are required again, or
in the worst case, core dump.
C<Module::Load> cannot do implicit imports, only explicit imports.
(in other words, you always have to specify explicitly what you wish
to import from a module, even if the functions are in that modules'
C<@EXPORT>)
=head1 ACKNOWLEDGEMENTS
lib/Alien/ROOT.pm view on Meta::CPAN
my $self = shift;
Carp::croak('You must call this method as an object') unless ref($self);
return $self->_config_get_one_line_param('bindir', qw(--bindir));
}
=head2 $aroot->libdir
This method returns the path to the library (F<lib/>) directory of ROOT.
Example code:
my $dir = $aroot->libdir;
=cut
sub libdir {
my $self = shift;
( run in 1.047 second using v1.01-cache-2.11-cpan-df04353d9ac )