On Mon, Aug 29, 2011 at 7:50 AM, Aristotle Pagaltzis <pagalt...@gmx.de> wrote: > I find this module intriguing.
I'm happy to hear that :-) > In my understanding, the complexity of Module::Build piled up > because the same tool tries to cover both installation and > authoring use cases. There are many things that contribute to that. I think there's a more general everything-and-the-kitchensink issue going on in Module::Build. In Module::Build::Tiny I'm trying to go into the opposite direction: modularize everything that's reusable so the central module is actually quite small and simple. > But is the implementation up to par? Not yet, but it's getting close. I'm still dealing with some portability issues, but the core idea of it seems sound. For a pure perl module that runs only on Unix on perl 5.10.1 or higher, it should be up to par now already. If not bug reports are welcomed. I'm only using it for two relatively unimportant modules so far, but I'm planning to try it with more modules as soon as the known issues have been ironed out. > 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? Dependencies are handled in the CPAN client (and written by Dist::Zilla), so that should be no problem. > (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.) HTML documentation support should definitely be added before I'd consider it finished; the others are design choices. That said, I'm not opposed to implementing any of the others if it can be done in a tiny enough way. If I end up adding extensions (which would essentially mean a rewrite of MBT) then even the tininess restriction would be gone for the other ones I guess. On Mon, Aug 29, 2011 at 5:07 PM, David Golden <dagol...@cpan.org> wrote: > 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) I have a prototype tying together ExtUtils::CBuilder and ExtUtils::ParseXS, it only supports simple XS modules and is so far only tested on Linux, but it was pleasantly simple to implement. > 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. Yeah, most of all MBT is an experiment. It's proof that writing a Build.PL implementation doesn't have to be all that hard. It's a process of getting the modules out there that make it easier. Being a viable alternative to existing builders is a bonus really. At some point there will be a non-tiny successor that will do everything Module::Build can and more without becoming an monolith. > 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). Yeah, I think that on the medium timescale 5.8's lack of configure_requires is the main handicap. Fortunately that problem will fix itself if given enough time. Leon
