Re: Easier building of Perl

[Andy Dougherty <doughera@lafayette.edu>]

On Tue, 11 Jan 2000, Johan Vromans wrote:

> Would it be feasible to split the Perl configure process in two
> stages. The first stage uses a reasonably small shell script 

> In the second stage, the miniature interpreter processes a much bigger
> configure script (Makefile.PL?) and gathers the information to build

> This is just an idea. I guess is has many aspects that need to be
> investigated. But I think it may be worth considering.

It's an elegant and interesting idea, but it's also a lot lot lot lot of
work both short term and long term (it's useless unless it's maintained),
and I think the scale of the project scares off most volunteers.

Here are my personal musings on why I've never done this sort of rewrite
myself.

First, it's not obvious that it buys as much as you might first imagine.
Let me give a specific example.  Here's the section from Configure where
we try to determine what typedef to use for lseek():

    : see what type lseek is declared as in the kernel
    rp="What is the type used for lseek's offset on this system?"
    set off_t lseektype long stdio.h sys/types.h
    eval $typedef_ask

Translating that into perl might look something vaguely like this 
(assuming some useful functions have been defined previously)

    # see what type lseek is declared as in the kernel
    $lseektype = typdef_ask($lseektype,
	prompt => "What is the type used for lseek's offset on this system?",
	alts => [qw(off_t long)],
	includes => [qw(stdio sys/types.h)]);

More readable, yes, but so dramatically so that it's worth the huge
investment to rewrite?  A difficult question.

It seems to me as if most of the major useful abstractions are already
done in Configure.  Though they are often obscure and ugly, they usually
work and we just re-use them.  The difference between Configure for a
microperl and Configure for the full perl is often just adding additional
checks of the sort illustrated above.  This is why I never bothered to try
to rewrite Configure to handle the extensions with a Perl script. It was
easier to just add yet-another-Configure check

	set dlopen d_dlopen
	eval $inlibc

to look for dlopen() than to reinvent Configure to write those lines as

	$d_dlopen = inlibc(d_dlopen, dlopen);

Now, I grant that many tests in Configure are far more complex than this.
Usually that's because the world is messy.  Sometimes those tests would be
a good bit less messy in Perl than in shell, but sometimes they wouldn't.

Maintaining both a shell Configure (even a smaller one) and a Perl
Configure strikes me as a lot of work, including a fair amount of
duplication.

If we're to travel this road at all, I think perhaps the path Ilya started
(with "crazyperl") and which Simon is pursuing may be the better path.  
That is, abandon the shell Configure altogether.  Try to write a tiny perl
that requires no configuration at all.  (Give up later and put in some
#ifdefs for VMS, MAC, WIN32, etc. but try to keep them to a minimum and
try not to use them for the full perl.)  Then use that tiny perl to run a
new streamlined Configure-in-perl.

It's still an awful lot of work.  My hat's off to anyone willing to
attempt it.

    Andy Dougherty		doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042

---

Follow-Ups from:

JVromans@squirrel.nl (Johan Vromans)

References to:

JVromans@Squirrel.nl (Johan Vromans)

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---