good chemistry is complicated,
and a little bit messy -LW
Re^3: On packaging modules (time to fix the big Module::Build issues)by schwern (Scribe)
|on Dec 15, 2004 at 09:00 UTC||Need Help??|
Now if we can get Module::Build to include a pass-through Makefile.PL by default
No, Module::Build should not produce a Makefile.PL by default. MakeMaker can't do all the things Module::Build can do and vice-versa. The generated Makefile.PL will not contain any extra logic in the Build.PL, such as asking the user configuration questions or sniffing the environment.
But most importantly, MAKEMAKER HAS TO DIE!
Having Module::Build attempt to be backward compatible with MakeMaker is a temporary solution while MB firms up and CPAN utilities catch up with it (CPANPLUS 0.50 finally handles MB pretty good). It has to take over fully from MakeMaker. Ubiquitous Makefile.PLs just delay this.
I'm assuming that the major Win32-related issues with Module::Build have been addressed.
Something projects like Module::Build and MakeMaker are always short on are Windows developers and Windows machines to check stuff out on. I can almost never find someone to check out MakeMaker releases, its actually easier for me to find VMS folks than Windows folks. And at the very least I can log into a remote VMS machine and test things out. I don't have any such thing for Windows (VNC does not count, its not multi-user AFAIK).
This is not a dig at Windows, its a problem statement. If you know of a way we can log into a remote Windows server to test things out, let us know. Or if you know some font of competant Windows Perl developers send them over to firstname.lastname@example.org and email@example.com.
There's a bunch of open Win32 bugs on rt.cpan.org. Have at 'em.
The second issue will probably be getting Module::Build into core Perl.
MB is slated to go into 5.10 along with CPANPLUS.
-- Michael G Schwern