Zefram wrote:
So to fit in with this system, we could arrange for each optional feature of a distribution to be reified as a module. Consider the case I ran into, where I want to declare a dependency on the C language support aspects of Module::Build.
I don't think you have worked through this fully. Assume for a second that Module::Build is installed first /sans/ ExtUtils::CBuilder, and hence this mystical C_support.pm is installed. Now, you go ahead and install ExtUtils::CBuilder second, which has *no* connection to Module::Build::C_support. How would that file get updated? Would C_support merely attempt to load ExtUtils::CBuilder (via eval) and return the appropriate value depending? That seems much more complicated for the framework author to code.
You may want to look at what I did in the version.pm distro. It is actually pretty easy (once you see how) to check for optional features during your build and branch accordingly from your own Build.PL (or for that matter Makefile.PL). I do similar magic in SVN::Notify::Mirror, where I can test various features depending on whether or not some optional modules are installed (though this case doesn't involve build dependencies).
I think it is really the individual module author's responsibility to code for their implicit dependencies, not the responsibility of the installation framework. It is certainly possible that Module::Build could make it even easier to expose whether feature 'A' is installed _now_ (i.e. during the current build). But I'm not sure that equating an optional feature with a phantom module is the way to go.
John
