X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlxstut.pod;h=501a34845eba73c6d08778c899bc0d3ba0cbbba3;hb=982b4e8fc47473059e209787b589853f4c8f8f9e;hp=592f2ee189aef4cc708d31593f85a8f023facf26;hpb=d9d2a7fbcc96dde1317c64fe5cf8ab5f28c2fd28;p=p5sagit%2Fp5-mst-13.2.git diff --git a/pod/perlxstut.pod b/pod/perlxstut.pod index 592f2ee..501a348 100644 --- a/pod/perlxstut.pod +++ b/pod/perlxstut.pod @@ -1,6 +1,6 @@ =head1 NAME -perlXStut - Tutorial for XSUB's +perlXStut - Tutorial for XSUBs =head1 DESCRIPTION @@ -10,8 +10,8 @@ L. This tutorial starts with very simple examples and becomes more complex, with each new example adding new features. Certain concepts may not be -completely explained until later in the tutorial in order to slowly ease -the reader into building extensions. +completely explained until later in the tutorial to ease the +reader slowly into building extensions. =head2 VERSION CAVEAT @@ -33,7 +33,7 @@ read: =item * -In versions of 5.002 prior to version beta 3, then the line in the .xs file +In versions of 5.002 prior to version beta 3, the line in the .xs file about "PROTOTYPES: DISABLE" will cause a compiler error. Simply remove that line from the file. @@ -63,7 +63,7 @@ Some systems may have installed Perl version 5 as "perl5". =head2 DYNAMIC VERSUS STATIC It is commonly thought that if a system does not have the capability to -dynamically load a library, you cannot build XSUB's. This is incorrect. +load a library dynamically, you cannot build XSUBs. This is incorrect. You I build them, but you must link the XSUB's subroutines with the rest of Perl, creating a new executable. This situation is similar to Perl 4. @@ -88,7 +88,7 @@ test" is sufficient. Our first extension will be very simple. When we call the routine in the extension, it will print out a well-known message and return. -Run "h2xs -A -n Mytest". This creates a directory named Mytest, possibly under +Run C. This creates a directory named Mytest, possibly under ext/ if that directory exists in the current working directory. Several files will be created in the Mytest dir, including MANIFEST, Makefile.PL, Mytest.pm, Mytest.xs, test.pl, and Changes. @@ -201,7 +201,7 @@ Now we run the script and we should see the following output: =head2 EXAMPLE 2 Now let's add to our extension a subroutine that will take a single argument -and return 0 if the argument is even, 1 if the argument is odd. +and return 1 if the argument is even, 0 if the argument is odd. Add the following to the end of Mytest.xs: @@ -227,7 +227,7 @@ Now re-run make to rebuild our new shared library. Now perform the same steps as before, generating a Makefile from the Makefile.PL file, and running make. -In order to test that our extension works, we now need to look at the +To test that our extension works, we now need to look at the file test.pl. This file is set up to imitate the same kind of testing structure that Perl itself has. Within the test script, you perform a number of tests to confirm the behavior of the extension, printing "ok" @@ -261,7 +261,8 @@ h2xs creates a number of files in the extension directory. The file Makefile.PL is a perl script which will generate a true Makefile to build the extension. We'll take a closer look at it later. -The files .pm and .xs contain the meat of the extension. +The files EextensionE.pm and EextensionE.xs contain the meat +of the extension. The .xs file holds the C routines that make up the extension. The .pm file contains routines that tell Perl how to load your extension. @@ -271,7 +272,7 @@ contain the shared library that we will build. Once we have tested it, we can install it into its final location. Invoking the test script via "make test" did something very important. It -invoked perl with all those -I arguments so that it could find the various +invoked perl with all those C<-I> arguments so that it could find the various files that are part of the extension. It is I important that while you are still testing extensions that @@ -445,7 +446,7 @@ section on the argument stack. =head2 WARNING In general, it's not a good idea to write extensions that modify their input -parameters, as in Example 3. However, in order to better accomodate calling +parameters, as in Example 3. However, to accommodate better calling pre-existing C routines, which often do modify their input parameters, this behavior is tolerated. The next example will show how to do this. @@ -576,17 +577,19 @@ and add the following lines to the end of the script: print &Mytest2::foo(1, 2, "0.0") == 7 ? "ok 3\n" : "not ok 3\n"; print abs(&Mytest2::foo(0, 0, "-3.4") - 0.6) <= 0.01 ? "ok 4\n" : "not ok 4\n"; -(When dealing with floating-point comparisons, it is often useful to not check +(When dealing with floating-point comparisons, it is often useful not to check for equality, but rather the difference being below a certain epsilon factor, 0.01 in this case) Run "make test" and all should be well. -=head 2 WHAT HAS HAPPENED HERE? +=head2 WHAT HAS HAPPENED HERE? Unlike previous examples, we've now run h2xs on a real include file. This has caused some extra goodies to appear in both the .pm and .xs files. +=over 4 + =item * In the .xs file, there's now a #include declaration with the full path to @@ -604,7 +607,7 @@ C routine. The .pm file has exported the name TESTVAL in the @EXPORT array. This could lead to name clashes. A good rule of thumb is that if the #define -is only going to be used by the C routines themselves, and not by the user, +is going to be used by only the C routines themselves, and not by the user, they should be removed from the @EXPORT array. Alternately, if you don't mind using the "fully qualified name" of a variable, you could remove most or all of the items in the @EXPORT array. @@ -617,12 +620,12 @@ processed at all by h2xs. There is no good solution to this right now. =back We've also told Perl about the library that we built in the mylib -subdirectory. That required only the addition of the MYEXTLIB variable +subdirectory. That required the addition of only the MYEXTLIB variable to the WriteMakefile call and the replacement of the postamble subroutine to cd into the subdirectory and run make. The Makefile.PL for the library is a bit more complicated, but not excessively so. Again we replaced the postamble subroutine to insert our own code. This code -simply specified that the library to be created here was a static +specified simply that the library to be created here was a static archive (as opposed to a dynamically loadable library) and provided the commands to build it. @@ -682,7 +685,7 @@ usually 0. The "ST" is actually a macro that points to the n'th argument on the argument stack. ST(0) is thus the first argument passed to the XSUB, ST(1) is the second argument, and so on. -When you list the arguments to the XSUB in the .xs file, that tell xsubpp +When you list the arguments to the XSUB in the .xs file, that tells xsubpp which argument corresponds to which of the argument stack (i.e., the first one listed is the first argument, and so on). You invite disaster if you do not list them in the same order as the function expects them. @@ -693,7 +696,7 @@ Sometimes you might want to provide some extra methods or subroutines to assist in making the interface between Perl and your extension simpler or easier to understand. These routines should live in the .pm file. Whether they are automatically loaded when the extension itself is loaded -or only loaded when called depends on where in the .pm file the subroutine +or loaded only when called depends on where in the .pm file the subroutine definition is placed. =head2 DOCUMENTING YOUR EXTENSION @@ -724,7 +727,7 @@ and L. =head2 Author -Jeff Okamoto +Jeff Okamoto EFE Reviewed and assisted by Dean Roehrich, Ilya Zakharevich, Andreas Koenig, and Tim Bunce.