Michael G Schwern wrote: > (Slight problem. The script never gets written to blib and thus never > gets installed. This is with Module::Build 0.2611.)
This problem has been resolved with the currently available Make::Build::Convert that defines the M::B argument 'script_files' in Build.PL; Make::Build::Convert strives to be the designated successor of make2build. > This does the "override WriteMakefile" trick. Excellent! I was just > wishing that existed the other day. Since this is the most accurate way > involving the least duplication to maintain both a Makefile.PL and a > Build.PL, I would recommend its inclusion into Module::Build. While it might be rather efficient in terms of speed, I doubt whether it'll be able to convert Makefile.PL's correctly that define additional code. I'm inclined to agree with the inclusion, but the last words relating to this matter are to be spoken by Ken. 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'; > > The advantages here are: > > * Any changes to the Makefile.PL are immediately reflected in the Build.PL Ken Williams wrote: > 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. What Ken said and replacing Makefile.PL with the passthrough one created by M::B::Compat should turn out to be sufficient enough. Michael G Schwern wrote: > * Any extra processing done in the Makefile.PL still happens when the > user runs the Build.PL. This includes prompting the user for more > information and any calculations necessary to determine the arguments > to WriteMakefile(). Ken Williams wrote: > 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(). What Ken said. Michael G Schwern wrote: > In fact, the only things this approach can't potentially handle are overrides > of MakeMaker methods. Nothing's going to handle that. I agree about the overriding argument. > And a final recommendation. Extend what the overriden WriteMakefile() can > handle to accept Module::Build->new arguments directly. Since (nearly) > all of WriteMakefile's arguments are upper-case, this is a simple > matter of passing any lowercase arguments straight through. That way one > can maintain a Makefile.PL while still taking advantage of some of > Module::Build's features. That seems like an ugly way as intermixing arguments will almost certainly break things when lower-cased MakeMaker arguments are passed in which is not a hypothetical case as such. Once again, traditional Makefile.PL's should rather be converted than upheld - otherwise we'll never get rid of the awful make dependency. Ken Williams wrote: > 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%. I don't know about the accuracy of your guess, but it sounds reasonable. We could also implement both; running the "override WriteMakefile" trick if only WriteMakefile() is present, parsing it if additional code could be found. > These are of course very scientifically derived guesses. ;-) Your guess is probably right, except for the percentages which might differ in detail. > 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. I certainly will.
