Here's an alternative approach. Why make compiler dependencies special? Treat them like any other alien dependency. How do we do that? Wrap a module around it. ExtUtils::CBuilder is one example. The various Alien modules are another. There's already existing wrapper modules for ssh, rsync and gpg.
By using a wrapper module around an external dependency has several advantages: It fits with the existing module dependency system just fine. You just depend on the appropriate alien module. If the external dependency doesn't exist either the alien module installs it for you or its installation fails thus stopping the build process. The user then looks at the docs of the alien module (the point of failure) to see what's wrong and how to resolve it. The narrow scope of the module means the appropriate docs will be easier to find. It ensures the external dependency is installed and working better than the Module::Build folks can. Its available to all build systems. MB and MakeMaker don't have to duplicate effort. Its one less thing to add to the Module::Build / MakeMaker monoliths. One less thing to add to the maintenance pile. It can be built, maintained, documented and released separately. Less work for the MB folks. Narrow scope means better quality and docs. It allows the module author to choose which external interface they're going to use rather than being forced to use the one the build system decides. It works for any external dependency, not just compilers. Need rsync? Ok, depend on Alien::rsync. SSH? GPG? Alien module authors can provide Module::Build plugin/adaptors for their modules. Or in certain obvious special cases, such as C compilers, MB can come with support for popular C wrappers built in (such as it does for ExtUtils::CBuilder).
