| 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 |
can 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 |
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 |
=head3 MKBUNDLE OPTIONS |
| 264 |
|
| 265 |
=over 4 |
| 266 |
|
| 267 |
=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 |
|
| 400 |
=back |
| 401 |
|
| 402 |
=head2 F<STATCPERL> CONFIGURATION AND HOOKS |
| 403 |
|
| 404 |
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 |
|
| 548 |
=head1 AUTHOR |
| 549 |
|
| 550 |
Marc Lehmann <schmorp@schmorp.de> |
| 551 |
http://software.schmorp.de/pkg/staticperl.html |
