On Oct 14, 2005, at 7:57 PM, Michael G Schwern wrote:
I would recommend a change in the way it works. Rather than spitting
out
a new Build.PL with static entries, the Build.PL should look something
like this:
# This does the trick of overriding WriteMakefile
use Module::Build::Compat::Make2Build;
do './Makefile.PL';
That would be fine for someone who wants to maintain the Makefile.PL as
their primary builder script and have the Build.PL be subservient to
it, but I think the main use for make2build will be for people who want
to *switch* from MakeMaker to M::B. If they ended up with a "do
'./Makefile.PL';" as their Build.PL, they'd have little (nothing?) to
gain from making the conversion.
The main problem with the "override WriteMakefile" trick is that it
runs all the code intended for the user's machine on the *author's*
machine, effectively freezing everything that should be dynamic. This
works fine for simple modules, but fails (silently!) on something as
simple as using a variable in the call to WriteMakefile().
I do still fantasize about a script that actually parses the
Makefile.PL rather than using the "override WriteMakefile" trick. The
trick seems like it would get you 100% there for 20% of the
Makefile.PLs, silently fail on 70%, and die on 10%. Parsing seems like
it could get you 100% there on maybe 60% of them and die on 40%.
These are of course very scientifically derived guesses. ;-)
Steven, you might be interested to have a look at the
makefile_to_build_args() method in Module::Build::Compat as another
source of parameter translation. You can call it as a class method if
you want.
-Ken