Configure.pl and the history of the world
Dan Sugalski
Now that we're integrating in with perl 5, a few things are becoming
really obvious.
First, we really need to work on the embedding interface. Memory
handling, signals, and I/O are the biggies there. Working on that,
though not fast enough for Arthur.
Second, we're running over the same problems in system configuration
that perl (and python, and ruby, for that matter) have already run
across. Moreover, we're making the same decisions, only...
differently. This is silly both because we're re-inventing the wheel
and we're making the wheel with metric nuts instead of english.
We could go dig through perl's configure every time we add a new
environment probe, but that'll get really old really quick. Instead,
what I'd like is for someone (Oh, Brent... :) to go through perl's
configure and dig out the tests in it, as well as the defaults that
it has and just get all the config variables in once and for all.
While some of what's in there we don't have to deal with (joys of C89
as a minimum requirement) there's a lot of hard-won platform
knowledge in there and ignoring it's foolish.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
: Second, we're running over the same problems in system configuration
: across. Moreover, we're making the same decisions, only...
: differently. This is silly both because we're re-inventing the wheel
: and we're making the wheel with metric nuts instead of english.
:
: We could go dig through perl's configure every time we add a new
: environment probe, but that'll get really old really quick. Instead,
: what I'd like is for someone (Oh, Brent... :) to go through perl's
: configure and dig out the tests in it, as well as the defaults that
: it has and just get all the config variables in once and for all.
: While some of what's in there we don't have to deal with (joys of C89
: as a minimum requirement) there's a lot of hard-won platform
: knowledge in there and ignoring it's foolish.
Er, yes, but...you might actually do better by looking at all the
metaconfig units that go into generating Configure. Then you'd at
least know what all the dependencies are. Oh, and metaconfig will
gladly do the work of weeding out the tests you're not interested in.
Not using metaconfig (or something like it) would be the biggest
mistake. It's actually next to impossible to maintain something like
a Configure script directly.
Larry
Brent "Dax" Royal-Gordon
> Instead,
> what I'd like is for someone (Oh, Brent... :) to go through perl's
> configure
Gulp.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Larry Wall
: 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. :-)
Larry
Rafael Garcia-Suarez
>
> Not using metaconfig (or something like it) would be the biggest
> mistake. It's actually next to impossible to maintain something like
> a Configure script directly.
Actually as parrot already uses IIUC variables set up by Configure,
I think one could drop the "or something like it". The biggest drawback
of Configure is that it's UNIX-centric. But it's yet impressively
portable and backwards-compatible (ask any Richard Clamp).
[Some time ago Raphael Manfredi, bored by the autocrap tools (as he
names it) expressed the intent to work on metaconfig again, but then he
disappeared again.]
H.Merijn Brand
> On Tue, Mar 16, 2004 at 07:47:25PM -0500, Dan Sugalski wrote:
> : Second, we're running over the same problems in system configuration
> : that perl (and python, and ruby, for that matter) have already run
> : across. Moreover, we're making the same decisions, only...
> : differently. This is silly both because we're re-inventing the wheel
> : and we're making the wheel with metric nuts instead of english.
> :
> : We could go dig through perl's configure every time we add a new
> : environment probe, but that'll get really old really quick. Instead,
> : what I'd like is for someone (Oh, Brent... :) to go through perl's
> : configure and dig out the tests in it, as well as the defaults that
> : it has and just get all the config variables in once and for all.
> : While some of what's in there we don't have to deal with (joys of C89
> : as a minimum requirement) there's a lot of hard-won platform
> : knowledge in there and ignoring it's foolish.
>
> Er, yes, but...you might actually do better by looking at all the
> metaconfig units that go into generating Configure. Then you'd at
> least know what all the dependencies are.
Better even, the metaconfig units are loaded with comments that do
not make it to the final Configure script.
> Oh, and metaconfig will gladly do the work of weeding out the tests
> you're not interested in.
But the metaconfig units still hold the code and comment, so you don't
have to #ifdef/comment-out those unwanted parts and clutter the code
> Not using metaconfig (or something like it) would be the biggest
> mistake. It's actually next to impossible to maintain something like
> a Configure script directly.
Who would maintain it? I've got no problem (yet) with maintaining it
for perl5, and I'm even working on backward compatibility for 5.005._xx,
so Configure and hints are usable for the complete actual range, and
thus save huge amounts of backporting time
The problem is that there are only a few knowledgable/interested in
doing this, ehh, less interesting part of the project (I still like it)
> Larry
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Andrew Dougherty
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 doug...@lafayette.edu
Josh Wilmes
that identify the platform ($^O, essentially) from metaconfig to something
we could put into Configure.pl.
Even that relatively simple chore wasn't too easy. I should still have
the work-in-progress code for that around here somewhere.
--Josh
Josh Wilmes
> 5. You probably don't need to support Eunice anymore.
I think i'm not the only one who would be deeply upset if I ceased to be
congratulated for not running Eunice though.
--Josh
Brent 'Dax' Royal-Gordon
Ah, but since we'll have One Configure To Rule Them All, we can replace
it with something more modern:
Congratulations, you aren't running Windows.
(I expect the OS probe step to be noisy, because we don't know what the
OS is yet, so we'll probably be spewing out error messages left and
right as we stumble about without knowing if we can even do Unix-style
I/O redirection.)