App-Staticperl/staticperl.pod

=head1 NAME

staticperl - perl, libc, 50 modules all in one 500kb file

=head1 SYNOPSIS

   staticperl help      # print the embedded documentation
   staticperl fetch     # fetch and unpack perl sources
   staticperl configure # fetch and then configure perl
   staticperl build     # configure and then build perl
   staticperl install   # build and then install perl
   staticperl clean     # clean most intermediate files (restart at configure)
   staticperl distclean # delete everything installed by this script
   staticperl cpan      # invoke CPAN shell
   staticperl instmod path...        # install unpacked modules
   staticperl instcpan modulename... # install modules from CPAN
   staticperl mkbundle <bundle-args...> # see documentation
   staticperl mkperl <bundle-args...>   # see documentation

Typical Examples:

   staticperl install   # fetch, configure, build and install perl
   staticperl cpan      # run interactive cpan shell
   staticperl mkperl -M '"Config_heavy.pl"' # build a perl that supports -V
   staticperl mkperl -MAnyEvent::Impl::Perl -MAnyEvent::HTTPD -MURI -MURI::http
                        # build a perl with the above modules linked in

=head1 DESCRIPTION

This script helps you creating single-file perl interpreters, or embedding
a pelr interpreter in your apps. Single-file means that it is fully
self-contained - no separate shared objects, no autoload fragments, no .pm
or .pl files are needed. And when linking statically, you can create (or
embed) a single file that contains perl interpreter, libc, all the modules
you need and all the libraries you need.

With uclibc and upx on x86, you can create a single 500kb binary that
contains perl and 50 modules such as AnyEvent, EV, IO::AIO, Coro and so
on. Or any other choice of modules.

The created files do not need write access to the filesystem (like PAR
does). In fact, since this script is in many ways similar to PAR::Packer,
here are the differences:

=over 4

=item * The generated executables are much smaller than PAR created ones.

Shared objects and the perl binary contain a lot of extra info, while
the static nature of F<staticperl> allows the linker to remove all
functionality and meta-info not required by the final executable. Even
extensions statically compiled into perl at build time will only be
present in the final executable when needed.

In addition, F<staticperl> can strip perl sources much more effectively
than PAR.

=item * The generated executables start much faster.

There is no need to unpack files, or even to parse Zip archives (which is
slow and memory-consuming business).

=item * The generated executables don't need a writable filesystem.

F<staticperl> loads all required files directly from memory. There is no
need to unpack files into a temporary directory.

=item * More control over included files.

PAR tries to be maintainance and hassle-free - it tries to include more files
than necessary to make sure everything works out of the box. The extra files
(such as the unicode database) can take substantial amounts of memory and filesize.

With F<staticperl>, the burden is mostly with the developer - only direct
compile-time dependencies and L<AutoLoader> are handled automatically.
This means the modules to include often need to be tweaked manually.

=item * PAR works out of the box, F<staticperl> does not.

Maintaining your own custom perl build can be a pain in the ass, and while
F<staticperl> tries to make this easy, it still requires a custom perl
build and possibly fiddling with some modules. PAR is likely to produce
results faster.

=back

=head1 HOW DOES IT WORK?

Simple: F<staticperl> downloads, compile and installs a perl version of
your choice in F<~/.staticperl>. You can add extra modules either by
letting F<staticperl> install them for you automatically, or by using CPAN
and doing it interactively. This usually takes 5-10 minutes, depending on
the speed of your computer and your internet conenction.

It is possible to do program development at this stage, too.

Afterwards, you create a list of files and modules you want to include,
and then either build a new perl binary (that acts just like a normla perl
except everything is compiled in), or you create bundle files (basically C
sources you can use to embed all files into your project).

This step is very fast (a few seconds if PPI is not used for stripping,
more seconds otherwise, as PPI is very slow), and can be tweaked and
repeated as often as necessary.

=head1 THE F<STATICPERL> SCRIPT

This module installs a script called F<staticperl> into your perl
binary directory. The script is fully self-contained, and can be used
without perl (for example, in an uClibc chroot environment). In fact,
it can be extracted from the C<App::Staticperl> distribution tarball as
F<bin/staticperl>, without any installation.

F<staticperl> interprets the first argument as a command to execute,
optionally followed by any parameters.

There are two command categories: the "phase 1" commands which deal with
installing perl and perl modules, and the "phase 2" commands, which deal
with creating binaries and bundle files.

=head2 PHASE 1 COMMANDS: INSTALLING PERL

The most important command is F<install>, which does basically
everything. The default is to download and install perl 5.12.2 and a few
modules required by F<staticperl> itself, but all this can (and should) be
changed - see L<CONFIGURATION>, below.

The command

   staticperl install

