Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of somian (5953)

Monday November 13, 2006
11:17 AM

Housecleaning CygwinPerl's build-time config

[ #31592 ]

I've been working for about 10 days now on renovating the
build configuration for the production of perl5 (5.8) on the
Cygwin platform. In order to not lose what I've learned in
doing this, I'm going to make some notes here.

One of the first things that comes to mind is that the entire
process has been like peeling away layers of an onion -- and
finding that the bad spots just go deeper and deeper. The more
peeled away, the worse the onion looks. The fact is that
cygperl's build works (where "works" could be defined as
"produces a final perl for installation that is more or less
viable") only (partly) by accident.

The absurd amount of time and CPU is takes to build and
install an average module for cygwinperl was part of the
reason for undertaking this housekeeping project. I don't have
figures to cite (atm), but what takes a few seconds on
a typical gnu/linux machine takes many minutes with cygperl,
and if the module is an extention (involves C compilation), it
is far worse.

Many files are involved in Perl's strange build configuration
mechanism. A few that impact this specific build are listed
here:

      Makefile.SH
      Policy.SH
      hints/cygwin.sh
      ExtUtils/MakeMaker/MM_Cygwin.pm
      cygwin/Makefile.SHs
      cygwin/perlld.in
      cygwin/ld2.in

As I've been drawn further and further into trying to get
everything "right" in the final product of the build process,
I have realized that apparently, successive contributors to
cygperl have never read or never read and thought much about
the principles and explanations contained in Porting/Glossary
or hints/README.hints. These files contain essential
information about how things actually work, that people doing
this kind of project really need to know. One of the amazing
facts spotted by reading hints/README.hints, for example, is:

  * the hints/[architecturename].sh file is not actually
        evaluated as a shell script! It may be called a shell
        script, have a shebang line at the top, and may have
        an .sh extention, but these files are actually read
        by Configure using simple line-by-line sed processing!

The result is (as explained in hints/README.hints) that such
things as an sh 'case' statement to set a variable value based
on some condition will not do what the hintsfile writer thinks
it will do. Yet cygperl's hintsfile had several such case
statements.

    [To Be Continued]