One of the items on the Parrot TODO is to build a Configure
system. I don't want to spark up the old metaconfig-versus-autoconf
debate again, so I'll clarify what I mean.

We have long-term and short-term goals for Parrot's configure
system.

The long-term goal is not something I want people to worry about
right now, but it would be good if people could start thinking about
it. Eventually, we want Parrot's configure to work a little like
the proposed microperl configure system.

That's to say, we build a tiny tiny version of Parrot with default
values for various config assumptions; we can ship config.h files
that work on standard Unix platforms, Win32, and so on. Then that
microparrot runs various precompiled bytecode programs which probe
the system finding out more information about the enivronment, and
produce a config file which is used to build Parrot proper.

But we can't do that right now because we don't have a very easy
way of generating those precompiled bytecode programs. So relax.

The short-term goal is really really simple and really really neat.

You'll notice that the Parrot build process currently depends on the
existence of Perl 5 to build certain header files and preprocess the
opcode table. So if we know we've got Perl 5 hanging around, we know
we've already got a config file which tells us things like how big IVs
are, what header files we have around, and so on. Furthermore, we
can write a Perl program which uses Config.pm to give us this
information in a hash, and hence we can use that to produce a config.h 
specific to a given machine.

So I'd like to see a patch which consists of a program to
automatically generate Parrot's config.h from Perl's Config.pm. You
could be really clever, and also have it conditionally include some
of the header files mentioned in parrot.h depending on whether the
i_... values in Config.pm say we have them. (You may need to move the
"#include"s of the system header files from parrot.h to config.h)
No prizes will be awarded for using Perl's config.h, or C preprocessor
abuse. :)

Furthermore, I'd like to see a Portability Pumpkin step forward to
warn us when we're doing things that don't go down too well on Cray
Unicos or QNX 6.

Simon

Reply via email to