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

Re: a plan for ext/

Thread Previous | Thread Next
From:
Rafael Garcia-Suarez
Date:
January 25, 2009 05:51
Subject:
Re: a plan for ext/
Message ID:
b77c1dce0901250551m4e1aa776n6f916ac5715c6ee2@mail.gmail.com
2009/1/24 Nicholas Clark <nick@ccl4.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.

IIRC there might be some ordering problems here -- SDBM_File comes to
mind (but arguably it's only one extension).

> 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

Good plan.

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