# from Aristotle Pagaltzis
# on Sunday 28 August 2011 22:50:
>In my understanding, the complexity of Module::Build piled up
>because the same tool tries to cover both installation and
>authoring use cases.
I've often had that thought, though I would say that M::B definitely
suffers from being a mature codebase largely lacking its original
author and large amounts of test coverage where small changes could
break the CPAN -- so, that tends to stifle innovation (in my personal
experience.) The compat code (involving various forms of Makefile.PL
workarounds) is also a burden, as is coding to be compatible with
anything older than 5.8.
But I don't think there are really enough authoring features for that to
be a major source of complexity. The "subclassing as customization"
design leaves a lot to be desired and makes it difficult to ever change
or refactor the internals API without breaking someone's distribution.
There is also almost a decade of transition coded into it (e.g.
TAP::Harness vs Test::Harness) and a lot of code just to guard against
being used in ridiculously old installations.
Plus, strange things that happen when you mess with PERL5LIB / -I / 'use
lib', etc and expect that to propagate throughout your tests across
processes regardless of whether you're running red hat or not. We'll
see if MBT has to run the same guantlet.
>I believe the Dist::Zilla approach is a better way to take care
>of authoring... So Dist::Zilla plus the *idea* of Module::Build::Tiny
>seem to fulfil the original concept of Module::Build better than that
>module itself ever has.
If you're using Dist::Zilla, you *should* not need anything besides
META.json to install a simple module if you just set dynamic_config=0.
(This "should" is, of course, largely unimplemented.)
Also, I think that M::B is better as a customizable deployable build
tool than as an author tool. I think it was even conceived as just
that and only years of feature creep have added a lot of author tools.
>But is the implementation up to par?
>...
>(I’d also be interested in whether any omissions mentioned in the
>POD are design choices or the idea is to add them in the future,
>and which if so.)
There might be some trouble being compatible with some of the more
obscure features of buildrc and the env (which somebody always seems to
have setup in a way which you have never thought necessary or logical.)
It does seem to have factored-out many functions which M::B had as
(maybe misplaced) methods.
Overall, it looks interesting, but I would hope that it at least adds
some runtime support if not also C/XS.
Without the ability to have dynamic prereqs or build C/XS, why do you
need a Build.PL at all? You have to assume that the client supports
'configure_requires' or the user has already installed MBT for this to
work. If the Build.PL is a compatibility workaround, that seems like a
weird niche to me because needing 'configure_requires' means you need a
client from the last few years and 'dynamic_config' has been around
longer.
Sadly, cpanm seems to not support dynamic_config. I'm not sure whether
one of the other two clients can "satisfy prereqs from META, run
`prove -lr t`, and install the files from lib/" yet.
--Eric
--
"Insert random misquote here"
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
