On Tue, 16 Mar 2004, Larry Wall wrote:
> On Tue, Mar 16, 2004 at 06:00:51PM -0800, Brent Dax Royal-Gordon wrote:
> : Dan Sugalski wrote:
> : >Instead,
> : >what I'd like is for someone (Oh, Brent... :) to go through perl's
> : >configure
> :
> : Gulp.
>
> I'm sure Andy can give you *reams* of advice on Perl 5's configurator,
> especially on how it all ought to have been done differently in the
> first place. :-)
Sure, but "Run away -- now!" is probably not the sort of advice you had in
mind :-).
The perl5-build at perl.org mailing list is a good place to ask specific
Configure-related questions -- all of the perl5/Configure maintainers
participate, and it's archived too. There's also the much-neglected
perl6-build mailing list.
I won't have time for a couple of weeks to write anything up in detail
(though you should feel free to nudge me again in a couple of weeks when I
forget to do so), but a few quick thoughts off of the top of my head:
There are some good features of metaconfig/Configure that I think perl6
and parrot would do well to emulate:
1. It tests for features, not for platforms. End users will try to build
parrot and perl6 on platforms the developers don't have access to.
Often, those platforms will be very similar to other known ones, and, if
the configuration system tests for features, they might be able to get
pretty far. Platforms also change names. Of course some things (such as
the name of the compiler to use on AIX to successfully compile threaded
programs) really are platform-specific, so don't be too rigid.
2. It separates out individual tests (or groups of closely-related tests)
into easily-maintained units. These units contain all the relevant
information needed for that test: Documentation of the relevant
variables, the prerequisites for the test, and the actual test itself.
The task of assembling these units together and making the appropriate
files in the distribution is automated by a tool (known as metaconfig).
3. It is generally well-documented and well-commented. By design, every
variable set by Configure must have a "Glossary" entry. By convention,
many of those entries are actually correct and useful. Most of the units
that are doing something odd or complex also have fairly extensive
comments about what's going on and why. (Many of those comments don't
make it to the final Configure product, but are in the original metaconfig
units.) I can look back at something I did nearly 10 years ago and have a
chance of understanding why it was necessary.
4. It is flexible. It's possible to override nearly everything in
Configure, by command-line options, by hints files, by Policy files, by
override files (config.over) or by interactively answering questions.
5. It has lots of clever optimizations. (For example, the nm-scan and
header-file checks are particularly efficient, but can be overridden or
backed up by other tests.)
6. It's written in maximally portable and efficient v7 Bourne Shell, and
studiously avoids all "modern" constructs, such as functions, that might
make it easier to understand. Instead, it relies on multiple layers of
shell quoting and string evaluations, and deliberately uses control-flow
structures designed for maximum efficiency on 1980s-era systems.
Of course it does carry considerable baggage that could well be
jettisoned. A few off the top of my head:
1. It is Unix-centric.
2. It's description of the build process does not distinguish clearly
among three separate functions:
Compiler (used to turn C source code into object files.)
Linker (used to link object files + libraries together to make
an executable)
Shared-library Builder: (used to combine object files into a
shared library).
3. It doesn't handle circular dependencies well. For example, consider
various levels of 64-bit support. In order to determine whether or not
the system supports 64-bit operations of various sorts, it would be
useful to compile and run various test programs. However, in order to
compile and run test programs in 64-bit mode, you might need to change the
compiler, compiler options, and/or libraries. Once you do that, you might
need to go back and re-calculate various other things (such as the size or
type of variable used for off_t). Perl5's Configure does this via a
complicated set of "call-back" units.
4. It spits out a monolithic script, rather than a series of function
calls.
5. You probably don't need to support Eunice anymore.
There are also some things that autoconf structurally does better. I
haven't looked at it in ages, but two that spring to mind immediately are:
1. Autoconf does a better job building up and using an intermediate
'config.h' file and partial library list. It knows how to go look for and
add an additional library, if needed. (Though again, adding in a new
library could potentially invalidate everything that came before, so be
wary.)
2. Autoconf offers more extensive error-logging possibilities.
Anyway, overall, I think metaconfig offers a good structural starting
point for a configuration system. I don't mean the final result has to
look like Perl5's Configure -- Parrot's Configure.pl could actually remain
almost unchanged. What would be affected more would be the generation and
piecing together of the individual steps that get run by Configure.pl.
Also, with such an infrastructure, it might be easier to promote the "test
for features, not for platforms" philosophy that has helped keep perl5 as
portable as it is.
The best advice to anyone, though, is the same advice Larry gave me a long
time ago (10 years, as of next Thursday):
Have the appropriate amount of fun.
--
Andy Dougherty [EMAIL PROTECTED]
