On Mon, Aug 29, 2011 at 1:50 AM, Aristotle Pagaltzis wrote:
I find this module intriguing.
Thank you. It grew out of Acme::Module::Build::Tiny -- which was an
exercise to determine the *minimal* API that Build.Pl/Build needed to
allow the toolchain to install a module. (Thus cutting out all the
authoring cruft that bled into Module::Build over the years.) Kudos
to Leon for taking it from Acme and making it real.
In my understanding, the complexity of Module::Build piled up
because the same tool tries to cover both installation and
authoring use cases.
That is one part of the complexity (OO subclassing is the other part).
I suspect that the majority of the lines of code are due to author
support, not installation support.
But is the implementation up to par?
Essentially: if I’m using Dist::Zilla for authoring, what regular
features not explicitly mentioned in MBT’s POD would I have to
avoid? Do things like optional or build-/test-only deps work?
(I’d assume these do.) Or can I assume that everything will work
unless otherwise pointed out?
I haven't used it in my own modules. With Dist::Zilla to hide the
ugliness of Makefile.PL from me, I just let it use that. Most if not
all of what dzil does should still work. The exception would be
plugins that want to hack directly on a generated Makefile.PL (e.g.
I could answer this for myself if I had *exact* understanding of
how much of the work falls upon the .PL at install time, and how
many of the toolchain features are implemented in the CPAN client
and thus unaffected by MBT’s minimalism.
MBT uses many external libraries (many core, some not yet core :-) to
do what it does. Here's a very simplistic version of the install
process (not specific to MBT):
* PL -- resolve any dynamic configuration issues; write prereq data
into somewhere the toolchain can find it (MYMETA is the new standard,
but EUMM and MB had their own custom ways to do it); alert users to
* make/Build -- assemble all files to be installed into blib/ -- for
pure perl module, this is usually just copying from lib/, unless there
are other foo.PL modules to generate foo.pm; for C/XS modules, a lot
of libraries are needed to compile the XS, location the C compiler,
etc. This is ugly, complicated stuff to get right portably, which is
why MBT doesn't do it (yet)
* test -- run tests in t with Test::Harness (or possibly
TAP::Harness); the make/Build tools is responsible for determining the
list of files to run, including possible recursion in t/, as well as
setting any necessary environment variables (e.g. PERL5LIB)
* install -- assemble a manifest of files to be installed from blib/
and hand off to ExtUtils::Install to do the dirty work
One of the hard parts throughout the stuff above is getting the
library paths correct. For installation, that means sorting out where
to install given PREFIX/INSTALL_BASE or custom library paths. For
testing, that means ensuring the right PERL5LIB/PATH given the various
ways they could be set, e.g. in an original PERL5LIB, via "-I bar"
flags to "perl Makefile.PL" or "perl Build.PL", or via "use lib"
statements in *.PL
(More that you wanted to know, perhaps.)
(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.)
I don't personally plan to do more work on it now that the
Build.PL/Build API has been demonstrated. I'll leave that to Leon to
respond to. Most of the original Acme::Module::Build::Tiny
limitations were design decisions to stay consistent with the Tiny
philosophy of providing 90% of the functionality of the "heavy" module
in a fraction of the code. I wasn't trying to rewrite M::B. I was
trying to write a new, minimalist replacement sufficient for most
things on CPAN that didn't require any changes to
Eric raises the question "why bother" and I think for module authors,
at least right now, there is no burning platform to switch. Schwern
has been trying to get people to stop using EU::MM for years and I
think the MBT is a stepping stone towards that vision. Once it
figures out the hard bits of interacting with the toolchain, it should
be relatively easy for it or successors to add the missing features
within a well-defined framework.
Perl 5.10.1 supports configure_requires and is already unsupported by
P5P, though the Perl toolchain maintainers have an informal agreement
to support older Perls (5.6 at least, though that may shift to
something in the 5.8 series with decent Unicode support before long).
By the time that MBT has enough track record for widespread adoption,
I would hope that Perl 5.10.1 becomes the oldest perl supported by the
toolchain and then MBT or other Build.PL solutions will be the future
and we'll finally put a stake in the heart of ExtUtils::MakeMaker.