ext\ExtUtils\t\Embed.t fails test when upgrading a perl with different core headers.
[p5sagit/p5-mst-13.2.git] / Porting / pumpkin.pod
index aa52845..fb5c2d7 100644 (file)
@@ -455,7 +455,7 @@ This is to ease maintenance.  When Configure gets updated, the parts
 sometimes get scrambled around, and the changes in config_H can
 sometimes be very hard to follow.  config.sh, on the other hand, can
 safely be sorted, so it's easy to track (typically very small) changes
-to config.sh and then propoagate them to a canned 'config.h' by any
+to config.sh and then propagate them to a canned 'config.h' by any
 number of means, including a perl script in win32/ or carrying 
 config.sh and config_h.SH to a Unix system and running sh
 config_h.SH.)  Vms uses configure.com to generate its own config.sh
@@ -479,9 +479,9 @@ directories.
 
 =head2 make regen_perly
 
-If perly.y has been edited, it is nessary to run this target to rebuild
-perly.h, perl.act and perl.tab. In fact this target just runs the Perl
-script regen_perly.pl. Note that perl.c is I<not> rebuilt; this is just a
+If perly.y has been edited, it is necessary to run this target to rebuild
+perly.h, perly.act and perly.tab. In fact this target just runs the Perl
+script regen_perly.pl. Note that perly.c is I<not> rebuilt; this is just a
 plain static file now. 
 
 This target relies on you having Bison installed on your system. Running
@@ -489,7 +489,7 @@ the target will tell you if you haven't got the right version, and if so,
 where to get the right one. Or if you prefer, you could hack
 regen_perly.pl to work with your version of Bison. The important things
 are that the regexes can still extract out the right chunks of the Bison
-output into perly.act and perl.tab, and that the contents of those two
+output into perly.act and perly.tab, and that the contents of those two
 files, plus perly.h, are functionally equivalent to those produced by the
 supported version of Bison.
 
@@ -587,7 +587,7 @@ time around, may be tackled in the future.  Update the file to reflect
 the situation as it stands when you hand over the pumpkin.
 
 You might like, early in your pumpkin-holding career, to see if you
-can find champions for partiticular issues on the to-do list: an issue
+can find champions for particular issues on the to-do list: an issue
 owned is an issue more likely to be resolved.
 
 There are also some more porting-specific L</Todo> items later in this
@@ -713,48 +713,6 @@ branches.
 
 =over 4
 
-=item CHECK_FORMAT
-
-If you have gcc, you can test the correct use of printf-style
-arguments.  Run C<Configure> with S<-Dccflags='-DCHECK_FORMAT
--Wformat'> (and S<-Dcc=gcc>, if you are not on a system where C<cc>
-is C<gcc>) and run C<make>.  The compiler will produce warnings of
-incorrect use of format arguments.  CHECK_FORMAT changes perl-defined
-formats to common formats, so DO NOT USE the executable produced by
-this process.
-
-A more accurate approach is the following commands:
-
-=over 4
-
-=item *
-
-build miniperl with -DCHECK_FORMAT 
-
-    make clean
-    make miniperl OPTIMIZE=-DCHECK_FORMAT >& mini.log  
-
-=item *
-
-build a clean miniperl,
-and build everything else from that with -DCHECK_FORMAT
-
-    make clean
-    make miniperl      
-    make all OPTIMIZE='-DCHECK_FORMAT -Wformat' >& make.log  
-               
-=item *
-
-clean up, and print warnings from the log files
-
-    make clean
-    perl -nwe 'print if /^\S+:/ and not /^make\b/' \
-       mini.log make.log
-
-=back
-
-(-Wformat support by Robin Barker.)
-
 =item gcc -ansi -pedantic
 
 Configure -Dgccansipedantic [ -Dcc=gcc ] will enable (via the cflags script,
@@ -835,42 +793,10 @@ The only currently known leaks happen when there are compile-time errors
 within eval or require.  (Fixing these is non-trivial, unfortunately, but
 they must be fixed eventually.)
 
-=head1 Common Gotcha's
+=head1 Common Gotchas
 
 =over 4
 
-=item #elif
-
-The '#elif' preprocessor directive is not understood on all systems.
-Specifically, I know that Pyramids don't understand it.  Thus instead of the
-simple
-
-       #if defined(I_FOO)
-       #  include <foo.h>
-       #elif defined(I_BAR)
-       #  include <bar.h>
-       #else
-       #  include <fubar.h>
-       #endif
-
-You have to do the more Byzantine
-
-       #if defined(I_FOO)
-       #  include <foo.h>
-       #else
-       #  if defined(I_BAR)
-       #    include <bar.h>
-       #  else
-       #    include <fubar.h>
-       #  endif
-       #endif
-
-Incidentally, whitespace between the leading '#' and the preprocessor
-command is not guaranteed, but is very portable and you may use it freely.
-I think it makes things a bit more readable, especially once things get
-rather deeply nested.  I also think that things should almost never get
-too deeply nested,  so it ought to be a moot point :-)
-
 =item Probably Prefer POSIX
 
 It's often the case that you'll need to choose whether to do