Is normally all you need: It installs the perl interpreter in
F<~/.staticperl/perl>. It downloads, configures, builds and installs the
perl interpreter if required.

Most of the following commands simply run one or more steps of this
sequence.

To force recompilation or reinstalaltion, you need to run F<staticperl
distclean> first.

=over 4

=item F<staticperl fetch>

Runs only the download and unpack phase, unless this has already happened.

=item F<staticperl configure>

Configures the unpacked perl sources, potentially after downloading them first.

=item F<staticperl build>

Builds the configured perl sources, potentially after automatically
configuring them.

=item F<staticperl install>

Wipes the perl installation directory (usually F<~/.staticperl/perl>) and installs
the perl distribution, potentially aftering building it first.

=item F<staticperl cpan> [args...]

Starts an interactive CPAN shell that you cna use to install further
modules. Installs the perl first if neccessary, but apart from that,
no magic is involved: you could just as well run it manually via
F<~/.staticperl/perl/bin/cpan>.

Any additional arguments are simply passed to the F<cpan> command.

=item F<staticperl instcpan> module...

Tries to install all the modules given and their dependencies, using CPAN.

Example:

   staticperl instcpan EV AnyEvent::HTTPD Coro

=item F<staticperl instsrc> directory...

In the unlikely case that you have unpacked perl modules around and want
to install from these instead of from CPAN, you cna do this using this
command by specifying all the directories with modules in them that you
want to have built.

=item F<staticperl clean>

Runs F<make distclean> in the perl source directory (and potentially
cleans up other intermediate files). This can be used to clean up
intermediate files without removing the installed perl interpreter.

=item F<staticperl distclean>

This wipes your complete F<~/.staticperl> directory. Be careful with this,
it nukes your perl download, perl sources, perl distribution and any
installed modules. It is useful if you wish to start over "from scratch"
or when you want to uninstall F<staticperl>.

=back

=head2 PHASE 2 COMMANDS: BUILDING PERL BUNDLES

Building (linking) a new F<perl> binary is handled by a separate
script. To make it easy to use F<staticperl> from a F<chroot>, the script
is embedded into F<staticperl>, which will write it out and call for you
with any arguments you pass:

   staticperl mkbundle mkbundle-args...

In the oh so unlikely case of something not working here, you
can run the script manually as well (by default it is written to
F<~/.staticperl/mkbundle>).

F<mkbundle> is a more conventional command and expect the argument
syntax commonly used on unix clones. For example, this command builds
a new F<perl> binary and includes F<Config.pm> (for F<perl -V>),
F<AnyEvent::HTTPD>, F<URI> and a custom F<httpd> script (from F<eg/httpd>
in this distribution):

   # first make sure we have perl and the required modules
   staticperl instcpan AnyEvent::HTTPD

   # now build the perl
   staticperl mkperl -M'"Config_heavy.pl"' -MAnyEvent::Impl::Perl \
                     -MAnyEvent::HTTPD -MURI::http \
                     --add 'eg/httpd httpd.pm'

   # finally, invoke it
   ./perl -Mhttpd

As you can see, things are not quite as trivial: the L<Config> module has
a hidden dependency which is not even a perl module (F<Config_heavy.pl>),
L<AnyEvent> needs at least one event loop backend that we have to
specifymanually (here L<AnyEvent::Impl::Perl>), and the F<URI> module
(required by L<AnyEvent::HTTPD>) implements various URI schemes as extra
modules - since L<AnyEvent::HTTPD> only needs C<http> URIs, we only need
to include that module.

=head3 OPTION PROCESSING

All options can be given as arguments on the commandline (typically using
long (e.g. C<--verbose>) or short option (e.g. C<-v>) style). Since
specifying a lot of modules can make the commandlien very cumbersome,
you can put all long options into a "bundle specification file" (with or
without C<--> prefix) and specify this bundle file instead.

For example, the command given earlier could also look like this:

   staticperl mkperl httpd.bundle

And all options could be in F<httpd.bundle>:
   
   use "Config_heavy.pl"
   use AnyEvent::Impl::Perl
   use AnyEvent::HTTPD
   use URI::http
   add eg/httpd httpd.pm

All options that specify modules or files to be added are processed in the
order given on the commandline (that affects the C<--use> and C<--eval>
options at the moment).

=head3 MKBUNDLE OPTIONS

=over 4

=item --verbose | -v

Increases the verbosity level by one (the default is C<1>).

=item --quiet | -q

Decreases the verbosity level by one.

=item --strip none|pod|ppi

Specify the stripping method applied to reduce the file of the perl
sources included.

The default is C<pod>, which uses the L<Pod::Strip> module to remove all
pod documenatiton, which is very fast and reduces filesize a lot.

