will regenerate Configure and config_h.SH. Much more information
on obtaining and running metaconfig is in the F<U/README> file
-that comes with Perl's metaconfig units. Perl's metaconfig units
-should be available on CPAN. A set of units that will work with
-perl5.005 is in the file F<mc_units-5.005_00-01.tar.gz> under
-http://www.cpan.org/authors/id/ANDYD/ . The mc_units tar file
-should be unpacked in your main perl source directory. Note: those
-units were for use with 5.005. There may have been changes since then.
-Check for later versions or contact perl5-porters@perl.org to obtain a
+that comes with Perl's metaconfig units.
+
+Since metaconfig is hard to change, running correction scripts after
+this generation is sometimes needed. Configure gained complexity over
+time, and the order in which config_h.SH is generated can cause havoc
+when compiling perl. Therefor, you need to run Porting/config_h.pl
+after that generation. All that and more is described in the README
+files that come with the metaunits.
+
+Perl's metaconfig units should be available on CPAN. A set of units
+that will work with perl5.9.x is in a file with a name similar to
+F<mc_units-20070423.tgz> under http://www.cpan.org/authors/id/H/HM/HMBRAND/ .
+The mc_units tar file should be unpacked in your main perl source directory.
+Note: those units were for use with 5.9.x. There may have been changes since
+then. Check for later versions or contact perl5-porters@perl.org to obtain a
pointer to the current version.
-Alternatively, do consider if the F<*ish.h> files might be a better
-place for your changes.
+Alternatively, do consider if the F<*ish.h> files or the hint files might be
+a better place for your changes.
=head2 MANIFEST
keywords.pl
myconfig
opcode.pl
- perly.fixer
t/TEST
t/*/*.t
*.SH
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
patch with a promise to quickly issue a follow-up that handles those
directories.
-=head2 make run_byacc
+=head2 make regen_perly
-If you have byacc-1.8.2 (available from CPAN as
-http://www.cpan.org/src/misc/perl-byacc1.8.2.tar.gz), and if there have
-been changes to F<perly.y>, you can regenerate the F<perly.c> file. The
-run_byacc makefile target does this by running byacc and then applying
-some patches so that byacc dynamically allocates space, rather than
-having fixed limits. This patch is handled by the F<perly.fixer>
-script. Depending on the nature of the changes to F<perly.y>, you may
-or may not have to hand-edit the patch to apply correctly. If you do,
-you should include the edited patch in the new distribution. If you
-have byacc-1.9, the patch won't apply cleanly. Changes to the printf
-output statements mean the patch won't apply cleanly. Long ago I
-started to fix F<perly.fixer> to detect this, but I never completed the
-task.
+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.
-If C<perly.c> or C<perly.h> changes, make sure you run C<perl vms/vms_yfix.pl>
-to update the corresponding VMS files. This could be taken care of by
-the regen_all target in the Unix Makefile. See also
-L<VMS-specific updates>.
+This target relies on you having Bison installed on your system. Running
+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 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.
-Some additional notes from Larry on this:
-
-Don't forget to regenerate perly_c.diff.
-
- byacc -d perly.y
- mv y.tab.c perly.c
- patch perly.c <perly_c.diff
- # manually apply any failed hunks
- diff -c perly.c.orig perly.c >perly_c.diff
-
-One chunk of lines that often fails begins with
-
- #line 29 "perly.y"
-
-and ends one line before
-
- #define YYERRCODE 256
-
-This only happens when you add or remove a token type. I suppose this
-could be automated, but it doesn't happen very often nowadays.
-
-Larry
+Note that in the old days, you had to do C<make run_byacc> instead.
=head2 make regen_all
-This target takes care of the PERLYVMS, regen_headers, and regen_pods
-targets.
+This target takes care of the regen_headers, and regen_pods targets.
=head2 make regen_headers
=head2 PPPort
-F<ext/Devel/PPPort/PPPort.pm> needs to be synchronized to include all
+F<ext/Devel-PPPort/PPPort.pm> needs to be synchronized to include all
new macros added to .h files (normally perl.h and XSUB.h, but others
as well). Since chances are that when a new macro is added the
committer will forget to update F<PPPort.pm>, it's the best to diff for
If you update the subversion number in F<patchlevel.h>, you may need
to change the version number near the top of the F<Changes> file.
+=head2 Bumping perl's version
+
+If you bump perl's version, you will need to update a few things:
+the L<perlhist> manpage for the date of release, the version number and
+perldelta reference in the top level F<README> (and maybe the copyright
+year too), the F<META.yml> file (generated via F<Porting/makemeta>, be
+sure to run it with the current bleadperl), and the meta-info about
+dual-lived modules in Module::Corelist (F<Porting/corelist.pl> does that).
+Make sure the numbered feature bundles in F<lib/feature.pm> are also
+correct.
+
=head2 Todo
The F<pod/perltodo.pod> file contains a roughly-categorized unordered
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
=head2 VMS-specific updates
-If you have changed F<perly.y> or F<perly.c>, then you most probably want
-to update F<vms/perly_{h,c}.vms> by running C<perl vms/vms_yfix.pl>, or
-by running `make regen_all` which will run that script for you.
-
The Perl revision number appears as "perl5" in configure.com.
It is courteous to update that if necessary.
=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,
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
=head1 LAST MODIFIED
+27-04-2007 H.Merijn Brand
$Id: pumpkin.pod,v 1.23 2000/01/13 19:45:13 doughera Released $