Cheap web site hosting service by Active-Venture.com
  

 Back to Index


NAME

Pumpkin - Notes on handling the Perl Patch Pumpkin And Porting Perl

SYNOPSIS

There is no simple synopsis, yet.

DESCRIPTION

This document attempts to begin to describe some of the considerations involved in patching, porting, and maintaining perl.

This document is still under construction, and still subject to significant changes. Still, I hope parts of it will be useful, so I'm releasing it even though it's not done.

For the most part, it's a collection of anecdotal information that already assumes some familiarity with the Perl sources. I really need an introductory section that describes the organization of the sources and all the various auxiliary files that are part of the distribution.

Where Do I Get Perl Sources and Related Material?

The Comprehensive Perl Archive Network (or CPAN) is the place to go. There are many mirrors, but the easiest thing to use is probably http://www.cpan.org/README.html , which automatically points you to a mirror site "close" to you.

Perl5-porters mailing list

The mailing list perl5-porters@perl.org is the main group working with the development of perl. If you're interested in all the latest developments, you should definitely subscribe. The list is high volume, but generally has a fairly low noise level.

Subscribe by sending the message (in the body of your letter)

 
	subscribe perl5-porters  

to perl5-porters-request@perl.org .

Archives of the list are held at:

 
    http://www.rosat.mpe-garching.mpg.de/mailing-lists/perl-porters/  

Upload Your Work to CPAN

You can upload your work to CPAN if you have a CPAN id. Check out http://www.cpan.org/modules/04pause.html for information on _PAUSE_, the Perl Author's Upload Server.

I typically upload both the patch file, e.g. perl5.004_08.pat.gz and the full tar file, e.g. perl5.004_08.tar.gz.

