Thread: [Module-build-general] MakeMaker Is DOOMED!
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: <sc...@po...> - 2003-02-13 09:34:24
|
Tonite at Portland.pm I gave a lightning talk entitled "MakeMaker Is DOOMED! or MakeMaker Is Dead! Long Live Module::Build!". Executive summary: The architecture of MakeMaker is fundamentally flawed by having to use an external build tool. Further feature development is discouraged. Use Module::Build instead. Which is what I've been saying all long. :) http://www.pobox.com/~schwern/talks/MakeMaker_Is_DOOMED/ I'll be giving a somewhat longer version of this at the German Perl Workshop, pending some financial disputes, talking a lot more about Module::Build and less about how much I am sick of MakeMaker. |
|
From: Ken W. <ke...@ma...> - 2003-02-16 03:43:05
|
On Thursday, February 13, 2003, at 03:30 AM, sc...@po... wrote: > Tonite at Portland.pm I gave a lightning talk entitled "MakeMaker Is > DOOMED! > or MakeMaker Is Dead! Long Live Module::Build!". Excellent. =) I should bring a Grim Reaper mask to YAPC/TPC this year. -Ken |
|
From: Brian I. <in...@tt...> - 2003-02-16 19:35:44
|
On 15/02/03 21:43 -0600, Ken Williams wrote:
>
> On Thursday, February 13, 2003, at 03:30 AM, sc...@po... wrote:
> > Tonite at Portland.pm I gave a lightning talk entitled "MakeMaker Is
> > DOOMED!
> > or MakeMaker Is Dead! Long Live Module::Build!".
>
> Excellent. =) I should bring a Grim Reaper mask to YAPC/TPC this year.
I went to the talk. It got me to thinking about CPAN::MakeMaker and its
relationship to Module::Build.
Given:
The goal of CP::MM is to allow authors to write very simple/clean
Makefile.PLs that can potentially "turn on" very powerful features
like "bundling" with the flick of a switch.
The Makefile.PL produces a Makefile.
Then:
There is no reason why CP::MM can't produce a Makefile that wraps
Module::Build!
If the author has a version of Module::Build on there system that
is sufficient to handle the options that the author has requested
of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B
into the author's dist. After that nobody is the wiser. Everything
just works.
Except that if the USER is installing on a makeless system, CP::MM
will prompt them to use Build instead.
Conclusions:
CP::MM becomes a migration tool for moving over to Module::Build.
The users always have the correct version of M::B, because it is
bundled in. (Just like CP::MM itself)
CP::MM focuses on "refactoring fancy functionality into simple
switches".
M::B focuses on replacing MakeMaker.
Yay! Thoughts?
Cheers, Brian
|
|
From: Ken W. <ke...@ma...> - 2003-02-17 18:09:24
|
On Sunday, February 16, 2003, at 01:35 PM, Brian Ingerson wrote: > I went to the talk. It got me to thinking about CPAN::MakeMaker and its > relationship to Module::Build. > > Given: > > The goal of CP::MM is to allow authors to write very simple/clean > Makefile.PLs that can potentially "turn on" very powerful features > like "bundling" with the flick of a switch. > > The Makefile.PL produces a Makefile. > > Then: > > There is no reason why CP::MM can't produce a Makefile that wraps > Module::Build! I'm not sure that's ideal, because it still requires 'make' to orchestrate at least some of the process. One of the hairiest parts of Module::Build is the tiny little pass-through Makefile in Module::Build::Compat, because it has to work in all kinds of different environments. I've just made a bunch of changes that let it work on Windows, but there are still a bunch of things missing, like translating MM command-line options to M::B options > If the author has a version of Module::Build on there system that > is sufficient to handle the options that the author has requested > of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B > into the author's dist. After that nobody is the wiser. Everything > just works. I wouldn't want lots of installation tools bundled into all my distributions, though. I still think it's far better to have a powerful system for listing dependencies in as fine-grained and accessible a manner as is necessary, and let the user choose their favorite policies and tools for fulfilling those dependencies. -Ken |
|
From: Brian I. <in...@tt...> - 2003-02-17 19:41:39
|
On 17/02/03 12:08 -0600, Ken Williams wrote:
>
> On Sunday, February 16, 2003, at 01:35 PM, Brian Ingerson wrote:
> > I went to the talk. It got me to thinking about CPAN::MakeMaker and its
> > relationship to Module::Build.
> >
> > Given:
> >
> > The goal of CP::MM is to allow authors to write very simple/clean
> > Makefile.PLs that can potentially "turn on" very powerful features
> > like "bundling" with the flick of a switch.
> >
> > The Makefile.PL produces a Makefile.
> >
> > Then:
> >
> > There is no reason why CP::MM can't produce a Makefile that wraps
> > Module::Build!
>
> I'm not sure that's ideal, because it still requires 'make' to
> orchestrate at least some of the process.
Not necessarily. It can create both the Makefile and the Build script,
and then cue the user what to do, especially on non-unix systems.
> One of the hairiest parts of
> Module::Build is the tiny little pass-through Makefile in
> Module::Build::Compat, because it has to work in all kinds of different
> environments. I've just made a bunch of changes that let it work on
> Windows, but there are still a bunch of things missing, like
> translating MM command-line options to M::B options
>
>
> > If the author has a version of Module::Build on there system that
> > is sufficient to handle the options that the author has requested
> > of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B
> > into the author's dist. After that nobody is the wiser. Everything
> > just works.
>
> I wouldn't want lots of installation tools bundled into all my
> distributions, though. I still think it's far better to have a
> powerful system for listing dependencies in as fine-grained and
> accessible a manner as is necessary, and let the user choose their
> favorite policies and tools for fulfilling those dependencies.
It's a good experiment actually. Module::Build and Test::More are two
excellent modules that I will probably not use because of the "prereq
syndrome". I won't add prerequisites to a module unless it is crucial to
that module's behaviour. And while useful, M::B and T::M are not
crucial.
On the other hand, if I can just create a Makefile.PL like this:
use CPAN::MakeMaker;
WriteMakefile;
and have it do all the right things with no added prereqs, well
fantastic. If it adds a few kilos to my tarball I certainly won't sweat
it.
M::B modules minus the Pod doc is 12kb as a tar.gz.
---
And I won't have to worry about what versions of T::M and M::B support
my module's needs because "Hey, it worked on my system, it almost
certainly will work everywhere else, because it's the exact same
version."
If a later version of M::B or T::M is incompatible or broken, it will
have absolutely no effect on that module I wrote 10 years ago before I
left the Perl community altogether to pursue a fulltime career in Pizza
Delivery Management.
Cheers, Brian
|
|
From: Ken W. <ke...@ma...> - 2003-02-17 20:09:42
|
On Monday, February 17, 2003, at 01:41 PM, Brian Ingerson wrote: > Not necessarily. It can create both the Makefile and the Build script, > and then cue the user what to do, especially on non-unix systems. > Okay, that sounds reasonable. > It's a good experiment actually. Module::Build and Test::More are two > excellent modules that I will probably not use because of the "prereq > syndrome". I won't add prerequisites to a module unless it is crucial > to > that module's behaviour. And while useful, M::B and T::M are not > crucial. Sometimes they are crucial for some projects. For example, some of my modules have "recommended" dependencies that I can't express well using MakeMaker. Crypt::SKey needs either Digest::MD4 *or* Digest::MD5, and it can optionally use Term::ReadKey to function as a simple SKey command-line calculator. But the module can be useful with only Digest::MD4, for example, so using M::B's more flexible prerequisite system means that the user will actually have *fewer* required prereqs than under MakeMaker, even if they don't already have M::B installed. Then there are the cases where in order to get something installed correctly, I just can't manage to do the job properly using EU::MM, so I have to turn to M::B. For many of my modules, I've been distributing with both a Makefile.PL and a Build.PL, and before too long I'll probably turn the Makefile.PLs into pass-throughs when it gets too hectic for me to manage both of them. But I won't do that for crucial modules until M::B is more well-known and more widely distributed and tested. > And I won't have to worry about what versions of T::M and M::B support > my module's needs because "Hey, it worked on my system, it almost > certainly will work everywhere else, because it's the exact same > version." And what of the people who have been sending me bug reports that say that M::B doesn't work right on Win32, even though I tested it fine on my iBook? Maybe at some future date we'll be able to make modules that a) have no unspotted bugs, and b) have no cross-platform issues, but I don't think we're there yet. > If a later version of M::B or T::M is incompatible or broken, it will > have absolutely no effect on that module I wrote 10 years ago before I > left the Perl community altogether to pursue a fulltime career in Pizza > Delivery Management. So, which do you think is more common: a) an unseen bug in a module gets fixed in a future version, or b) a module with no bugs gets broken in a future version? I'd say it's a), and that CP::MM (as described, at least) optimizes for the less common case instead of the more common one, in a way that would annoy me as a developer or system maintainer. I think that in the CP::MM project, it will be *crucial* to allow the user to use an upgraded version of a module that they've installed more recently than the one the developer provided in the bundle, for the reasons I described above. It's really just not true that "it worked once for the developer" implies that "it will work for everyone else now and forever". Usually the way people deal with buggy code on their systems is to upgrade things using bug-fix releases, but if you keep distributing buggy versions cached in CPAN distros people are going to be awfully upset. -Ken |
|
From: Brian I. <in...@tt...> - 2003-02-19 06:06:37
|
On 17/02/03 14:09 -0600, Ken Williams wrote:
>
> On Monday, February 17, 2003, at 01:41 PM, Brian Ingerson wrote:
> > Not necessarily. It can create both the Makefile and the Build script,
> > and then cue the user what to do, especially on non-unix systems.
> >
>
> Okay, that sounds reasonable.
>
>
> > It's a good experiment actually. Module::Build and Test::More are two
> > excellent modules that I will probably not use because of the "prereq
> > syndrome". I won't add prerequisites to a module unless it is crucial
> > to
> > that module's behaviour. And while useful, M::B and T::M are not
> > crucial.
>
> Sometimes they are crucial for some projects. For example, some of my
> modules have "recommended" dependencies that I can't express well using
> MakeMaker. Crypt::SKey needs either Digest::MD4 *or* Digest::MD5, and
> it can optionally use Term::ReadKey to function as a simple SKey
> command-line calculator. But the module can be useful with only
> Digest::MD4, for example, so using M::B's more flexible prerequisite
> system means that the user will actually have *fewer* required prereqs
> than under MakeMaker, even if they don't already have M::B installed.
>
> Then there are the cases where in order to get something installed
> correctly, I just can't manage to do the job properly using EU::MM, so
> I have to turn to M::B.
>
> For many of my modules, I've been distributing with both a Makefile.PL
> and a Build.PL, and before too long I'll probably turn the Makefile.PLs
> into pass-throughs when it gets too hectic for me to manage both of
> them. But I won't do that for crucial modules until M::B is more
> well-known and more widely distributed and tested.
I agree with all this. I am definitely in favor of M::B over EU::MM. And
in a perfect world, every Perl module would use a perfect version of
M::B that was installed on every installation of Perl. But we ain't
there yet. The technical and social bootstrapping is going to be a long
and winding road with many cats to shepard. I'm looking for ways to
abstract over both systems to smooth the transition. I hope that one day
(not too far away) CP::MM is a wrapper over completely over M::B instead
of both systems.
(EU) MakeMaker is Dead. Long live (CP) MakeMaker. ;)
> > And I won't have to worry about what versions of T::M and M::B support
> > my module's needs because "Hey, it worked on my system, it almost
> > certainly will work everywhere else, because it's the exact same
> > version."
>
> And what of the people who have been sending me bug reports that say
> that M::B doesn't work right on Win32, even though I tested it fine on
> my iBook? Maybe at some future date we'll be able to make modules that
> a) have no unspotted bugs, and b) have no cross-platform issues, but I
> don't think we're there yet.
Right. This is assuming a more mature M::B of course. But we're getting
there relatively fast no?
> > If a later version of M::B or T::M is incompatible or broken, it will
> > have absolutely no effect on that module I wrote 10 years ago before I
> > left the Perl community altogether to pursue a fulltime career in Pizza
> > Delivery Management.
>
> So, which do you think is more common: a) an unseen bug in a module
> gets fixed in a future version, or b) a module with no bugs gets broken
> in a future version? I'd say it's a), and that CP::MM (as described,
> at least) optimizes for the less common case instead of the more common
> one, in a way that would annoy me as a developer or system maintainer.
>
> I think that in the CP::MM project, it will be *crucial* to allow the
> user to use an upgraded version of a module that they've installed more
> recently than the one the developer provided in the bundle, for the
> reasons I described above. It's really just not true that "it worked
> once for the developer" implies that "it will work for everyone else
> now and forever".
>
> Usually the way people deal with buggy code on their systems is to
> upgrade things using bug-fix releases, but if you keep distributing
> buggy versions cached in CPAN distros people are going to be awfully
> upset.
I see what you are saying, but here's the deal: If a bug is found in a
bundled installation support module like T::M or M::B, and it is known
to be fixed in a later version, there is ONE EXACT POINT of contact in
the entire universe. And we know her email address by definition.
Email the (CP::MM using) module author and tell them to re-release with
the fixed version and the worldwide problem is fixed for everyone in one
fell swoop. And this will take the author all of 5 minutes to do.
No need to hunt down and inform the thousands of M::B installees with a
busted version.
So I'll have to disagree with you here. It is *crucial* that CP::MM
always respects its private environment. That is the central theme
of CP::MM.
---
Now, that said, an inquisitive young sysadmin could simply run:
make reset
perl Makefile.PL
And CP::MM would reset the distro as if that person were the author.
They could fiddle with it until it worked on their platform and then
report their findings back to the real author.
Cheers, Brian
PS I really do like/support Module::Build. Keep up the good work.
|
|
From: Ken W. <ke...@ma...> - 2003-02-19 17:03:56
|
On Wednesday, February 19, 2003, at 12:06 AM, Brian Ingerson wrote: > On 17/02/03 14:09 -0600, Ken Williams wrote: >> >> Then there are the cases where in order to get something installed >> correctly, I just can't manage to do the job properly using EU::MM, so >> I have to turn to M::B. >> >> For many of my modules, I've been distributing with both a Makefile.PL >> and a Build.PL, and before too long I'll probably turn the >> Makefile.PLs >> into pass-throughs when it gets too hectic for me to manage both of >> them. But I won't do that for crucial modules until M::B is more >> well-known and more widely distributed and tested. > > I agree with all this. I am definitely in favor of M::B over EU::MM. > And > in a perfect world, every Perl module would use a perfect version of > M::B that was installed on every installation of Perl. But we ain't > there yet. The technical and social bootstrapping is going to be a long > and winding road with many cats to shepard. I'm looking for ways to > abstract over both systems to smooth the transition. Sounds like exactly the way I feel too. >> And what of the people who have been sending me bug reports that say >> that M::B doesn't work right on Win32, even though I tested it fine on >> my iBook? Maybe at some future date we'll be able to make modules >> that >> a) have no unspotted bugs, and b) have no cross-platform issues, but I >> don't think we're there yet. > > Right. This is assuming a more mature M::B of course. But we're getting > there relatively fast no? Yeah, but you have to remember, it's Software. It's always going to have problems. We'll never actually get to Wally World. ;-) -Ken |
Thanks for helping keep SourceForge clean.
X