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
cna 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

=head3 MKBUNDLE OPTIONS

=over 4

   "strip=s"   => \$STRIP,
   "verbose|v" => sub { ++$VERBOSE },
   "quiet|q"   => sub { --$VERBOSE },
   "perl"      => \$PERL,
   "eval=s"    => sub { trace_eval   $_[1] },
   "use|M=s"   => sub { trace_module $_[1] },
   "boot=s"    => sub { cmd_boot     $_[1] },
   "add=s"     => sub { cmd_add      $_[1] },
   "static"    => sub { $STATIC = 1 },
   "<>"        => sub { cmd_file     $_[1] },

=back

=head2 F<STATCPERL> CONFIGURATION AND HOOKS

#TODO

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://software.schmorp.de/pkg/staticperl.html


Revision:	1.1
Committed:	Mon Dec 6 19:33:57 2010 UTC (13 years, 6 months ago) by root
Branch:	MAIN
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			cna run the script manually as well (by default it is written to
212			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			=head3 MKBUNDLE OPTIONS
260
261			=over 4
262
263			"strip=s" => \$STRIP,
264			"verbose\|v" => sub { ++$VERBOSE },
265			"quiet\|q" => sub { --$VERBOSE },
266			"perl" => \$PERL,
267			"eval=s" => sub { trace_eval $_[1] },
268			"use\|M=s" => sub { trace_module $_[1] },
269			"boot=s" => sub { cmd_boot $_[1] },
270			"add=s" => sub { cmd_add $_[1] },
271			"static" => sub { $STATIC = 1 },
272			"<>" => sub { cmd_file $_[1] },
273
274			=back
275
276			=head2 F<STATCPERL> CONFIGURATION AND HOOKS
277
278			#TODO
279
280			=head1 AUTHOR
281
282			Marc Lehmann <schmorp@schmorp.de>
283			http://software.schmorp.de/pkg/staticperl.html
284
285
286