Andreas J. Koenig wrote:
> Recently, on IRC (off the top of my head):
>
> <klapperl>: so can you explain why the compatibility layer is broken?
> <ewilhelm>: jeez, it is the *compatibility layer*
>
> I think it's time that Module::Build considers another compatibility
> layer in addition to the existing one. It would be the one for authors
> who consider the compatibility layer broken for their demands.
>
> This is just a raw sketch to get some talk going, I have not actually
> tried to work this out. So this is the rough layout:
>
> Build.PL has a new option:
> diplomatic_makefile_pl => 1,
>
> The generated Makefile.PL would be very short:
> if (have_Module_Build_installed()){
> system $^X, "Build.PL";
> write_diplomatic_makefile();
> } else {
> beg_user_to_install_module_build_asap();
> write_traditional_compat_makefile();
> }
>
> The generated diplomatic Makefile would then contain:
> default:
> ./Build
> test:
> ./Build test
> install:
> ./Build install
> [...etc...]
>
> So the effect would be that
>
> (1) the module would ship with a Makefile.PL (so old CPAN.pm will not
> try to invent one on its own).
>
> (2) Users with Module::Build installed get the best the author can
> offer.
>
> (3) Users without Module::Build get the best Module::Build::Compat can
> offer.
>
> Has this been tried? Does it have pitfalls? It seems so easy and
> natural. Isn't anybody keen implementing it?
>
> I know that there is to put some more work into this than the above
> sketch. But as the term "diplomatic" suggest, most work would be to
> appear polite to the user instead of demanding and guide them.
This already exists, it is the "passthrough" option to Module::Build::Compat.
small
A small Makefile.PL will be created that passes all
functionality through to the Build.PL script in the same
directory. The user must already have Module::Build installed
in order to use this, or else they’ll get a module‐not‐found
error.
passthrough
This is just like the "small" option above, but if
Module::Build is not already installed on the user’s system,
the script will offer to use "CPAN.pm" to download it and
install it before continuing with the build.
The resuilting Makefile.PL does its best to translate the Makefile.PL args to
Build.PL arguments and then run the Build.PL. It mostly works, and a lot of
work was put into it. I wouldn't call it broken, but it can never be 100%.
Here's why...
1) MakeMaker is poorly documented. We don't even know all the flags
Makefile.PL can take and what they all do. We don't know what all the targets
are. If we don't know what MakeMaker can do we can't translate it. In
particular, getting all the make variables right.
2) MakeMaker does a lot of weird stuff that would be a major bother or
impossible to translate into Module::Build. The compatibility layer nails
most of it, but it only maps so well. Again, the make variables are almost
impossible to get right.
3) Module::Build can do things that MakeMaker cannot and this gap is only
going to get wider. If you're working through the Makefile.PL and make
interface you miss out on these features. In the past this was
--install_base, a much saner take on PREFIX. I eventually implemented
INSTALL_BASE in MakeMaker since it made so much sense, but you see the problem?
I've gone through almost six months of writing a compatibility layer
(Class::DBI to DBIx::Class, fortunately for money) and let me tell you, the
work never ends and it's never quite right. I liken it to a combination of
Xeno's Paradox and Sisyphis' task. You keep fixing half the remaining bugs,
then half that, then half that, getting closer and closer and closer... then
they release a new version and the target moves.
A lot of users prefer to use the "traditional" form of compatibility because
then there's no emulation and no Module::Build to download and no CPAN shell
configuration. This mattered more when PREFIX didn't work, there's less
reason to use it now. Module::Build just writes a normal Makefile.PL to the
best of its ability. Reason #2 really hurts this. More importantly, any
custom code in the Build.PL is lost in translation. This means any questions
about configuration which were added have to be duplicated. Any customization.
Eric's point wrt the CPAN shell's default choice of Build.PL vs Makefile.PL is
valid. The Build.PL is always going to be the better maintained and closest
to what the author intends. If you have Module::Build installed, and a module
has a Build.PL, there's no good reason to prefer the Makefile.PL.
--
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.