The C<ppi> method uses L<PPI> to parse and condense the perl sources. This
saves a lot more than just L<Pod::Strip>, and is generally safer, but is
also a lot slower, so is best used for production builds.

Last not least, in the unlikely case where C<pod> is too slow, or some
module gets mistreated, you can specify C<none> to not mangle included
perl sources in any way.

=item --perl

After writing out the bundle files, try to link a new perl interpreter. It
will be called F<perl> and will be left in the current working
directory. The bundle files will be removed.

This switch is automatically ued when F<staticperl> is invoked with the
C<mkperl> command (instead of C<mkbundle>):

   # build a new ./perl with only common::sense in it - very small :)
   staticperl mkperl -Mcommon::sense

=item --use module | -Mmodule

Include the named module and all direct dependencies. This is done by
C<require>'ing the module in a subprocess and tracing which other modules
and files it actually loads. If the module uses L<AutoLoader>, then all
splitfiles will be included as well.

Example: include AnyEvent and AnyEvent::Impl::Perl.

   staticperl mkbundle --use AnyEvent --use AnyEvent::Impl::Perl

Sometimes you want to load old-style "perl libraries" (F<.pl> files), or
maybe other weirdly named files. To do that, you need to quote the name in
single or double quoutes. When given on the commandline, you probably need
to quote once more to avoid your shell interpreting it. Common cases that
need this are F<Config_heavy.pl> and F<utf8_heavy.pl>.

Example: include the required files for F<perl -V> to work in all its
glory (F<Config.pm> is included automatically by this).

   # bourne shell
   staticperl mkbundle --use '"Config_heavy.pl"'

   # bundle specification file
   use "Config_heavy.pl"

The C<-Mmodule> syntax is included as an alias that might be easier to
remember than C<use>. Or maybe it confuses people. Time will tell. Or
maybe not. Argh.

=item --eval "perl code" | -e "perl code"

Sometimes it is easier (or necessary) to specify dependencies using perl
code, or maybe one of the modules you use need a special use statement. In
that case, you can use C<eval> to execute some perl snippet or set some
variables or whatever you need. All files C<require>'d or C<use>'d in the
script are included in the final bundle.

Keep in mind that F<mkbundle> will only C<require> the modules named
by the C<--use> option, so do not expect the symbols from modules you
C<--use>'d earlier on the commandlien to be available.

Example: force L<AnyEvent> to detect a backend and therefore include it
in the final bundle.

   staticperl mkbundle --eval 'use AnyEvent; AnyEvent::detect'

   # or like this
   staticperl mkbundle -MAnyEvent --eval 'use AnyEvent; AnyEvent::detect'

Example: use a separate "bootstrap" script that C<use>'s lots of modules
and include this in the final bundle, to be executed automatically.

   staticperl mkbundle --eval 'do "bootstrap"' --boot bootstrap

=item --boot filename

Include the given file in the bundle and arrange for it to be executed
(using a C<require>) before anything else when the new perl is
initialised. This can be used to modify C<@INC> or anything else before
the perl interpreter executes scripts given on the commandline (or via
C<-e>). This works even in an embedded interpreter.

=item --add "file" | --add "file alias"

Adds the given (perl) file into the bundle (and optionally call it
"alias"). This is useful to include any custom files into the bundle.

Example: embed the file F<httpd> as F<httpd.pm> when creating the bundle.

   staticperl mkperl --add "httpd httpd.pm"

It is also a great way to add any custom modules:

   # specification file
   add file1 myfiles/file1
   add file2 myfiles/file2
   add file3 myfiles/file3

=item --static

When C<--perl> is also given, link statically instead of dynamically. The
default is to link the new perl interpreter fully dynamic (that means all
perl modules are linked statically, but all external libraries are still
referenced dynamically).

Keep in mind that Solaris doesn't support static linking at all, and
systems based on GNU libc don't really support it in a usable fashion
either. Try uClibc if you want to create fully statically linked
executables, or try the C<--staticlibs> option to link only some libraries
statically.

=item any other argument

Any other argument is interpreted as a bundle specification file, which
supports most long options (without extra quoting), one option per line.

=back

=head2 F<STATCPERL> CONFIGURATION AND HOOKS

During (each) startup, F<staticperl> tries to source the following shell
files in order:

   /etc/staticperlrc
   ~/.staticperlrc
   $STATICPERL/rc

They can be used to override shell variables, or define functions to be
called at specific phases.

Note that the last file is erased during F<staticperl distclean>, so
generally should not be used.

=head3 CONFIGURATION VARIABLES

=head4 Variables you I<should> override

=over 4

=item C<EMAIL>

The e-mail address of the person who built this binary. Has no good
default, so should be specified by you.

=back

=head4 Variables you I<might want> to override

=over 4

=item C<PERLVER>

