Thread: [Module::Build] Re: ExtUtils::MakeMaker or Module::Build
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Randy W. S. <Ra...@Th...> - 2003-11-20 12:25:12
|
Orton, Yves wrote: >>>But as we start to put this together we run across >> >>Module::Build. In >> >>>the past I have always used ExtUtils::MakaMaker. Is there >> >>a preference >> >>>(if one were starting from scratch), to using one over the other? > > > Personally my feeling is that Module::Build isn't mature enough for release > ready code. > > The fact that without manual intervention what it produces isnt compatible > with CPAN is IMO a serious argument against using it, and poses serious > questions in my mind about its suitability in 5.10. Luckily it will be a > long time before 5.10 is released, so Ken has lots of time to get it right. > > BTW, it shouldnt be seen that I am critical of Kens efforts, I actually > think his project is quite a good idea and will eventually be an excellent > replacement for older tools. But IMO it is not production worthy code at the > current time. > > I dont know the logic behind using Build.pl instead of makefile.pl, but the > fact that it doesnt create the later by defualt (or so I have been told) is > in my eyes a serious mistake that will greatly reduce its overall uptake in > the market. And for those people releasing code without a Makefile.pl, I > wonder at the point of putting such things on CPAN. (Others such as Randal > Schwartz have said the same thing) Module::Build has a compatibility feature that does in fact produce a Makefile.PL file for distribution. In addition, you can have both a Build.PL and a MakeMaker Makefile.PL if you want to go that route. > Another serious issue with Module::Build is that for the last ages on Win32 > it doesnt. Have a look at the transaction report of trying to install it > (using itself) from CPAN. It doesnt play nicely with CPAN's prerequisite > system, (a Makefile.pl program would have caused CPAN to autoload these > prerequisites on my system by default) and fails build. Module::Build has worked on Windows since version 0.16 (it also now works on Cygwin as of 0.21); I ported it. Unfortunately the latest release (0.21) had some Windows bugs that I didn't catch before it was released. Despite this last release, I have found it to be very stable. >>There are nearly 200 distinct distributions on CPAN that now use >>Module::Build. And the number continues to inch upward. M::B is >>scheduled to appear in perl 5.10 and ultimately to replace MakeMaker, >>see perldelta. M::B doesn't require a make tool, so on >>platforms that do not include easy access to make, users can still build > > and > >>install pure perl modules. > > > I agree that the makeless make is a worthy objective, and Kens efforts are > to be applauded. But IMO currently its a bit of a waste that these modules > use it and are on CPAN. First off this means that they are unavailable to > Win32 users, a group that make up the majority of the Perl user base > (whatever the *nixens think). And for those that havent bothered including > Makefile.pl's and only Build.pl's, well that code wont install cleanly from > the cpan shell. > > Anyway, > thats my take on using Module::Build. > > Yves > I believe current releases of CPAN(PLUS)? do natively support Build.PL files, but I don't use either of them. (I prefer manual installs). I'm not arguing; I just wanted to clarify a few points. ;) Module::Build is a long way from being complete, but I think it's further along than you think, and it's catching on relatively fast. BTW, If you want to see who and what is using Build.PL, I generated a report a while back at <http://sourceforge.net/mailarchive/forum.php?thread_id=3333245&forum_id=10905> Regards, Randy. |
|
From: Orton, Y. <yve...@de...> - 2003-11-20 13:00:55
|
> > I dont know the logic behind using Build.pl instead of > makefile.pl, but the > > fact that it doesnt create the later by defualt (or so I > have been told) is > > in my eyes a serious mistake that will greatly reduce its > overall uptake in > > the market. And for those people releasing code without a > Makefile.pl, I > > wonder at the point of putting such things on CPAN. (Others > such as Randal > > Schwartz have said the same thing) > > Module::Build has a compatibility feature that does in fact produce a > Makefile.PL file for distribution. In addition, you can have both a > Build.PL and a MakeMaker Makefile.PL if you want to go that route. Well, I find it odd that it works the way it does. CPAN expects a Makefile.PL. If an author doesnt bother to have makefile.pl created (my understanding is that this is not default, I await correction) then the module is not auto installable by a large cross section of the deployed Perls out there. This is an odd decision about a system intended to replace MakeMaker IMO. Build.PL should disappear and be replaced entirely by Makefile.pl. But thats an argument I have no expectation of winning. > > Another serious issue with Module::Build is that for the > last ages on Win32 > > it doesnt. Have a look at the transaction report of trying > to install it > > (using itself) from CPAN. It doesnt play nicely with > CPAN's prerequisite > > system, (a Makefile.pl program would have caused CPAN to > autoload these > > prerequisites on my system by default) and fails build. > > Module::Build has worked on Windows since version 0.16 (it also now > works on Cygwin as of 0.21); I ported it. Unfortunately the latest > release (0.21) had some Windows bugs that I didn't catch > before it was > released. Despite this last release, I have found it to be > very stable. Alas, I have yet to see a stable Win32 build. I do believe that you did one, but..... > I believe current releases of CPAN(PLUS)? do natively support > Build.PL files, but I don't use either of them. (I prefer manual installs). CPANPLUS may do, but i do not think that CPAN does. Even if the latest version does, this doesnt help people who cant upgrade the version that was distributed with their perl, and makes life really difficult for people who "cant install modules". If you cant install modules then the fact that Module::Build and CPANPLUS exist isnt going to help you much. The issue here is backwards compatibility. If you want your code to install accross a wide range of OS's and platforms and perl versions then using Module::Build and expecting people to have CPANPLUS is not going to be a winning proposition. > > I'm not arguing; I just wanted to clarify a few points. ;) > Module::Build is a long way from being complete, but I think it's further > along than you think, and it's catching on relatively fast. I think it would have caught on a LOT faster if the silly Build.PL decision hadnt been made. Breaking the old stuff is ok once the new stuff has sufficient market penetration. Breaking the old stuff from the get go just means youll never have the market penetration to convince people its worthwhile. Frankly until Module::Build works seamlessly by default with plain old CPAN I would advance the opinion that it will never replace MakeMaker, and potentially in the long run leave the community divided, with those of us who can using Module::Build and those of us who cant or need to ensure backwards compatibility not. I personally dont think that the balkanization of CPAN is a fair price for the changes that Module::Build brings. Now if a concerted effort was made to ensure that Module::Build easily installed everywhere (as seen with the prerequisites and Win32 build failure it does not) and that _every_ distribution produced by Module::Build was installable via CPAN.pm then I would feel much more confident about its future. > > BTW, If you want to see who and what is using Build.PL, I generated a > report a while back at http://sourceforge.net/mailarchive/forum.php?thread_id=3333245&forum_id=1090 5> Cheers, Ill have a look at it. Yves |
|
From: Dave R. <au...@ur...> - 2003-11-20 16:14:28
|
On Thu, 20 Nov 2003, Orton, Yves wrote: > Well, I find it odd that it works the way it does. CPAN expects a > Makefile.PL. If an author doesnt bother to have makefile.pl created (my > understanding is that this is not default, I await correction) then the > module is not auto installable by a large cross section of the deployed > Perls out there. This is an odd decision about a system intended to replace > MakeMaker IMO. Build.PL should disappear and be replaced entirely by > Makefile.pl. I wrote a patch for CPAN.pm to add support for Module::Build. To address your complain that Build.PL should be called Makefile.PL, if this were to happen, you'd then complain that Module::Build doesn't accept all the same options as EU::MM. This is intentional, because many of the EU::MM options are implemented in a rather crufty way. A good example is PREFIX. Trying to duplicate this logic really isn't worth it, so Ken chose a much simpler way of doing local installs. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Michael G S. <sc...@po...> - 2003-11-21 03:53:12
|
On Thu, Nov 20, 2003 at 10:13:37AM -0600, Dave Rolsky wrote: > > Well, I find it odd that it works the way it does. CPAN expects a > > Makefile.PL. If an author doesnt bother to have makefile.pl created (my > > understanding is that this is not default, I await correction) then the > > module is not auto installable by a large cross section of the deployed > > Perls out there. This is an odd decision about a system intended to replace > > MakeMaker IMO. Build.PL should disappear and be replaced entirely by > > Makefile.pl. > > I wrote a patch for CPAN.pm to add support for Module::Build. > > To address your complain that Build.PL should be called Makefile.PL, if > this were to happen, you'd then complain that Module::Build doesn't accept > all the same options as EU::MM. This is intentional, because many of the > EU::MM options are implemented in a rather crufty way. A good example is > PREFIX. Trying to duplicate this logic really isn't worth it, so Ken > chose a much simpler way of doing local installs. I'd more than agree. MakeMaker's interface blows, and large parts of it are undocumented. A new build system that was saddled with reimplementing that crappy interface would be extremely difficult, would never really work like MM does and have most of the problems of MakeMaker. M::B's done a really good job of emulating Makefile.PL so far, enough to handle automated installations and the most common options, but its just a backstop while the module installation utilities (CPAN, CPANPLUS, etc...) and user community adjust to M::B. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ This Ring, no other, is made by the elves, Who'd pawn their own mother to grab it themselves. Ruler of creeper, mortal, and scallop, This is a sleeper that packs quite a wallop. -- "Bored of the Rings" |
|
From: Norbert G. <no...@MP...> - 2003-11-23 10:26:40
|
Hi Dave, On Thu, Nov 20 2003, Dave Rolsky wrote: > > I wrote a patch for CPAN.pm to add support for Module::Build. is this patch available somewhere ? I would like to patch CPAN at our installation. I have already applied your patch for EU::ModuleMaker and I would like to do the same with CPAN. Thank you in advance, Norbert -- +-------------------------------------------------------------------+ | Norbert E. Gruener http://www.MPA-Garching.MPG.de/~nog/ | | Max-Planck-Institut <no...@MP...> | | fuer Astrophysik PGP encrypted mail preferred | | PGPprint(RSA): 66 64 C0 D0 6F 1A 16 02 C2 C6 37 83 3A 5F 88 9B | | PGPprint(DH): 8B9A CB28 79DC 4C4F 5A0F 08A8 2771 2A99 A091 FBE8 | | PGPprint(DSS): 8900 2CB4 F3D3 124F 7ED2 F681 EA2D 11CA BE19 6642 | +-------------------------------------------------------------------+ |
|
From: Dave R. <au...@ur...> - 2003-11-24 00:55:44
Attachments:
cpan-diff
|
On Sun, 23 Nov 2003, Norbert Gruener wrote: > On Thu, Nov 20 2003, Dave Rolsky wrote: > > > > I wrote a patch for CPAN.pm to add support for Module::Build. > > is this patch available somewhere ? I would like to patch CPAN at > our installation. I have already applied your patch for > EU::ModuleMaker and I would like to do the same with CPAN. The latest version is attached. I think this was against CPAN 1.76. BTW, EU::ModuleMaker's latest release includes my patch, so you might as well install it. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Norbert G. <no...@MP...> - 2003-11-24 12:02:16
|
On Mon, Nov 24 2003, Dave Rolsky wrote: > On Sun, 23 Nov 2003, Norbert Gruener wrote: > > > On Thu, Nov 20 2003, Dave Rolsky wrote: > > > > > > I wrote a patch for CPAN.pm to add support for Module::Build. > > > > is this patch available somewhere ? I would like to patch CPAN at > > our installation. I have already applied your patch for > > EU::ModuleMaker and I would like to do the same with CPAN. > > The latest version is attached. I think this was against CPAN 1.76. BTW, Thank you for your patch. > EU::ModuleMaker's latest release includes my patch, so you might as well > install it. Thank you also for that hint :-) I will upgrade ASAP. Norbert -- Ceterum censeo | PGP encrypted mail preferred. Redmond esse delendam. | PGP Key at www.MPA-Garching.MPG.de/~nog/ |
|
From: Michael G S. <sc...@po...> - 2003-11-24 02:38:58
|
On Thu, Nov 20, 2003 at 01:00:07PM -0000, Orton, Yves wrote: > If you cant install modules then the fact that Module::Build and CPANPLUS > exist isnt going to help you much. *head scratch* if they can't install modules then it really doesn't matter how modules are installed since they can't install modules. > I think it would have caught on a LOT faster if the silly Build.PL decision > hadnt been made. Breaking the old stuff is ok once the new stuff has > sufficient market penetration. Breaking the old stuff from the get go just > means youll never have the market penetration to convince people its > worthwhile. Except when the old stuff is Fairly Broken, Mostly Undocumented and would be a Nightmare to reproduce. Sort of in the same way that PONIE would be impossible if it had to replicate all of XS. We don't now half of how things are used and a lot of it simply doesn't make sense in the new module. Part of the point of Module::Build is to correct the historical design mistakes of MM's interface. Module::Build's Makefile.PL emulation handles most of the commonly used MakeMaker options and that's good enough for most uses. If you've found an edge case that causes problems, patches welcome. > Now if a concerted effort was made to ensure that Module::Build easily > installed everywhere (as seen with the prerequisites and Win32 build failure > it does not) and that _every_ distribution produced by Module::Build was > installable via CPAN.pm then I would feel much more confident about its > future. M::B is planned to go into 5.10, that's as fast as we can push it. Both from new Perl core module inclusion perspective and giving time for M::B to mature. Meanwhile, its installable seperately, backwards compatible and much, much more easily maintained across platforms than MakeMaker. Hell, it even works on MacPerl. If its got a glitch on Win32 then it just needs a little work. Perhaps from a Win32 developer that's interested in Module::Build. If only we knew one... ;) As for CPAN.pm, petition Andreas to include Dave's Build.PL patch. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ WOOHOO! I'm going to Disneyland! http://www.goats.com/archive/980805.html |
|
From: Ken W. <ke...@ma...> - 2003-11-28 22:04:07
|
On Thursday, November 20, 2003, at 07:00 AM, Orton, Yves wrote: > Frankly until Module::Build works seamlessly by default with plain old > CPAN > I would advance the opinion that it will never replace MakeMaker, and > potentially in the long run leave the community divided, with those of > us > who can using Module::Build and those of us who cant or need to ensure > backwards compatibility not. I personally dont think that the > balkanization > of CPAN is a fair price for the changes that Module::Build brings. Well, consider that Module::Build has become backward-compatible into areas that MakeMaker has never been able to penetrate at all. MacPerl on Mac OS (not OS X), for example. And because it doesn't have to know obscure facts about operating systems that its authors don't even have access to, a single version of Module::Build can work on perls from 5.005 up to 5.8.2. > > Now if a concerted effort was made to ensure that Module::Build easily > installed everywhere (as seen with the prerequisites and Win32 build > failure > it does not) and that _every_ distribution produced by Module::Build > was > installable via CPAN.pm then I would feel much more confident about its > future. The former is a good goal. As for the latter, that's really up to the author of the distributions, they get to decide how their distributions should be installed. I agree that Module::Build should try to help as much as it can, though. -Ken |
|
From: Orton, Y. <yve...@de...> - 2003-11-20 16:36:09
|
> On Thu, 20 Nov 2003, Orton, Yves wrote:
>
> > Well, I find it odd that it works the way it does. CPAN expects a
> > Makefile.PL. If an author doesnt bother to have makefile.pl created (my
> > understanding is that this is not default, I await correction) then the
> > module is not auto installable by a large cross section of the deployed
> > Perls out there. This is an odd decision about a system intended to
replace
> > MakeMaker IMO. Build.PL should disappear and be replaced entirely by
> > Makefile.pl.
>
> I wrote a patch for CPAN.pm to add support for Module::Build.
Thats great. Did it get applied? Even if it did it still wont help those
that cannot upgrade their CPAN or install modules will it?
> To address your complain that Build.PL should be called
> Makefile.PL, if this were to happen, you'd then complain
> that Module::Build doesn't accept all the same options
> as EU::MM.
Thats a little presumptious actually. First off im not complaining. I'm
making observations that are grounded in my own experience and what Ive
heard from others. Second I would say that if Module::Build received an
option it couldnt handle then failing gracefully is better than outright
incompatibility.
To my mind having Module::Build work correctly with the 80%+ installations
out there (yeah yeah, lies, damned lies and statistics) and causing problems
for the remaining 20% is far superior result than having it only work with
less than 1% of the installations out there.
> This is intentional, because many of the EU::MM options are implemented
> in a rather crufty way. A good example is PREFIX. Trying to duplicate
> this logic really isn't worth it, so Ken chose a much simpler way of
> doing local installs.
I know this decision was intentional. I also consider it to be foolish.
Sorry, I know thats harsh but there you go.
Lets consider the situation as we have it from the POV of a CPAN.pm user
without your patches (like me and the vast majority of production perl
instances out there).
1. CPAN downloads the dist unpacks it and either
A. Finds no Makefile.PL, and crashes directly.
B. Finds a Makefile.PL which is simply a passthrough to Module::Build and
Build.PL.
i) CPAN passes special options to the Makefile.PL
ii) where Module::Build either ignores them or dies with an error.
In what way is the superior to
1. CPAN downloads the dist, unpacks it and
2. Runs Makefile.PL with some set of special options
3. Makefile.PL uses Module::Build and either ignores them or dies with an
error.
So by switching to Build.PL we dont actually gain anything but complexity
and balkanization.
Its a bad call, and when things start getting closer 5.10 I think this
subject will heat up quite a bit.
Regards,
Yves
I feel obliged to repeat what I said earlier. I think the Module::Build
project and the CPANPLUS project are Good Things. I think that some of the
implementation decisions are not such Good Things, and I worry that the
impact of them over the long haul will be negative for both CPAN and for
Module::Build. Only time will tell if im right.
|
|
From: Chris R. <ch...@dy...> - 2003-11-20 18:08:59
|
On Thu, 20 Nov 2003, Orton, Yves wrote: > Thats great. Did it get applied? Even if it did it still wont help those > that cannot upgrade their CPAN or install modules will it? If you can't install a new version of CPAN.pm, how can you install other modules? You're either maintaining your own person perl lib, or installing modules for the entire system. Might I say that you seem awfully convinced that the sky is falling with this issue. Module::Build works pretty well. That's my opinion, and the opinion of a lot of people that are smarter than me. There are a few rough edges with regards to compatibility with MakeMaker, but they aren't as bad as you make them to be. Regards. -- Chris Reinhardt -- ch...@dy... -- http://www.dyndns.org/ I have hardly ever known a mathematician who was capable of reasoning. --Plato |
|
From: Ron S. <ro...@de...> - 2003-11-23 23:17:54
|
Hi Folks > So by switching to Build.PL we dont actually gain anything but > complexity and balkanization. Also, I hope no-one's lost sight of the fact that some of us use home-grown CGI scripts to install modules, and don't want manually intervention during the installation process. I mention this just in case it happens to be relevant. > I feel obliged to repeat what I said earlier. I think the > Module::Build project and the CPANPLUS project are Good Things. I > think that some of the implementation decisions are not such Good > Things, and I worry that the impact of them over the long haul will > be negative for both CPAN and for Module::Build. Only time will > tell if im right. I second that. -- Ron Savage, ro...@de... on 24/11/2003. Room EF 312 Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia Phone: +61-3-9251 7067, Fax: +61-3-9251 7604 http://www.deakin.edu.au/~rons |
|
From: Ken W. <ke...@ma...> - 2003-11-28 20:59:23
|
Hi Ron, Whose message are you quoting here? I don't see it in my mailbox, so I can't tell what the actual issues are that somebody's complaining about. -Ken On Sunday, November 23, 2003, at 05:17 PM, Ron Savage wrote: > Hi Folks > >> So by switching to Build.PL we dont actually gain anything but >> complexity and balkanization. > > Also, I hope no-one's lost sight of the fact that some of us use > home-grown CGI scripts to install modules, and don't want manually > intervention during the installation process. I mention this just in > case it happens to be relevant. > >> I feel obliged to repeat what I said earlier. I think the >> Module::Build project and the CPANPLUS project are Good Things. I >> think that some of the implementation decisions are not such Good >> Things, and I worry that the impact of them over the long haul will >> be negative for both CPAN and for Module::Build. Only time will >> tell if im right. > > I second that. |
|
From: Randy W. S. <Ra...@Th...> - 2003-11-28 21:30:21
|
Ken Williams wrote: > Hi Ron, > > Whose message are you quoting here? I don't see it in my mailbox, so > I can't tell what the actual issues are that somebody's complaining > about. > > -Ken This thread began on the module-authors list as did the thread "How to indicate a dependency in my module". > > On Sunday, November 23, 2003, at 05:17 PM, Ron Savage wrote: > >> Hi Folks >> >>> So by switching to Build.PL we dont actually gain anything but >>> complexity and balkanization. >> >> >> Also, I hope no-one's lost sight of the fact that some of us use >> home-grown CGI scripts to install modules, and don't want manually >> intervention during the installation process. I mention this just in >> case it happens to be relevant. >> >>> I feel obliged to repeat what I said earlier. I think the >>> Module::Build project and the CPANPLUS project are Good Things. I >>> think that some of the implementation decisions are not such Good >>> Things, and I worry that the impact of them over the long haul will >>> be negative for both CPAN and for Module::Build. Only time will >>> tell if im right. >> >> >> I second that. > |
|
From: Michael G S. <sc...@po...> - 2003-11-24 02:48:04
|
On Thu, Nov 20, 2003 at 04:34:42PM -0000, Orton, Yves wrote: > Lets consider the situation as we have it from the POV of a CPAN.pm user > without your patches (like me and the vast majority of production perl > instances out there). > > 1. CPAN downloads the dist unpacks it and either > A. Finds no Makefile.PL, and crashes directly. > B. Finds a Makefile.PL which is simply a passthrough to Module::Build and > Build.PL. > i) CPAN passes special options to the Makefile.PL > ii) where Module::Build either ignores them or dies with an error. Ah HA! I see the problem. M::B's Makefile.PL *does* honor a healthy chunk of Makefile.PL options. Including PREFIX. It might behave a little differently, but that's the best that can be done without someone doing a lot of work to emulate MM's fairly crazy prefixification logic. [/usr/local/src/CPAN/Module-Build-0.21] perl Makefile.PL PREFIX=~ perl Build.PL config=prefix=/Users/schwern Checking whether your kit is complete... Looks good Creating new 'Build' script for 'Module-Build' version '0.21' > In what way is the superior to > > 1. CPAN downloads the dist, unpacks it and > 2. Runs Makefile.PL with some set of special options > 3. Makefile.PL uses Module::Build and either ignores them or dies with an > error. This is exactly what it does. If that's not working for you I guess its just a bug. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ It's Airplane Glue sniffing time! |
Thanks for helping keep SourceForge clean.
X