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

Reply via email to