develooper Front page | perl.perl5.porters | Postings from January 2009

Re: a plan for ext/

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
January 24, 2009 13:57
Subject:
Re: a plan for ext/
Message ID:
20090124215708.GU95022@plum.flirble.org
On Sat, Jan 24, 2009 at 03:26:49PM -0600, Craig A. Berry wrote:
> On Sat, Jan 24, 2009 at 10:46 AM, Nicholas Clark <nick@ccl4.org> wrote:

> >   For starters, that means merging in functionality from win32/buildext.pl
> >   I'm not sure how VMS does it
> 
> make_ext.com is generated at configuration time by configure.com.  It
> parses config.sh to get the value of $Config{extensions}, then invokes
> miniperl and the make utility to build the extensions.  It also
> supports a clean target.

Aha.

But HP discontinued testdrive, so there's no way for me to play with this :-(

> > 3: Re-arrange ext/ so that everything is at the top level.
> >   ext/Sys/Hostname becomes ext/Sys-Hostname
> >   ext/Sys/Syslog           ext/Sys-Syslog
> >
> > This makes "known extensions" as simple as a glob of ext/*
> > There is no more multi-level scanning.
> > There are no more exceptions - eg ext/Encode/Symbol/Makefile.PL does not
> > represent a distinct extension, whereas ext/threads/shared/Makefile.PL does.
> 
> No more exceptions for sub-module status, but there would still be
> exceptions for other reasons, such as only building the Win32*
> extensions on Win32, only building extensions that depend on an
> external library when that library is available, etc.

True. But it removed a lot of complications for "is this directory something to
do with its parent?"

Particularly where "this directory" doesn't contain a Makefile.PL

> > 5: Start to move dual-life modules from lib to ext
> 
> Once upon a time, everything in ext involved XS and everything in lib
> didn't, with exceptions noted.  The meaning of $Config{nonxs_ext}
> might have to be changed (or it might need to be deprecated) and the
> bits of installperl that use it might have to be looked at.

I think that Jerry Hedden has already spotted and fixed installperl, thanks to
Module::Pluggable being in ext/ (so that it can run a Makefile.PL)
I was hopeful that $Config{nonxs_ext} would work as-is.

However, one problem I thought that we might hit is (effectively) "early" and
"late" extensions, where "early" would be anything that is part of the
toolchain needed to bootstrap the build of extension modules, and should be
completely built "early" (and installed to lib/) before running the
Makefile.PL of most everything else.

(A possibility that occurred to me was to just use ./miniperl to build
DynaLoader, make ./perl earlier, and use it to build the rest of ext, but
Vadim Konovalov pointed out a big flaw in that - it makes cross compiling
far more complex)

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About