If you want your patch to appear in the src/5.0/unsupported directory on CPAN, send e-mail to the CPAN master librarian. (Check out http://www.cpan.org/CPAN.html ).

Help Save the World

You should definitely announce your patch on the perl5-porters list. You should also consider announcing your patch on comp.lang.perl.announce, though you should make it quite clear that a subversion is not a production release, and be prepared to deal with people who will not read your disclaimer.

Todo

Here, in no particular order, are some Configure and build-related items that merit consideration. This list isn't exhaustive, it's just what I came up with off the top of my head.

Adding missing library functions to Perl

The perl Configure script automatically determines which headers and functions you have available on your system and arranges for them to be included in the compilation and linking process. Occasionally, when porting perl to an operating system for the first time, you may find that the operating system is missing a key function. While perl may still build without this function, no perl program will be able to reference the missing function. You may be able to write the missing function yourself, or you may be able to find the missing function in the distribution files for another software package. In this case, you need to instruct the perl configure-and-build process to use your function. Perform these steps.

  • Code and test the function you wish to add. Test it carefully; you will have a much easier time debugging your code independently than when it is a part of perl.
  • Here is an implementation of the POSIX truncate function for an operating system (VOS) that does not supply one, but which does supply the ftruncate() function.

     
      /* Beginning of modification history */
      /* Written 02-01-02 by Nick Ing-Simmons (nick@ing-simmons.net) */
      /* End of modification history */
      
      /* VOS doesn't supply a truncate function, so we build one up
         from the available POSIX functions.  */
      
      #include <fcntl.h>
      #include <sys/types.h>
      #include <unistd.h>
      
      int
      truncate(const char *path, off_t len)
      {
       int fd = open(path,O_WRONLY);
       int code = -1;
       if (fd >= 0) {
         code = ftruncate(fd,len);
         close(fd);
       }
       return code;
      }  

    Place this file into a subdirectory that has the same name as the operating system. This file is named perl/vos/vos.c

  • If your operating system has a hints file (in perl/hints/XXX.sh for an operating system named XXX), then start with it. If your operating system has no hints file, then create one. You can use a hints file for a similar operating system, if one exists, as a template.
  • Add lines like the following to your hints file. The first line (d_truncate="define") instructs Configure that the truncate() function exists. The second line (archobjs="vos.o") instructs the makefiles that the perl executable depends on the existence of a file named "vos.o". (Make will automatically look for "vos.c" and compile it with the same options as the perl source code). The final line ("test -h...") adds a symbolic link to the top-level directory so that make can find vos.c. Of course, you should use your own operating system name for the source file of extensions, not "vos.c".

     
      # VOS does not have truncate() but we supply one in vos.c
      d_truncate="define"
      archobjs="vos.o"
      
      # Help gmake find vos.c
      test -h vos.c || ln -s vos/vos.c vos.c  

    The hints file is a series of shell commands that are run in the top-level directory (the "perl" directory). Thus, these commands are simply executed by Configure at an appropriate place during its execution.

  • At this point, you can run the Configure script and rebuild perl. Carefully test the newly-built perl to ensure that normal paths, and error paths, behave as you expect.

Good ideas waiting for round tuits

Configure -Dsrc=/blah/blah
We should be able to emulate configure --srcdir. Tom Tromey tromey@creche.cygnus.com has submitted some patches to the dist-users mailing list along these lines. They have been folded back into the main distribution, but various parts of the perl Configure/build/install process still assume src='.'.
Hint file fixes
Various hint files work around Configure problems. We ought to fix Configure so that most of them aren't needed.
Hint file information
Some of the hint file information (particularly dynamic loading stuff) ought to be fed back into the main metaconfig distribution.

Probably good ideas waiting for round tuits

GNU configure --options
I've received sensible suggestions for --exec_prefix and other GNU configure --options. It's not always obvious exactly what is intended, but this merits investigation.
make clean
Currently, make clean isn't all that useful, though make realclean and make distclean are. This needs a bit of thought and documentation before it gets cleaned up.
Try gcc if cc fails
Currently, we just give up.
bypassing safe*alloc wrappers
On some systems, it may be safe to call the system malloc directly without going through the util.c safe* layers. (Such systems would accept free(0), for example.) This might be a time-saver for systems that already have a good malloc. (Recent Linux libc's apparently have a nice malloc that is well-tuned for the system.)

Vague possibilities

MacPerl
Get some of the Macintosh stuff folded back into the main distribution.
gconvert replacement
Maybe include a replacement function that doesn't lose data in rare cases of coercion between string and numerical values.
Improve makedepend

The current makedepend process is clunky and annoyingly slow, but it works for most folks. Alas, it assumes that there is a filename $firstmakefile that the make command will try to use before it uses Makefile. Such may not be the case for all make commands, particularly those on non-Unix systems.

Probably some variant of the BSD .depend file will be useful. We ought to check how other packages do this, if they do it at all. We could probably pre-generate the dependencies (with the exception of malloc.o, which could probably be determined at Makefile.SH extraction time.

GNU Makefile standard targets
GNU software generally has standardized Makefile targets. Unless we have good reason to do otherwise, I see no reason not to support them.
File locking
Somehow, straighten out, document, and implement lockf(), flock(), and/or fcntl() file locking. It's a mess. See $d_fcntl_can_lock in recent config.sh files though.

AUTHORS

Original author: Andy Dougherty doughera@lafcol.lafayette.edu . Additions by Chip Salzenberg chip@perl.com and Tim Bunce Tim.Bunce@ig.co.uk .

All opinions expressed herein are those of the author(s).

LAST MODIFIED

$Id: pumpkin.pod,v 1.23 2000/01/13 19:45:13 doughera Released $

 

  

 

Cheap domain name:
Domain name services from just
$8.95/year only
 


Buy domain name registration and cheap domain transfer at low, affordable price.

2002-2004 Active-Venture.com Web Site Hosting Service

 

[ First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII and we thought it was a typewriter. Then we discovered graphics, and we thought it was a television. With the World Wide Web, we've realized it's a brochure.   ]

 

 
 
 

Disclaimer: This documentation is provided only for the benefits of our web hosting customers.
For authoritative source of the documentation, please refer to http://www.perldoc.com