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

Re: a plan for ext/

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
January 24, 2009 13:26
Subject:
Re: a plan for ext/
Message ID:
c9ab31fc0901241326t67a795eaybbeeae3fbcfe0bcd@mail.gmail.com
On Sat, Jan 24, 2009 at 10:46 AM, Nicholas Clark <nick@ccl4.org> wrote:
> My plan for ext/ is roughly this:
>
> 1: Move ext/util/make_ext.pl to the top level.
>   Likewise move ext/util/make_ext_cross, even though it's planned to merge
>   that back into make_ext.pl
>
> I couldn't spot a better place to put them. The important thing here is to get
> them out of ext, so that everything in ext is now an extension
>
> 2: Figure out how to migrate the VMS and Win32 build systems to use make_ext.pl
>   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.

> 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.

> 4: Add support for directories in ext/ that don't have Makefile.PL
>
> For now I was just thinking of "faking up" a Makefile.PL to avoid needing
> to create lots of near-identical instances, that all differ from their CPAN
> counterparts, because they need to special-case MAN3PODS for the core.
> Logically this could be extended to also support Build.PL, but I'm not sure
> what in core that would benefit.
>
> 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.

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