The perl version to install - default is currently C<5.12.2>, but C<5.8.9>
is also a good choice (5.8.9 is much smaller than 5.12.2, while 5.10.1 is
about as big as 5.12.2).

=item C<CPAN>

The URL of the CPAN mirror to use (e.g. L<http://mirror.netcologne.de/cpan/>).

=item C<PERL_CPPFLAGS>, C<PERL_OPTIMIZE>, C<PERL_LDFLAGS>, C<PERL_LIBS>

These flags are passed to perl's F<Configure> script, and are generally
optimised for small size (at the cost of performance). Since they also
contain subtle workarounds around various build issues, changing these
usually requires understanding their default values - best look at the top
of the F<staticperl> script for more info on these.

=item C<STATICPERL>

The directory where staticperl stores all its files
(default: F<~/.staticperl>).

=item C<PREFIX>

The prefix where perl get's installed (default: F<$STATICPERL/perl>),
i.e. where the F<bin> and F<lib> subdirectories will end up.

=item C<PERL_MM_USE_DEFAULT>, C<EV_EXTRA_DEFS>, others

Usually set to C<1> to make modules "less inquisitive" during their
installation, you can set any environment variable you want - some modules
(such as L<Coro> or L<EV>) use environment variables for further tweaking.

=item C<EXTRA_MODULES>

Additional modules installed during F<staticperl install>. Here you can
set which modules you want have to installed from CPAN.

Example: I really really need EV, AnyEvent, Coro and IO::AIO.

   EXTRA_MODULES="EV AnyEvent Coro IO::AIO"

Note that you cna also use a C<postinstall> hook to achieve this, and
more.

=back

=head4 Variables you I<probably do not want> to override

=over 4

=item C<MKBUNDLE>

Where F<staticperl> writes the C<mkbundle> command to
(default: F<$STATICPERL/mkbundle>).

=item C<STATICPERL_MODULES>

Additional modules needed by C<mkbundle> - should therefore not be changed
unless you know what you are doing.

=back

=head3 OVERRIDABLE HOOKS

In addition to environment variables, it is possible to provide some
shell functions that are called at specific times. To provide your own
commands, justd efine the corresponding function.

Example: install extra modules from CPAN and from some directories
at F<staticperl install> time.

   postinstall() {
      rm -rf lib/threads.* # weg mit Schaden
      instcpan IO::AIO EV
      instsrc ~/src/AnyEvent
      instsrc ~/src/XML-Sablotron-1.0100001
      instcpan AnyEvent::HTTPD
   }

=over 4

=item postconfigure

Called after configuring, but before building perl. Current working
directory is the perl source directory.

Could be used to tailor/patch config.sh (followed by F<./Configure -S>) or
do any other modifications.

=item postbuild

Called after building, but before installing perl. Current working
directory is the perl source directory.

I have no clue what this could be used for - tell me.

=item postinstall

Called after perl and any extra modules have been installed in C<$PREFIX>,
but before setting the "installation O.K." flag.

The current working directory is C<$PREFIX>, but maybe you should not rely
on that.

This hook is most useful to customise the installation, by deleting files,
or installing extra modules using the C<instcpan> or C<instsrc> functions.

The script must return with a zero exit status, or the installation will
fail.

=back

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://software.schmorp.de/pkg/staticperl.html
Revision:	1.2
Committed:	Mon Dec 6 20:53:44 2010 UTC (13 years, 5 months ago) by root
Branch:	MAIN
Changes since 1.1:	+280 -15 lines
Log Message:	* empty log message *
#	User	Rev	Content
1	root	1.1	=head1 NAME
2
3			staticperl - perl, libc, 50 modules all in one 500kb file
4
5			=head1 SYNOPSIS
6
7			staticperl help # print the embedded documentation
8			staticperl fetch # fetch and unpack perl sources
9			staticperl configure # fetch and then configure perl
10			staticperl build # configure and then build perl
11			staticperl install # build and then install perl
12			staticperl clean # clean most intermediate files (restart at configure)
13			staticperl distclean # delete everything installed by this script
14			staticperl cpan # invoke CPAN shell
15			staticperl instmod path... # install unpacked modules
16			staticperl instcpan modulename... # install modules from CPAN
17			staticperl mkbundle <bundle-args...> # see documentation
18			staticperl mkperl <bundle-args...> # see documentation
19
20			Typical Examples:
21
22			staticperl install # fetch, configure, build and install perl
23			staticperl cpan # run interactive cpan shell
24			staticperl mkperl -M '"Config_heavy.pl"' # build a perl that supports -V
25			staticperl mkperl -MAnyEvent::Impl::Perl -MAnyEvent::HTTPD -MURI -MURI::http
26			# build a perl with the above modules linked in
27
28			=head1 DESCRIPTION
29
30			This script helps you creating single-file perl interpreters, or embedding
31			a pelr interpreter in your apps. Single-file means that it is fully
32			self-contained - no separate shared objects, no autoload fragments, no .pm
33			or .pl files are needed. And when linking statically, you can create (or
34			embed) a single file that contains perl interpreter, libc, all the modules
35			you need and all the libraries you need.
36
37			With uclibc and upx on x86, you can create a single 500kb binary that
38			contains perl and 50 modules such as AnyEvent, EV, IO::AIO, Coro and so
39			on. Or any other choice of modules.
40
41			The created files do not need write access to the filesystem (like PAR
42			does). In fact, since this script is in many ways similar to PAR::Packer,
43			here are the differences:
44
45			=over 4
46
47			=item * The generated executables are much smaller than PAR created ones.
48
49			Shared objects and the perl binary contain a lot of extra info, while
50			the static nature of F<staticperl> allows the linker to remove all
51			functionality and meta-info not required by the final executable. Even
52			extensions statically compiled into perl at build time will only be
53			present in the final executable when needed.
54
55			In addition, F<staticperl> can strip perl sources much more effectively
56			than PAR.
57
58			=item * The generated executables start much faster.
59
60			There is no need to unpack files, or even to parse Zip archives (which is
61			slow and memory-consuming business).
62
63			=item * The generated executables don't need a writable filesystem.
64
65			F<staticperl> loads all required files directly from memory. There is no
66			need to unpack files into a temporary directory.
67
68			=item * More control over included files.
69
70			PAR tries to be maintainance and hassle-free - it tries to include more files
71			than necessary to make sure everything works out of the box. The extra files
72			(such as the unicode database) can take substantial amounts of memory and filesize.
73
74			With F<staticperl>, the burden is mostly with the developer - only direct
75			compile-time dependencies and L<AutoLoader> are handled automatically.
76			This means the modules to include often need to be tweaked manually.
77
78			=item * PAR works out of the box, F<staticperl> does not.
79
80			Maintaining your own custom perl build can be a pain in the ass, and while
81			F<staticperl> tries to make this easy, it still requires a custom perl
82			build and possibly fiddling with some modules. PAR is likely to produce
83			results faster.
84
85			=back
86
87			=head1 HOW DOES IT WORK?
88
89			Simple: F<staticperl> downloads, compile and installs a perl version of
90			your choice in F<~/.staticperl>. You can add extra modules either by
91			letting F<staticperl> install them for you automatically, or by using CPAN
92			and doing it interactively. This usually takes 5-10 minutes, depending on
93			the speed of your computer and your internet conenction.
94
95			It is possible to do program development at this stage, too.
96
97			Afterwards, you create a list of files and modules you want to include,
98			and then either build a new perl binary (that acts just like a normla perl
99			except everything is compiled in), or you create bundle files (basically C
100			sources you can use to embed all files into your project).
101
102			This step is very fast (a few seconds if PPI is not used for stripping,
103			more seconds otherwise, as PPI is very slow), and can be tweaked and
104			repeated as often as necessary.
105
106			=head1 THE F<STATICPERL> SCRIPT
107
108			This module installs a script called F<staticperl> into your perl
109			binary directory. The script is fully self-contained, and can be used
110			without perl (for example, in an uClibc chroot environment). In fact,
111			it can be extracted from the C<App::Staticperl> distribution tarball as
112			F<bin/staticperl>, without any installation.
113
114			F<staticperl> interprets the first argument as a command to execute,
115			optionally followed by any parameters.
116
117			There are two command categories: the "phase 1" commands which deal with
118			installing perl and perl modules, and the "phase 2" commands, which deal
119			with creating binaries and bundle files.
120
121			=head2 PHASE 1 COMMANDS: INSTALLING PERL
122
123			The most important command is F<install>, which does basically
124			everything. The default is to download and install perl 5.12.2 and a few
125			modules required by F<staticperl> itself, but all this can (and should) be
126			changed - see L<CONFIGURATION>, below.
127
128			The command
129
130			staticperl install
131
132			Is normally all you need: It installs the perl interpreter in
133			F<~/.staticperl/perl>. It downloads, configures, builds and installs the
134			perl interpreter if required.
135
136			Most of the following commands simply run one or more steps of this
137			sequence.
138
139			To force recompilation or reinstalaltion, you need to run F<staticperl
140			distclean> first.
141
142			=over 4
143
144			=item F<staticperl fetch>
145
146			Runs only the download and unpack phase, unless this has already happened.
147
148			=item F<staticperl configure>
149
150			Configures the unpacked perl sources, potentially after downloading them first.
151
152			=item F<staticperl build>
153
154			Builds the configured perl sources, potentially after automatically
155			configuring them.
156
157			=item F<staticperl install>
158
159			Wipes the perl installation directory (usually F<~/.staticperl/perl>) and installs
160			the perl distribution, potentially aftering building it first.
161
162			=item F<staticperl cpan> [args...]
163
164			Starts an interactive CPAN shell that you cna use to install further
165			modules. Installs the perl first if neccessary, but apart from that,
166			no magic is involved: you could just as well run it manually via
167			F<~/.staticperl/perl/bin/cpan>.
168
169			Any additional arguments are simply passed to the F<cpan> command.
170
171			=item F<staticperl instcpan> module...
172
173			Tries to install all the modules given and their dependencies, using CPAN.
174
175			Example:
176
177			staticperl instcpan EV AnyEvent::HTTPD Coro
178
179			=item F<staticperl instsrc> directory...
180
181			In the unlikely case that you have unpacked perl modules around and want
182			to install from these instead of from CPAN, you cna do this using this
183			command by specifying all the directories with modules in them that you
184			want to have built.
185
186			=item F<staticperl clean>
187
188			Runs F<make distclean> in the perl source directory (and potentially
189			cleans up other intermediate files). This can be used to clean up
190			intermediate files without removing the installed perl interpreter.
191
192			=item F<staticperl distclean>
193
194			This wipes your complete F<~/.staticperl> directory. Be careful with this,
195			it nukes your perl download, perl sources, perl distribution and any
196			installed modules. It is useful if you wish to start over "from scratch"
197			or when you want to uninstall F<staticperl>.
198
199			=back
200
201			=head2 PHASE 2 COMMANDS: BUILDING PERL BUNDLES
202
203			Building (linking) a new F<perl> binary is handled by a separate
204			script. To make it easy to use F<staticperl> from a F<chroot>, the script
205			is embedded into F<staticperl>, which will write it out and call for you
206			with any arguments you pass:
207
208			staticperl mkbundle mkbundle-args...
209
210			In the oh so unlikely case of something not working here, you
211	root	1.2	can run the script manually as well (by default it is written to
212	root	1.1	F<~/.staticperl/mkbundle>).
213
214			F<mkbundle> is a more conventional command and expect the argument
215			syntax commonly used on unix clones. For example, this command builds
216			a new F<perl> binary and includes F<Config.pm> (for F<perl -V>),
217			F<AnyEvent::HTTPD>, F<URI> and a custom F<httpd> script (from F<eg/httpd>
218			in this distribution):
219
220			# first make sure we have perl and the required modules
221			staticperl instcpan AnyEvent::HTTPD
222
223			# now build the perl
224			staticperl mkperl -M'"Config_heavy.pl"' -MAnyEvent::Impl::Perl \
225			-MAnyEvent::HTTPD -MURI::http \
226			--add 'eg/httpd httpd.pm'
227
228			# finally, invoke it
229			./perl -Mhttpd
230
231			As you can see, things are not quite as trivial: the L<Config> module has
232			a hidden dependency which is not even a perl module (F<Config_heavy.pl>),
233			L<AnyEvent> needs at least one event loop backend that we have to
234			specifymanually (here L<AnyEvent::Impl::Perl>), and the F<URI> module
235			(required by L<AnyEvent::HTTPD>) implements various URI schemes as extra
236			modules - since L<AnyEvent::HTTPD> only needs C<http> URIs, we only need
237			to include that module.
238
239			=head3 OPTION PROCESSING
240
241			All options can be given as arguments on the commandline (typically using
242			long (e.g. C<--verbose>) or short option (e.g. C<-v>) style). Since
243			specifying a lot of modules can make the commandlien very cumbersome,
244			you can put all long options into a "bundle specification file" (with or
245			without C<--> prefix) and specify this bundle file instead.
246
247			For example, the command given earlier could also look like this:
248
249			staticperl mkperl httpd.bundle
250
251			And all options could be in F<httpd.bundle>:
252
253			use "Config_heavy.pl"
254			use AnyEvent::Impl::Perl
255			use AnyEvent::HTTPD
256			use URI::http
257			add eg/httpd httpd.pm
258
259	root	1.2	All options that specify modules or files to be added are processed in the
260			order given on the commandline (that affects the C<--use> and C<--eval>
261			options at the moment).
262
263	root	1.1	=head3 MKBUNDLE OPTIONS
264
265			=over 4
266
267	root	1.2	=item --verbose \| -v
268
269			Increases the verbosity level by one (the default is C<1>).
270
271			=item --quiet \| -q
272
273			Decreases the verbosity level by one.
274
275			=item --strip none\|pod\|ppi
276
277			Specify the stripping method applied to reduce the file of the perl
278			sources included.
279
280			The default is C<pod>, which uses the L<Pod::Strip> module to remove all
281			pod documenatiton, which is very fast and reduces filesize a lot.
282
283			The C<ppi> method uses L<PPI> to parse and condense the perl sources. This
284			saves a lot more than just L<Pod::Strip>, and is generally safer, but is
285			also a lot slower, so is best used for production builds.
286
287			Last not least, in the unlikely case where C<pod> is too slow, or some
288			module gets mistreated, you can specify C<none> to not mangle included
289			perl sources in any way.
290
291			=item --perl
292
293			After writing out the bundle files, try to link a new perl interpreter. It
294			will be called F<perl> and will be left in the current working
295			directory. The bundle files will be removed.
296
297			This switch is automatically ued when F<staticperl> is invoked with the
298			C<mkperl> command (instead of C<mkbundle>):
299
300			# build a new ./perl with only common::sense in it - very small :)
301			staticperl mkperl -Mcommon::sense
302
303			=item --use module \| -Mmodule
304
305			Include the named module and all direct dependencies. This is done by
306			C<require>'ing the module in a subprocess and tracing which other modules
307			and files it actually loads. If the module uses L<AutoLoader>, then all
308			splitfiles will be included as well.
309
310			Example: include AnyEvent and AnyEvent::Impl::Perl.
311
312			staticperl mkbundle --use AnyEvent --use AnyEvent::Impl::Perl
313
314			Sometimes you want to load old-style "perl libraries" (F<.pl> files), or
315			maybe other weirdly named files. To do that, you need to quote the name in
316			single or double quoutes. When given on the commandline, you probably need
317			to quote once more to avoid your shell interpreting it. Common cases that
318			need this are F<Config_heavy.pl> and F<utf8_heavy.pl>.
319
320			Example: include the required files for F<perl -V> to work in all its
321			glory (F<Config.pm> is included automatically by this).
322
323			# bourne shell
324			staticperl mkbundle --use '"Config_heavy.pl"'
325
326			# bundle specification file
327			use "Config_heavy.pl"
328
329			The C<-Mmodule> syntax is included as an alias that might be easier to
330			remember than C<use>. Or maybe it confuses people. Time will tell. Or
331			maybe not. Argh.
332
333			=item --eval "perl code" \| -e "perl code"
334
335			Sometimes it is easier (or necessary) to specify dependencies using perl
336			code, or maybe one of the modules you use need a special use statement. In
337			that case, you can use C<eval> to execute some perl snippet or set some
338			variables or whatever you need. All files C<require>'d or C<use>'d in the
339			script are included in the final bundle.
340
341			Keep in mind that F<mkbundle> will only C<require> the modules named
342			by the C<--use> option, so do not expect the symbols from modules you
343			C<--use>'d earlier on the commandlien to be available.
344
345			Example: force L<AnyEvent> to detect a backend and therefore include it
346			in the final bundle.
347
348			staticperl mkbundle --eval 'use AnyEvent; AnyEvent::detect'
349
350			# or like this
351			staticperl mkbundle -MAnyEvent --eval 'use AnyEvent; AnyEvent::detect'
352
353			Example: use a separate "bootstrap" script that C<use>'s lots of modules
354			and include this in the final bundle, to be executed automatically.
355
356			staticperl mkbundle --eval 'do "bootstrap"' --boot bootstrap
357
358			=item --boot filename
359
360			Include the given file in the bundle and arrange for it to be executed
361			(using a C<require>) before anything else when the new perl is
362			initialised. This can be used to modify C<@INC> or anything else before
363			the perl interpreter executes scripts given on the commandline (or via
364			C<-e>). This works even in an embedded interpreter.
365
366			=item --add "file" \| --add "file alias"
367
368			Adds the given (perl) file into the bundle (and optionally call it
369			"alias"). This is useful to include any custom files into the bundle.
370
371			Example: embed the file F<httpd> as F<httpd.pm> when creating the bundle.
372
373			staticperl mkperl --add "httpd httpd.pm"
374
375			It is also a great way to add any custom modules:
376
377			# specification file
378			add file1 myfiles/file1
379			add file2 myfiles/file2
380			add file3 myfiles/file3
381
382			=item --static
383
384			When C<--perl> is also given, link statically instead of dynamically. The
385			default is to link the new perl interpreter fully dynamic (that means all
386			perl modules are linked statically, but all external libraries are still
387			referenced dynamically).
388
389			Keep in mind that Solaris doesn't support static linking at all, and
390			systems based on GNU libc don't really support it in a usable fashion
391			either. Try uClibc if you want to create fully statically linked
392			executables, or try the C<--staticlibs> option to link only some libraries
393			statically.
394
395			=item any other argument
396
397			Any other argument is interpreted as a bundle specification file, which
398			supports most long options (without extra quoting), one option per line.
399	root	1.1
400			=back
401
402			=head2 F<STATCPERL> CONFIGURATION AND HOOKS
403
404	root	1.2	During (each) startup, F<staticperl> tries to source the following shell
405			files in order:
406
407			/etc/staticperlrc
408			~/.staticperlrc
409			$STATICPERL/rc
410
411			They can be used to override shell variables, or define functions to be
412			called at specific phases.
413
414			Note that the last file is erased during F<staticperl distclean>, so
415			generally should not be used.
416
417			=head3 CONFIGURATION VARIABLES
418
419			=head4 Variables you I<should> override
420
421			=over 4
422
423			=item C<EMAIL>
424
425			The e-mail address of the person who built this binary. Has no good
426			default, so should be specified by you.
427
428			=back
429
430			=head4 Variables you I<might want> to override
431
432			=over 4
433
434			=item C<PERLVER>
435
436			The perl version to install - default is currently C<5.12.2>, but C<5.8.9>
437			is also a good choice (5.8.9 is much smaller than 5.12.2, while 5.10.1 is
438			about as big as 5.12.2).
439
440			=item C<CPAN>
441
442			The URL of the CPAN mirror to use (e.g. L<http://mirror.netcologne.de/cpan/>).
443
444			=item C<PERL_CPPFLAGS>, C<PERL_OPTIMIZE>, C<PERL_LDFLAGS>, C<PERL_LIBS>
445
446			These flags are passed to perl's F<Configure> script, and are generally
447			optimised for small size (at the cost of performance). Since they also
448			contain subtle workarounds around various build issues, changing these
449			usually requires understanding their default values - best look at the top
450			of the F<staticperl> script for more info on these.
451
452			=item C<STATICPERL>
453
454			The directory where staticperl stores all its files
455			(default: F<~/.staticperl>).
456
457			=item C<PREFIX>
458
459			The prefix where perl get's installed (default: F<$STATICPERL/perl>),
460			i.e. where the F<bin> and F<lib> subdirectories will end up.
461
462			=item C<PERL_MM_USE_DEFAULT>, C<EV_EXTRA_DEFS>, others
463
464			Usually set to C<1> to make modules "less inquisitive" during their
465			installation, you can set any environment variable you want - some modules
466			(such as L<Coro> or L<EV>) use environment variables for further tweaking.
467
468			=item C<EXTRA_MODULES>
469
470			Additional modules installed during F<staticperl install>. Here you can
471			set which modules you want have to installed from CPAN.
472
473			Example: I really really need EV, AnyEvent, Coro and IO::AIO.
474
475			EXTRA_MODULES="EV AnyEvent Coro IO::AIO"
476
477			Note that you cna also use a C<postinstall> hook to achieve this, and
478			more.
479
480			=back
481
482			=head4 Variables you I<probably do not want> to override
483
484			=over 4
485
486			=item C<MKBUNDLE>
487
488			Where F<staticperl> writes the C<mkbundle> command to
489			(default: F<$STATICPERL/mkbundle>).
490
491			=item C<STATICPERL_MODULES>
492
493			Additional modules needed by C<mkbundle> - should therefore not be changed
494			unless you know what you are doing.
495
496			=back
497
498			=head3 OVERRIDABLE HOOKS
499
500			In addition to environment variables, it is possible to provide some
501			shell functions that are called at specific times. To provide your own
502			commands, justd efine the corresponding function.
503
504			Example: install extra modules from CPAN and from some directories
505			at F<staticperl install> time.
506
507			postinstall() {
508			rm -rf lib/threads.* # weg mit Schaden
509			instcpan IO::AIO EV
510			instsrc ~/src/AnyEvent
511			instsrc ~/src/XML-Sablotron-1.0100001
512			instcpan AnyEvent::HTTPD
513			}
514
515			=over 4
516
517			=item postconfigure
518
519			Called after configuring, but before building perl. Current working
520			directory is the perl source directory.
521
522			Could be used to tailor/patch config.sh (followed by F<./Configure -S>) or
523			do any other modifications.
524
525			=item postbuild
526
527			Called after building, but before installing perl. Current working
528			directory is the perl source directory.
529
530			I have no clue what this could be used for - tell me.
531
532			=item postinstall
533
534			Called after perl and any extra modules have been installed in C<$PREFIX>,
535			but before setting the "installation O.K." flag.
536
537			The current working directory is C<$PREFIX>, but maybe you should not rely
538			on that.
539
540			This hook is most useful to customise the installation, by deleting files,
541			or installing extra modules using the C<instcpan> or C<instsrc> functions.
542
543			The script must return with a zero exit status, or the installation will
544			fail.
545
546			=back
547	root	1.1
548			=head1 AUTHOR
549
550			Marc Lehmann <schmorp@schmorp.de>
551			http://software.schmorp.de/pkg/staticperl.html