develooper Front page | perl.perl5.porters | Postings from May 2013

Re: RFC: Deprecating Module::Build

Thread Previous | Thread Next
Nicholas Clark
May 24, 2013 12:20
Re: RFC: Deprecating Module::Build
Message ID:
On Fri, May 24, 2013 at 01:42:26PM +0200, Steffen Mueller wrote:
> On 05/24/2013 01:42 AM, Ricardo Signes wrote:
> > * David Golden <> [2013-05-22T13:44:38]
> >> I propose deprecating Module::Build from core in 5.19 and removing it in
> >> 5.21.
> >
> > I will go poke some more people/groups who might care.  Like:  I'll go
> > cross-post.
> >
> > I don't expect any substantial objections, though, and think we'll end up doing
> > this.  That means:
> >
> >    * add the "use deprecate" to Module::Build
> >    * ship it[1]
> >    * mark it deprecated in CoreList
> >    * set a timer for 5.21.0
> This whole deal about nuking Module::Build from core concerns me.
> The "nobody wants to maintain it" argument really doesn't cut it - if 
> M::B is broken by Perl, a significant fraction of CPAN will explode. 
> We'd have to fix it anyway. Furthermore, we should also expunge 

But Module::Build isn't doing anything that exotic, is it? It would be the
sort of change that would bust a bunch of other things, and we'd either
have to fix a lot of stuff, or not make the change.

Having it no longer in the core makes it clear to anyone considering what
build system to use that it's not looking like something with a future.

> ExtUtils::MakeMaker while we're at it. It's not seen a lot of love 
> either (despite the laudable claims of some).

Yes, but a counter to that is that the core build uses ExtUtils::MakeMaker,
so it is our itch to scratch. The core doesn't use Module::Build, partly
because it *can't* use Module::Build, because Module::Build wasn't written
to be able to bootstrap the XS modules from non-XS. I suspect because that
wasn't part of its design goals.

> Module::Build is rather low in the module building infrastructure and is 
> depended on by A LOT of code. In particular, non-core, non-CPAN build 
> systems may have logic that depends on M::B which will run into 
> "interesting" bootstrapping issues once its gone.

I tend to view what's on CPAN as the best approximation we have of what code
is "out there". If there isn't code on CPAN that can be identified that
breaks in such a way, I'd argue that it's unlikely that there is much
elsewhere. If there is code on CPAN, then I'd take it as an indicator of
the size of the "problem". To be fair, I haven't gone looking on CPAN for
this. But it isn't clear from your phrasing that you're confident of this

> Generally speaking, killing this module in core seems to fall on the far 
> side of the "cost/benefit" line.

I'm not sure. I hate the fact that we have been donated an albatross that
*we don't use* that it seems we are now implicitly expected to support
in perpetuity. It feels like bait and switch, because when it arrived it
was actively maintained by an external group. But that group has
dissipated. There was even a comment on the module-build list a year or
two ago to the effect of "but we made it [to core], and now someone else
looks after it".

Certainly, if it is to stay in core, I think that it should move to ext/
(ie *not* be dual life), be stated as being "bug fixes only", and we only
have to do work to support it on the current release. Not make it work on
all versions that the toolchain supports. (ie back to 5.8.1, as I understand

If Module::Build end users like to use Module::Build, surely they should
pool to contribute to its upkeep?

Nicholas Clark

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