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

a plan for ext/

Thread Next
From:
Nicholas Clark
Date:
January 24, 2009 08:47
Subject:
a plan for ext/
Message ID:
20090124164656.GD2941@plum.flirble.org
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

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.

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

Nicholas Clark

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