Front page | perl.perl5.porters |
Postings from January 2009
Re: a plan for ext/
Thread Previous
From:
Nicholas Clark
Date:
January 25, 2009 03:37
Subject:
Re: a plan for ext/
Message ID:
20090125113702.GY95022@plum.flirble.org
On Sat, Jan 24, 2009 at 11:58:25PM -0500, David Golden wrote:
> On Sat, Jan 24, 2009 at 4:57 PM, Nicholas Clark <nick@ccl4.org> wrote:
>
> > However, one problem I thought that we might hit is (effectively) "early"
> > and
> > "late" extensions, where "early" would be anything that is part of the
> > toolchain needed to bootstrap the build of extension modules, and should be
> > completely built "early" (and installed to lib/) before running the
> > Makefile.PL of most everything else.
> >
>
> What about just having a manifest-like file with an ordered list of ext/* to
> build? It should change relatively infrequently so it's just the one-time
> pain to figure out the key dependencies and move them up in the build
> order. (This would work not unlike a Bundle, actually.)
The only real dependencies here are actually 'build_requires', as the core
builds everything in ext before running any tests. So the problem to solve
is actually simpler than it might seem, which I think means we can get away
with something simpler than your suggestion.
> More radically, perhaps, I believe CPAN.pm only requires File::Spec,
> File::Temp, Scalar::Util, Test::Harness and Test::More (and File::HomeDir on
> Darwin). So if those can get bootstrapped, then potentially CPAN.pm could
> be used to build up everything else. On the one hand, that may be more
> complicated than make_ext, but on the other hand, the less difference
> between installing a dual-life module during core build versus afterwards,
> the better.
CPAN.pm is way more complicated than make_ext.
Also, I think it *would* be a lot of differences, different differences, as
CPAN.pm would have to be run in an unconfigured mode, told not to make any
network connections, ignore the fact that there are no PAUSE indexes anywhere,
not use a ~/.cpan directory, and build against an uninstalled perl, possibly
with extra environment variable fudging to cope with libperl.so not being
installed.
It wouldn't build modules in parallel nicely, and the tests results wouldn't
aggregate properly.
Nicholas Clark
Thread Previous