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

Re: The plan for ext/ and dual-life modules

Thread Previous | Thread Next
David E. Wheeler
August 28, 2009 16:35
Re: The plan for ext/ and dual-life modules
Message ID:
On Aug 28, 2009, at 1:55 PM, Nicholas Clark wrote:

>   As of last night, this is in.

Yay! Nicholas++

>   It's a bit rough, and there are currently exceptions in place for  
> specific
>   directories in ext/, some to disable setting $ENV{PERL_CORE},

Should such changes be pushed back upstream?

>   and one to
>   still run ext/File-Glob/t/*.t from t, as those tests expect to see  
> t/TEST
>   and various other files, but IT WORKS.
>   (If anyone would like to help, figuring out how to change them to  
> run from
>    ext/File-Glob would be useful)


> 1: Clean up the existing tests to ext, feeding changes back upstream  
> to their
>   owners

Yeah, excellent.

> 2: Migrate as many dual modules as possible from lib/ to ext/,  
> giving them the
>   exact same layout as their CPAN distributions.

1 and 2 needed be done in sequence, correct? One can be moving stuff  
around in ext while also cleaning things up as described in 1, yes?

>   (As a module gets moved from lib/$somewhere to ext/$name the  
> directory its
>    tests are run from changes from t to ext/$name, so there may be  
> some
>    fixing needed, but as this is all 1 module at a time, it's  
> manageable)
>   This also means fixing the MAP field in Porting/ to  
> reflect
>   the new, untangled layout. (Hopefully removing the MAP field  
> completely)

If things are going to have the same layout as on CPAN, will you even  
need All that data should be in META.yml files for  
each "distribution".

>   Go for the easy ones first. I think that most everything is  
> "easy", except
>   the modules needed to build things in ext/ - ie  
> ExtUtils::MakeMaker, and
>   anything it calls or depends on. So lib/ likely can't  
> easily
>   move to somewhere in ext/constant. I'm not worried - there are  
> dozens which
>   can.
>   Feed all the fixes back upstream

I'd love to help with this.

> 3: I think, but I've not checked the code, let alone tried it, that  
> it might be
>   possible to have more than 1 "ext" directory. In which case, we  
> can split
>   ext into "ext" and "dual". All the core-only modules can stay in  
> ext/
>   All the dual life modules can go in dual/


>   That would makes it incredibly easy for anyone to see which code we
>   "control", and which code and documentation we get from upstream,  
> and so
>   should send patches and bug reports upstream, instead of  
> attempting to fix
>   in place.
> Well, that's my plan. If people think it's a good idea, and want to  
> help,
> that would be great. Pick anything to help with, but in particular
> 1: please try to convert the File::Glob tests to run from ext/File- 
> Glob
> 2: pick any dual life module currently in lib, get the CPAN tarball
>   (named in Porting/Maintainers.PL), and try to move it to ext/

I'll find some tuits to do this next week.



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About