On Mon, Aug 29, 2011 at 1:50 AM, Aristotle Pagaltzis <pagalt...@gmx.de> 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. Dist::Zilla::Plugin::DualLife). > 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 things missing * 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 CPAN/CPANPLUS/cpanminus. 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. -- David
