crummy build process for FastCGI-integrated Perl
Mark Brown (mbrown@openmarket.com)
Tue, 18 Jun 1996 10:19:33 -0400
Message-Id: <199606181419.KAA22972@breckenridge.openmarket.com>
To: fastcgi-developers@openmarket.com
Subject: crummy build process for FastCGI-integrated Perl
Date: Tue, 18 Jun 1996 10:19:33 -0400
From: Mark Brown <mbrown@openmarket.com>
Nigel Metheringham observes:
Also I am *very* unhappy about the perl build process - making a new
perl for fastcgi is a real bitch! Particularly as your build process
did not work on our Sun (SunOS 4.1.3 patches) system so I had to do a
lot of hacking around, then to find that the extra cflags broke the
Configure test programs, so other things didn't work (ie no signal
names!). I eventually configured as normal (no fastcgi changes),
then edited config.sh (at the prompt) and added the cflags, ldflags &
libs entries, and changed the stdio settigs (std stdio and base etc
entries - all together in config.sh) to undef. This worked and
tested OK.
I can assure you that we suffered comparable pain getting it to
build on four platforms.
Would it not be possible to:-
1. Just have an FCGI module, leaving the main perl stdio alone.
2. Have a modified CGI module which uses the FCGI input routines.
3. State that all output must go via a different file descriptor
which is handled by FCGI. You could then attach STDOUT to that
descriptor at the top of the program if you wished.
Building a new perl with non-standard build process is a pain, and I
have to admit I have installed it under a different name since I
don't really trust it :-)
Your suggestions are entirely reasonable.
I have spent some time puzzling over the Perl documentation,
trying to figure out how to provide my own implementation
of the filehandle type, but haven't made much progress. I'm
quite willing to collaborate with a perlguts expert on doing
the FastCGI-Perl integration right, but I don't think I have
time to become a perlguts expert on my own.
--mark