Front page | perl.perl5.porters |
Postings from August 2009
Re: The plan for ext/ and dual-life modules
Thread Previous
|
Thread Next
From:
David E. Wheeler
Date:
August 28, 2009 16:35
Subject:
Re: The plan for ext/ and dual-life modules
Message ID:
F57BD52B-25E0-4F60-AFD4-5F1CCCE84F15@kineticode.com
On Aug 28, 2009, at 1:55 PM, Nicholas Clark wrote:
> As of last night, this is in.
> http://perl5.git.perl.org/perl.git/commit/2adbc9b6919cad1240a83432
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)
Agreed.
> 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/Maintainers.pl 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 Maintainers.pl? 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/constant.pm 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/
+1.
> 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.
Best,
David
Thread Previous
|
Thread Next