--- App-Staticperl/staticperl.pod	2010/12/23 14:16:25	1.31
+++ App-Staticperl/staticperl.pod	2011/02/10 22:44:29	1.35
@@ -384,8 +384,8 @@
 =item C<--use> F<module> | C<-M>F<module>
 
 Include the named module and trace direct dependencies. This is done by
-C<require>'ing the module in a subprocess and tracing which other modules
-and files it actually loads.
+C<use>'ing the module from a fresh package in a subprocess and tracing
+which other modules and files it actually loads.
 
 Example: include AnyEvent and AnyEvent::Impl::Perl.
 
@@ -422,9 +422,9 @@
 variables or whatever you need. All files C<require>'d or C<use>'d while
 executing the snippet 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 command line to be available.
+Keep in mind that F<mkbundle> will not import any symbols from the modules
+named by the C<--use> option, so do not expect the symbols from modules
+you C<--use>'d earlier on the command line to be available.
 
 Example: force L<AnyEvent> to detect a backend and therefore include it
 in the final bundle.
@@ -469,9 +469,9 @@
 =item C<--add> F<file> | C<--add> "F<file> alias"
 
 Adds the given (perl) file into the bundle (and optionally call it
-"alias"). The F<file> is either an absolute path or a path relative to
-the current directory. If an alias is specified, then this is the name it
-will use for C<@INC> searches, otherwise the F<file> will be used as the
+"alias"). The F<file> is either an absolute path or a path relative to the
+current directory. If an alias is specified, then this is the name it will
+use for C<@INC> searches, otherwise the path F<file> will be used as the
 internal name.
 
 This switch is used to include extra files into the bundle.
@@ -481,6 +481,14 @@
 
    staticperl mkperl --add "httpd httpd.pm"
 
+   # can be accessed via "use httpd"
+
+Example: add a file F<initcode> from the current directory.
+
+   staticperl mkperl --add 'initcode &initcode'
+
+   # can be accessed via "do '&initcode'"
+
 Example: add local files as extra modules in the bundle.
 
    # specification file
@@ -499,9 +507,9 @@
 without any postprocessing (perl files might get stripped to reduce their
 size).
 
-You should probably add a C</> prefix to avoid clashing with embedded perl
-files (whose paths do not start with C</>), and/or use a special directory
-prefix, such as C</res/name>.
+If you specify an alias you should probably add a C<&> prefix to avoid
+clashing with embedded perl files (whose paths never start with C<&>),
+and/or use a special directory prefix, such as C<&res/name>.
 
 You can later get a copy of these files by calling C<staticperl::find
 "alias">.
@@ -666,7 +674,7 @@
 instead it will simply initialise the perl interpreter, clean it up and
 exit.
 
-This means that, by default, it will do nothing but burna few CPU cycles
+This means that, by default, it will do nothing but burn a few CPU cycles
 - for it to do something useful you I<must> add some boot code, e.g. with
 the C<--boot> option.
 
@@ -955,7 +963,7 @@
 
 =over 4
 
-=item staticperl_init ()
+=item staticperl_init (xs_init = 0)
 
 Initialises the perl interpreter. You can use the normal perl functions
 after calling this function, for example, to define extra functions or
@@ -972,25 +980,43 @@
    static void
    run_myapp(void)
    {
-      staticperl_init ();
+      staticperl_init (0);
       newXSproto ("myapp::xsfunction", xsfunction, __FILE__, "$$;$");
       eval_pv ("require myapp::main", 1); // executes "myapp/main.pm"
    }
 
-=item staticperl_xs_init (pTHX)
+When your bootcode already wants to access some XS functions at
+compiletime, then you need to supply an C<xs_init> function pointer that
+is called as soon as perl is initialised enough to define XS functions,
+but before the preamble code is executed:
 
-Sometimes you need direct control over C<perl_parse> and C<perl_run>, in
-which case you do not want to use C<staticperl_init> but call them on your
-own.
+   static void
+   xs_init (pTHX)
+   {
+     newXSproto ("myapp::xsfunction", xsfunction, __FILE__, "$$;$");
+   }
 
-Then you need this function - either pass it directly as the C<xs_init>
-function to C<perl_parse>, or call it from your own C<xs_init> function.
+   static void
+   run_myapp(void)
+   {
+      staticperl_init (xs_init);
+   }
 
 =item staticperl_cleanup ()
 
 In the unlikely case that you want to destroy the perl interpreter, here
 is the corresponding function.
 
+=item staticperl_xs_init (pTHX)
+
+Sometimes you need direct control over C<perl_parse> and C<perl_run>, in
+which case you do not want to use C<staticperl_init> but call them on your
+own.
+
+Then you need this function - either pass it directly as the C<xs_init>
+function to C<perl_parse>, or call it as one of the first things from your
+own C<xs_init> function.
+
 =item PerlInterpreter *staticperl
 
 The perl interpreter pointer used by staticperl. Not normally so useful,