Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 17, 2006, at 8:01 AM, Nicholas Clark wrote: It won't hurt them, but it will cause immense pain for anyone wanting to ship a module that uses a Build.PL - those developers will be forced to decide whether to cut out anyone with an old Module::Build, or code their Build.PL to use that version and work around the deficiencies. Those authors should just be able to put a 'build_requires' dependency on the right version of Module::Build. The thread on what YAML version Module::Build needs, and how to upgrade correctly if there isn't =0.50 suggests that solving these Module::Build needs upgrading issues isn't yet battle tested. That's a different issue - the problem there is how to handle increases in 'feature' requirements, e.g. the 'yaml_support' feature for M::B. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Sun, Feb 19, 2006 at 05:00:40PM +1100, Adam Kennedy wrote: I missed that thread. What was the subject? Module::Build doesn't need YAML at all (though authors really should have it to generate a fleshed-out META.yml). And the current development version should work fine with current versions of YAML. I don't think anybody is suggesting putting 0.2611 in the core, and I for one wouldn't mind seeing the battle-testing that would result from putting 0.27_* in the core happen before 0.28 is released. I'd really really really like to have a while to hammer on 0.28, since it's been 8 months since the last Module::Build release, and what exists now is surely better than what I have to play with now. Developer releases are only useful to a point. Andreas has 345 Perl installations on his server, and I'm starting to assemble my every production Perl on every production platform matrix based on his work. And I'd class that as appropriate _training_ for battle conditions, which would throw up even more stuff. And if we can clear Module::Build on 400-500 installations of Perl, I'd feel much more comfortable about seeing it head towards the core. Sigh. It's a perl-only module; putting it in is not going to break any builds, at worst it will fail its tests. And if it is going to fail tests on platform Foo, we want to know that as soon as possible, so that's a good thing. I greatly appreciate it that you want to test it on so many perls, but that's not a substitute for the variety of platforms doing smoke tests or other periodic testing of the core. It scares me that modules like version are switching to Module::Build and we don't have any sense for how many platforms it just plain doesn't work on. The sooner it's in the core, the better.
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Fri, Feb 17, 2006 at 02:01:30PM +, Nicholas Clark wrote: On Thu, Feb 16, 2006 at 07:26:47PM -0800, Yitzchak Scott-Thoennes wrote: On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: On the other hand, if we begin to ship M::B with stable perls, a lot of people will keep perl's M::B and not upgrade it. So we'd better be sure it's pretty stable in terms of functionality and API. So I agree with you here. Um. Those same people aren't likely to install M::B in the first place. I don't see how providing them with it (even if it will fall out of date) hurts. It won't hurt them, but it will cause immense pain for anyone wanting to ship a module that uses a Build.PL - those developers will be forced to decide whether to cut out anyone with an old Module::Build, or code their Build.PL to use that version and work around the deficiencies. I don't see the mountain, just a molehill. But maybe that's just me. For (wild speculation in absense of data) 99% of modules, Module::Build is feature-complete. The remaining 1% of modules (e.g. Tk) won't be switching to it any time soon, and when they do, they'll require version 0.30 or the like. The thread on what YAML version Module::Build needs, and how to upgrade correctly if there isn't =0.50 suggests that solving these Module::Build needs upgrading issues isn't yet battle tested. I missed that thread. What was the subject? Module::Build doesn't need YAML at all (though authors really should have it to generate a fleshed-out META.yml). And the current development version should work fine with current versions of YAML. I don't think anybody is suggesting putting 0.2611 in the core, and I for one wouldn't mind seeing the battle-testing that would result from putting 0.27_* in the core happen before 0.28 is released. This is fine for 5.9 (anyone using 5.9 should be expecting surprises, including unannounced binary compatibility breakages across any patch) but not for stable, be it 5.8.x or 5.10.1. There is time before 5.10 to solve this. [But hopefully not loads of time :-)] With respect to stability, I hope functionality continues to increase, and that backwards-incompatible changes will be severely limited. I don't see how this is different from any other module already in the core. However, I hope you are only applying this reasoning to 5.8.x. My That's why it's not suitable for stable now, independent of any policy on assimilation. Disagreeing with the premise (assuming I've correctly identified your That), I disagree with your conclusion too. Oh well.
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Adam Kennedy wrote: Adding additional work for every single Perl application because $you can't create a system which behaves like everybody else is expected to. All of *my* CPAN releases contain a compatibility Makefile.PL which _will_ install Module::Build if it isn't already present; I don't have any bootstrap problems. I still don't think a Makefile.PL _has_ to be mandatory, though I wouldn't object if M::B would whine if one wasn't present, because I agree that it is a good idea. On the other hand, I don't see Module::Install as being nearly ready for prime time, at least partly due to lacking documentation (which I know you are focusing on). Try not to let your legitimate advocacy of a module you like blind you to the reality that there are people who like M::B despite its limitations and who will not switch, no matter how much you complain until you can provide a clearly superior product. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
demerphq wrote: cherry picking through your message There is no excuse for a module built with MB going on CPAN without a Makefile.PL. I agree 100%. I'm using using Module::Starter::PBP and (more importantly) Module::Release, so I don't have an option. But before we continue down the road of FUD, can anyone provide a list of how many CPAN distros _don't_ contain a Makefile.PL??? MB should provide one automagically if the user hasnt requested it. Here, we disagree. It is the *authors's* responsibility to ensure that any CPAN release gets tested in a wide variety of environments, including bootstrapping with backrev'd tools. If no one else does, I'll even provide a patch to M::B that will force a module author to hit Y when running './Build dist' if there isn't a Makafile.PL present, but I'm opposed to creating a file without asking. There are simply too many variables involved for M::B to make a sane choice. But if it isnt there then the build is going to fail almost EVERYWHERE. And thats bad. Much much much worse than providing a Makefile.PL that will never be used. If by EVERYWHERE you mean Win32, then I hate to break it to you but lots of stuff doesn't work with Win32. As much as they try, ActiveState's PPM has huge holes because it is very hard to get Win32 installs working right (plus I have to strongly disagree with their notion of we don't ship a newer version of Module::XX in our product, so our PPM machines cannot be upgraded either). If by EVERYWHERE you mean people running Perl 5.005_03 with the CPAN distro to match, you aren't going to get a lot of sympathy around here, certainly. Big modules on CPAN have README files which are supposed to help users perform their install. The very first paragraph of that README should suggest upgrading the couple of dual-lived core modules that have been upgraded since 8088's were the common desktop choice. It's simply good practice to sharpen your tools before cutting (you are much less likely to draw blood). I am both an author and a user of CPAN. I've installed RT. More than once. Successfully. I've installed VCP. More than once. With very little loss of blood. I'm also a happy user of Module::Build and CPANPLUS, because they are superior to what is shipped in the core. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Wed, Feb 15, 2006 at 12:07:02PM +0100, Rafael Garcia-Suarez wrote: On 2/15/06, Adam Kennedy [EMAIL PROTECTED] wrote: But MB is going to go core real soon now though right? 5.8.9? It's planned for the next 5.9, but I doubt new modules will go in the maintainance track. (But I'm no authority on maint:) Well, I was assuming that it would be in current stable when current stable is 5.10 :-) (ie no, not 5.8.x, for the reasons below) On Thu, Feb 16, 2006 at 07:26:47PM -0800, Yitzchak Scott-Thoennes wrote: On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: On the other hand, if we begin to ship M::B with stable perls, a lot of people will keep perl's M::B and not upgrade it. So we'd better be sure it's pretty stable in terms of functionality and API. So I agree with you here. Um. Those same people aren't likely to install M::B in the first place. I don't see how providing them with it (even if it will fall out of date) hurts. It won't hurt them, but it will cause immense pain for anyone wanting to ship a module that uses a Build.PL - those developers will be forced to decide whether to cut out anyone with an old Module::Build, or code their Build.PL to use that version and work around the deficiencies. The thread on what YAML version Module::Build needs, and how to upgrade correctly if there isn't =0.50 suggests that solving these Module::Build needs upgrading issues isn't yet battle tested. This is fine for 5.9 (anyone using 5.9 should be expecting surprises, including unannounced binary compatibility breakages across any patch) but not for stable, be it 5.8.x or 5.10.1. There is time before 5.10 to solve this. [But hopefully not loads of time :-)] With respect to stability, I hope functionality continues to increase, and that backwards-incompatible changes will be severely limited. I don't see how this is different from any other module already in the core. However, I hope you are only applying this reasoning to 5.8.x. My That's why it's not suitable for stable now, independent of any policy on assimilation. Nicholas Clark
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 8:44 AM, John Peacock wrote: demerphq wrote: cherry picking through your message There is no excuse for a module built with MB going on CPAN without a Makefile.PL. I agree 100%. I'm using using Module::Starter::PBP and (more importantly) Module::Release, so I don't have an option. I actually have a custom version of Module::Release that understands M::B and does a few more things to make my life easier (like looking up my CPAN password in my OS X keychain), but my several attempts at getting patches accepted for it have gone unresponded-to, so I've given up on getting it integrated. I'll mail it to you if you want, though. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On 2/16/06, Ken Williams [EMAIL PROTECTED] wrote: On Feb 15, 2006, at 8:19 PM, Adam Kennedy wrote: But now I'm just getting annoyed and I doubt I can contribute any further to this conversation without repeating myself or resorting to outright flaming, so I'll step out here. Why do you think these threads keep happening on lists that AREN'T M::B's list? It's very frustrating for me. If there are problems we can solve in M::B, please bring them to our attention. The reasons these discussions happen in other venues besides the MB lists is because the MB lists are moderated and sometimes a post doesnt hit the list for days after it was posted and then isnt responded to for some time. Also, I think that expecting every critical thought about MB to be sent to the lists is unrealistic. People have posted lots of discussion on Perlmonks for instance, but ive rarely/never seen you comment. Is it so hard to pop by a site where your users congregate and see what they are saying about your stuff? I mean we aren't talking about some obscure site with 7 users, we are talking about one of the flagship perl help sites. As an example I stopped hanging out in clpm because I found perlmonks, but i still do the occasional search to see whether any of my modules are being discussed. Not only that but when legitimate concerns have been raised the response has been less than positive. For instance the subject matter of this thread (CPAN distros without Makefile.PL's) has been raised time and time again. With almost every time the exact same message. And we still don't see that Makefile.PL being made mandatory. (And judging from your comments in this thread it seems we shouldnt expect to either.) How long did it take to come up with a patch to make Cwd install ok on Win32? A long time and in the end I wrote it. As soon as you realized that MB couldnt install CWD on win32 you should have a) ditched MB for that project until it worked everywhere, b) fixed MB. I mean seriously, if the author of a project like MB can't get it to work properly on his flagship core distro and leaves it as such doesnt it strike you as a pretty serious issue? Yet you havent released an update to MB in a while because it breaks some feature of CPANPLUS? (With an installed user base a mere fraction that of CPAN?) I think you need to reconsider some of your positions. Making MB built modules work as often as possible is much much more important than adding new features whose appeal is restricted to module authors. Making MB built stuff work on both of the popular OS'es (Linux and Win32) is more important than making it easy for an author to pick which license they are releasing their module. Making feedback as easy and painless as possible is more important than having a spam free mailing list. Monitoring how your module is impacting the marketplace is important, you cant just expect every comment to be emailed directly to you. And telling people that MB is great because its easy to extend while ignoring the fact that most peoples first interaction with MB will be when it fails to work is just counterproductive. Frankly getting your product out the door more often with less changes per release would help. Its time to stop caring about the 10%ers and start worrying about the 90%ers. If you can get an MB out the door that has features and bug fixes that appeal to 90% of your user base then forget about the stuff that you havent got working that only appeals to 10%. The 10% will get over it and probably help you do the work anyway, and the 90% are going to be able to yell a lot louder and in a lot more places than you can respond to. IMO, the MB PR has been awful. Time to fix that. There is no excuse for a module built with MB going on CPAN without a Makefile.PL. MB should provide one automagically if the user hasnt requested it. If people dont need the Makefile.PL then they can ignore it just fine. Its only a few hundred bytes. But if it isnt there then the build is going to fail almost EVERYWHERE. And thats bad. Much much much worse than providing a Makefile.PL that will never be used. And BTW, before anybody tries to skewer me for saying this stuff, consider that I have filed bug reports and patches. Ive gone from just bitching about MB to trying to be constructive and helpful about it. MB is a good project that has gotten a bad name for decisions that were no doubt made with good intent but that have backfired. Its time to start taking these kinds of comments seriously and change the public perception of MB. And respond to the issues raised. I like to add a last point: I realize that you are a volunteer and that you have a life besides Perl. But you have placed yourself as the lynchpin of a number of core functions. If you dont have the time to keep up with that then you need to change your development practices and start distributing your responsibilites. Im not saying you should do this, im just saying that a lack of
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On 2/16/06, demerphq [EMAIL PROTECTED] wrote: ps: I'll go out on a limb here and say that MB should NOT be made core until it makes Makefile.PL production mandatory. And until it can My opinion : the functionality that's interesting to add in the core is to be able to run Build.PL, not to produce distros. On the other hand, if we begin to ship M::B with stable perls, a lot of people will keep perl's M::B and not upgrade it. So we'd better be sure it's pretty stable in terms of functionality and API. So I agree with you here. install all of the core modules that are built with it on all of the main OS'es that use it. Actually id go even further and say that no core distro should use MB until that distro can be installed on all the main OS'es. I agree for XS core modules; pure-perl core modules just don't use any makefile during perl's compilation process, so it's less important. But it might be important that people can upgrade core modules without installing non-core modules. (That won't be always the case, since sometimes new dependencies appear.)
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 3:34 AM, demerphq wrote: The reasons these discussions happen in other venues besides the MB lists is because the MB lists are moderated and sometimes a post doesnt hit the list for days after it was posted and then isnt responded to for some time. Also, I think that expecting every critical thought about MB to be sent to the lists is unrealistic. People have posted lots of discussion on Perlmonks for instance, but ive rarely/never seen you comment. That's true. I don't typically have time to scan perlmonks. Perlmonks is a great site, but for getting things changed in a module or asking questions about rationale, nothing beats contacting the module's authors and/or posting to its mailing list. Is it so hard to pop by a site where your users congregate and see what they are saying about your stuff? Yes. Not only that but when legitimate concerns have been raised the response has been less than positive. For instance the subject matter of this thread (CPAN distros without Makefile.PL's) has been raised time and time again. With almost every time the exact same message. And we still don't see that Makefile.PL being made mandatory. (And judging from your comments in this thread it seems we shouldnt expect to either.) As I understand it, the reasoning is basically there are non-compliant distros on CPAN - so we must MAKE them comply! I'm sorry, but I just disagree. I believe we should *help* them comply. How long did it take to come up with a patch to make Cwd install ok on Win32? A long time and in the end I wrote it. As soon as you realized that MB couldnt install CWD on win32 you should have a) ditched MB for that project until it worked everywhere, b) fixed MB. I mean seriously, if the author of a project like MB can't get it to work properly on his flagship core distro and leaves it as such doesnt it strike you as a pretty serious issue? You want the PathTools distro? You can have it. I only took it because nobody else would. It's a horrible legacy mess and political mess and I would be glad to be rid of it. Why didn't I make Cwd install ok on Win32 sooner? Because I don't have an appropriate Win32 machine to test on, I don't understand ANY of the issues that were going on in that bug, and I don't own the code (ExtUtils::Install) that was determined to need the patching. But you know all this, so why are you flaming me about it? BTW, i really hope that this isnt perceived as a flame. Thats not whats its intended to do. Its intended to be thoughtful and constructive critcism with the aim of improving the standing of MB in the community. I hope it acheives its goal. Not really, it still felt like a flame to me. But whatever, I can ignore the tone and try to just see the points. ps: I'll go out on a limb here and say that MB should NOT be made core until it makes Makefile.PL production mandatory. And until it can install all of the core modules that are built with it on all of the main OS'es that use it. Actually id go even further and say that no core distro should use MB until that distro can be installed on all the main OS'es. You mean no core distro should use *just* M::B, right? I see no harm in having both a traditional Makefile.PL and a Build.PL to give users the choice, do you? In any case, on this Makefile.PL issue: I'm willing to put in an admonition to authors and a y/n button when they try to make a distribution without a Makefile.PL. I think at least 90% of those cases are probably just accidents. But I'm not willing to *force* the author to include a Makefile.PL, whatever force would mean here. Given that, which is on the surface in conflict with your other desire to get 0.28 released ASAP, would you vote for a) getting this into 0.28, or b) waiting until afterwards? -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 1:16 PM, Tyler MacDonald wrote: Ken Williams [EMAIL PROTECTED] wrote: If we did that, we'd screw over people who are already maintaining their Makefile.PL separately by hand. OK... but if they are doing that, the Makefile.PL will be in their *build* directory already... as far as I understand, our Makefile.PL only needs to be generated in the *dist* directory. Yeah, that's true. Let me reconsider my reasoning here from scratch. The original point that Adam Yves were making, IIUIC, was that distributions should include a Makefile.PL. If they don't have one at all, then of course we don't need to worry about clobbering one! So I'd be fine with changing the default in this case to provide some flavor of Makefile.PL generated in the dist directory. The main question would be what style to make it. 'traditional' is accessible by more people, but will often be broken (if, e.g., there are config questions or auto-sensing in the Build.PL they'll be lost to the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' for this case. That should make most people happy, no? -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Ken Williams [EMAIL PROTECTED] wrote: *build* directory already... as far as I understand, our Makefile.PL only needs to be generated in the *dist* directory. Yeah, that's true. Let me reconsider my reasoning here from scratch. The original point that Adam Yves were making, IIUIC, was that distributions should include a Makefile.PL. If they don't have one at all, then of course we don't need to worry about clobbering one! So I'd be fine with changing the default in this case to provide some flavor of Makefile.PL generated in the dist directory. The main question would be what style to make it. 'traditional' is accessible by more people, but will often be broken (if, e.g., there are config questions or auto-sensing in the Build.PL they'll be lost to the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' for this case. I think passthrough is the way to go here. I also still think that if we default in some way to generating a Makefile.PL, create_makefile_pl should be extended to have an explicit skip option as well. That should make most people happy, no? Sounds good to me. :-) - Tyler
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 11:45 AM, Tyler MacDonald wrote: I think passthrough is the way to go here. I also still think that if we default in some way to generating a Makefile.PL, create_makefile_pl should be extended to have an explicit skip option as well. Definitely. I'd just change the default to 'auto' (which means create a 'small' [or 'passthrough'] Makefile.PL if none already exists) though, and then the author can explicitly put create_makefile_pl = 0 (or any other false value) in their Build.PL to shut it off. If in the future we figure out how to auto-sense when we could create a 'traditional' Makefile.PL that would be cool, but I don't really see it happening. Too hard. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
demerphq wrote: My understanding of this (and i hope im not putting words in Adams mouth) is that anybody using an old CPAN can't install a distribution that requires Module::Build unless a Makefile.PL is present. Since this is a big chunk of the cpan's out there it affects a lot of users, and in my experience is one of the reasons that people often get a bad impression of MB on their first exposure as there is a good chance that the first time they notice something uses MB will be when CPAN fails to install because of the missing Makefile.pl Let's be clear about the scope of responsibilities here. Every time you start an install using a backrev'd CPAN, you are given instructions for updating CPAN itself. The current CPAN handles MB just fine, thanks, so the core problem is sysadmins who refuse to upgrade their basic tools. If this reflects badly on M::B it is due to sloth and inertia, and that isn't something that adding a Makefile.PL is going to automatically fix. Of course, there is also the far superior CPANPLUS, which deals with M::B even better... IOW, no dist should ever be released to CPAN without a Makefile.PL and MB should not allow anyone to create such a dist. There is no need to make the Makefile.PL do any more than signal that MB needs to be installed and then hand over to it to do the dirty work. Such an implementation should work transparently on every CPAN ever released. And who acts as gatekeeper? PAUSE? Module::Build itself??? This goes completely against the nature of CPAN, which is to accept all sorts of crap, with the good stuff eventually floating to the top (by being on a 'use' line in every other module). I would certainly accept a mandatory warning during './Build dist' if there was no Makefile.PL present, but I think that assuming that everyone wants to release to CPAN is grossly inappropriate. I personally have released modules to CPAN lacking a Makefile.PL, but mostly because I forgot to add one (and since I now try to use Module::Starter::PBP, that isn't going to happen again). I strongly support any author who wants to include only a Build.PL because they don't care if people who refuse to upgrade their core modules get burned. ;-) John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
John Peacock [EMAIL PROTECTED] wrote:
if ($mb-overwrite_makefile() -f $Makefile ) {
my $answer = $mb-y_n(Found an existing Makefile.PL; overwrite?);
if ($answer =~/y/i) {
write_makefile;
}
}
where overwrite_makefile is a package option passed to M::B::new(). I
did it this way so that
a) the developer has to affirmatively choose that option;
b) the developer has to _always_ hit 'Y' when running './Build distdir',
just in case he/she did something manually and forgot to turn off the
option.
So that's in there now?
BTW.. tsk tsk... y_n requires a default now. ;-)
- Tyler
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 3:18 PM, John Peacock wrote:
Tyler MacDonald wrote:
Seriously though, it sounds like having at least a loud warning I
did not write this Makefile.PL, move it out of the way first is
worthwhile.
Pseudocode:
if ($mb-overwrite_makefile() -f $Makefile ) {
my $answer = $mb-y_n(Found an existing Makefile.PL;
overwrite?);
if ($answer =~/y/i) {
write_makefile;
}
}
where overwrite_makefile is a package option passed to M::B::new
(). I did it this way so that
a) the developer has to affirmatively choose that option;
b) the developer has to _always_ hit 'Y' when running './Build
distdir', just in case he/she did something manually and forgot to
turn off the option.
Ugh, I have to hit Y every time??? If you add the following to the
conditional, I'd be happy:
slurp($Makefile) !~ /auto.generated/is
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 2:40 PM, Tyler MacDonald wrote: Well it would only clobber the file if it contained the auto-generated line, so I think that's safe, but if you want to be *really* paranoid, how about having the dist actions fail if you havent specified a create_makfile_pl arg? (one of the exsitng ones or skip). I just tested and CVS HEAD M::B happily overwrote a hand-made Makefile.PL when I added 'traditional' to Build.PL and ran Build distdir. Luckily, I had it in SVN so it was an easy restore. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 2:05 PM, Chris Dolan wrote: Attached below is a regexp-based solution that matches simple Build.PL files. I submit this just for thought, not necessarily for inclusion in M::B. Cool. I wonder if Randy Sims (when he gets back from vacation) could run this against his mini-cpan area to get some statistics on the broader CPAN. Or anyone else, if they're so inclined, certainly. Perhaps this mode could be triggered by Ccreate_makefile_pl = 'automatic' Yeah. As long as we're very strict in how we parse, i.e. any syntax errors according to our grammar for simple Build.PL files are fatal, this does seem like a good way to do things. I would initially like to roll out the 'auto' default without any of this sensing on the Build.PL, but it's going to be good to have in our back pocket. Thanks. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On 2/16/06, Ken Williams [EMAIL PROTECTED] wrote: Let me reconsider my reasoning here from scratch. The original point that Adam Yves were making, IIUIC, was that distributions should include a Makefile.PL. If they don't have one at all, then of course we don't need to worry about clobbering one! So I'd be fine with changing the default in this case to provide some flavor of Makefile.PL generated in the dist directory. Yes that was my point. The main question would be what style to make it. 'traditional' is accessible by more people, but will often be broken (if, e.g., there are config questions or auto-sensing in the Build.PL they'll be lost to the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' for this case. That should make most people happy, no? In general yes. But I think its worth considering that traditional is preferable. This http://perlmonks.org/index.pl?node_id=458282 argues that the traditional provides more flexibility for the end user. Cheers, yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 3:48 PM, demerphq wrote: In general yes. But I think its worth considering that traditional is preferable. This http://perlmonks.org/index.pl?node_id=458282 argues that the traditional provides more flexibility for the end user. Yes. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: On 2/16/06, demerphq [EMAIL PROTECTED] wrote: ps: I'll go out on a limb here and say that MB should NOT be made core until it makes Makefile.PL production mandatory. And until it can That doesn't make sense to me. Alerting module authors to missing Makefile.PLs is important only because of how many MB-less installations there are out there; adding MB to the core can only end up decreasing the number of such installations. My opinion : the functionality that's interesting to add in the core is to be able to run Build.PL, not to produce distros. Agreed, but there's little point in separating them. On the other hand, if we begin to ship M::B with stable perls, a lot of people will keep perl's M::B and not upgrade it. So we'd better be sure it's pretty stable in terms of functionality and API. So I agree with you here. Um. Those same people aren't likely to install M::B in the first place. I don't see how providing them with it (even if it will fall out of date) hurts. With respect to stability, I hope functionality continues to increase, and that backwards-incompatible changes will be severely limited. I don't see how this is different from any other module already in the core. However, I hope you are only applying this reasoning to 5.8.x. My main reason for wanting M::B in the core for 5.9.x as soon as possible is to increase the number of people forced to test it and help get it working on non-major platforms.
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On 2/15/06, Andreas J. Koenig [EMAIL PROTECTED] wrote: On Wed, 15 Feb 2006 13:29:34 +1100, Adam Kennedy [EMAIL PROTECTED] said: I think I'm coming into this discussion late. =( What do you mean by doesn't bootstrap? M::B does indeed use itself to install itself, so you must have something else in mind. Could you elaborate briefly to bring me up to date on this discussion? Sure thing. Module::Build is not (yet) a core module. Thus, any CPAN distribution (other than MB itself with your extra magic of course) that has ONLY got a Build.PL has an undeclared non-core dependency, which will cause Build.PL to crash with an error. CPAN.pm in particular, the CPAN client we ship in the core, does not install Module::Build either, even when upgraded to the current version. So as a result, any MB-using dist cannot be installed on any current production Perl. Installation requires an undocumented (to the installer) undeclared non-core module MB to be hand-installed because any of these dists will work. CPAN.pm 1.83_56 introduced a protection against this sometimes missing prerequisite declaration. 1.84 is really close to a release, so this gap is closed then. Ive always had problems doing an upgrade using Bundle::CPAN on win32 and eventually stopped bothering. However i just took a moment to try. Unfortunately it still chokes. :( I say this here because I believe it is relevent. Win32 users almost definately wont bother with Bundle::CPAN as they most likely have the same experience that i have had, that its too much trouble to bother. Although this latest error is different from earlier ones that I recall where the failures were down to hard to install (on win32) XS modules failing. D:\ cpan Terminal does not support AddHistory. There seems to be running another CPAN process (pid 3024). Contacting... Other job not responding. Shall I overwrite the lockfile? (Y/N) [y] y cpan shell -- CPAN exploration and modules installation (v1.7601) ReadLine support available (try 'install Bundle::CPAN') cpan install Bundle::CPAN CPAN: Storable loaded ok Going to read D:\home\.cpan5.8.x\Metadata Database was generated on Mon, 06 Feb 2006 02:17:31 GMT Subroutine new redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 34, FIN line 1. Subroutine _request_sanity_check redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 113, FIN line 1. Subroutine send_request redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 133, FIN line 1. Subroutine prepare_request redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 239, FIN line 1. Subroutine simple_request redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 268, FIN line 1. Subroutine request redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 277, FIN line 1. Subroutine get redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 415, FIN line 1. Subroutine post redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 423, FIN line 1. Subroutine head redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 431, FIN line 1. Subroutine _process_colonic_headers redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 439, FIN line 1. Subroutine is_protocol_supported redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 493, FIN line 1. Subroutine protocols_allowed redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 520, FIN line 1. Subroutine protocols_forbidden redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 521, FIN line 1. Subroutine requests_redirectable redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 522, FIN line 1. Subroutine redirect_ok redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 526, FIN line 1. Subroutine credentials redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 553, FIN line 1. Subroutine get_basic_credentials redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 561, FIN line 1. Subroutine agent redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 574, FIN line 1. Subroutine _agent redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 586, FIN line 1. Subroutine timeout redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 588, FIN line 1. Subroutine from redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 589, FIN line 1. Subroutine parse_head redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 590, FIN line 1. Subroutine max_size redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 591, FIN line 1. Subroutine max_redirect redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 592, FIN line 1. Subroutine cookie_jar redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 595, FIN line 1. Subroutine default_headers redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 609, FIN line 1. Subroutine default_header redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 618, FIN line 1. Subroutine conn_cache redefined at E:/Perl/811/site/lib/LWP\UserAgent.pm line 624, FIN line 1. Subroutine use_eval redefined at
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
I think I'm coming into this discussion late. =( What do you mean by doesn't bootstrap? M::B does indeed use itself to install itself, so you must have something else in mind. Could you elaborate briefly to bring me up to date on this discussion? Sure thing. Module::Build is not (yet) a core module. Thus, any CPAN distribution (other than MB itself with your extra magic of course) that has ONLY got a Build.PL has an undeclared non-core dependency, which will cause Build.PL to crash with an error. CPAN.pm in particular, the CPAN client we ship in the core, does not install Module::Build either, even when upgraded to the current version. So as a result, any MB-using dist cannot be installed on any current production Perl. Installation requires an undocumented (to the installer) undeclared non-core module MB to be hand-installed because any of these dists will work. This is what I mean by bootstrapping. The reason this is so bad is because of the most common failure modules. This is typically someone installing something like RT, which recurses downwards two or three times, hits the MB error 500 lines into the output, continues to install whatever else it can find recursing upwards, until it gets to the end. The error message failed to load Module::Build from which the user is supposed to realise they need to manually install Module::Build (or install directly via CPAN.pm) is buried somewhere 500 lines into a 1000 line long output. This is effectively impenetrable to anyone that isn't an author (and doesn't have this problem anyway). This is the problem that I'd like to see fixed. And while I'm trying very hard (I hope mostly successfully) to not say anything about MB's other properties (good or bad) other than this installation problem, let me add that just because some authors might like some feature of MB it doesn't mitigate the problem of (anything using) it not bootstrapping properly. Adam K At the very least the Makefile.pl could create a tiny makefile that then runs Build.pl and Build as needed. If someone can explain why this is impossible, then id like to hear it. We already do that, using the 'passthrough' or 'small' options for auto-creating a Makefile.PL. See the docs for Module::Build::Compat. Module::Build itself also ships with such a Makefile.PL so that automated tools like CPAN(PLUS) can install it. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On 2/15/06, Adam Kennedy [EMAIL PROTECTED] wrote: But MB is going to go core real soon now though right? 5.8.9? It's planned for the next 5.9, but I doubt new modules will go in the maintainance track. (But I'm no authority on maint:)
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
My understanding of this (and i hope im not putting words in Adams mouth) is that anybody using an old CPAN can't install a distribution that requires Module::Build unless a Makefile.PL is present. Since this is a big chunk of the cpan's out there it affects a lot of users, and in my experience is one of the reasons that people often get a bad impression of MB on their first exposure as there is a good chance that the first time they notice something uses MB will be when CPAN fails to install because of the missing Makefile.pl Those words are fine to be put in my mouth, it pretty much covers it. But I'll clarify old to include current. Because unless I missed it Module::Build isn't core yet, it's a seperate CPAN module. Hence why I said that it applies to any existing perl distribution. And I'm also absolutely cool with doing whatever people like with third party non-CPAN module, because $we never have to deal with them and will never see people adding deps on them. But MB is going to go core real soon now though right? 5.8.9? Adam K
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Wed, 15 Feb 2006 13:29:34 +1100, Adam Kennedy [EMAIL PROTECTED] said: I think I'm coming into this discussion late. =( What do you mean by doesn't bootstrap? M::B does indeed use itself to install itself, so you must have something else in mind. Could you elaborate briefly to bring me up to date on this discussion? Sure thing. Module::Build is not (yet) a core module. Thus, any CPAN distribution (other than MB itself with your extra magic of course) that has ONLY got a Build.PL has an undeclared non-core dependency, which will cause Build.PL to crash with an error. CPAN.pm in particular, the CPAN client we ship in the core, does not install Module::Build either, even when upgraded to the current version. So as a result, any MB-using dist cannot be installed on any current production Perl. Installation requires an undocumented (to the installer) undeclared non-core module MB to be hand-installed because any of these dists will work. CPAN.pm 1.83_56 introduced a protection against this sometimes missing prerequisite declaration. 1.84 is really close to a release, so this gap is closed then. -- andreas
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 3:06 PM, Tyler MacDonald wrote: Chris Dolan [EMAIL PROTECTED] wrote: Well it would only clobber the file if it contained the auto-generated line, so I think that's safe, but if you want to be *really* paranoid, how about having the dist actions fail if you havent specified a create_makfile_pl arg? (one of the exsitng ones or skip). I just tested and CVS HEAD M::B happily overwrote a hand-made Makefile.PL when I added 'traditional' to Build.PL and ran Build distdir. Luckily, I had it in SVN so it was an easy restore. But that's exactly what you asked it to do. ;-) Seriously though, it sounds like having at least a loud warning I did not write this Makefile.PL, move it out of the way first is worthwhile. - Tyler I understand that. I was simply saying that your assertion that it wouldn't clobber a file that lacked the auto-generated line was not the current reality. It was unclear to me from that message whether you were discussing actual behavior or ideal behavior, so I tested it myself. Sorry, I should have put a smiley after my SVN comment. :-D I like your proposed warning. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Andreas J. Koenig wrote: On Wed, 15 Feb 2006 13:29:34 +1100, Adam Kennedy [EMAIL PROTECTED] said: So as a result, any MB-using dist cannot be installed on any current production Perl. Installation requires an undocumented (to the installer) undeclared non-core module MB to be hand-installed because any of these dists will work. CPAN.pm 1.83_56 introduced a protection against this sometimes missing prerequisite declaration. 1.84 is really close to a release, so this gap is closed then. Actually, I was going to point out that I took one of the rare machines that I have access to that isn't infected with my entire toolchain and installed Bundle::CPAN. The very last thing it installed was Module::Build itself; I was trying to see how long the Bundle::CPAN that is distributed with CPAN has included M::B, but search.cpan.org is having some issues at the present time. :( John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Andreas J. Koenig wrote:
It entered 2005-12-19, short before 1.80_57. But note, that the
protection I was talking about is not the fact that M:B is in the
Bundle:CPAN. The protecion looks instead like so:
if (-f Build.PL ! -f Makefile.PL ! exists
$req-{Module::Build}) {
$CPAN::Frontend-mywarn( Warning: CPAN.pm discovered Module::Build as
.
undeclared prerequisite.\n.
Adding it now as a prerequisite.\n
);
But I guess my point was big projects like RT (which is the one that
Adam cited) should have a prominently displayed warning make sure your
CPAN[PLUS] is up to date before trying to install. Either updating
CPAN (or preferably Bundle::CPAN) should be the first order of business
and would prevent any bootstrap problems (unless you are stuck with
Win32, that is).
John
--
John Peacock
Director of Information Research and Technology
Rowman Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Wed, 15 Feb 2006 13:47:08 +0100, demerphq [EMAIL PROTECTED] said: The bundle file D:\home\.cpan5.8.x\Bundle\CPAN.pm may be a broken bundlefile. It seems not to contain any bundle definition. Please check the file and if it is bogus, please delete it. Sorry for the inconvenience. This has come up before. The explanation last time was that 1.76_01 had the bug and 1.84 doesn't have it. 1.76_01 installed the wrong CPAN.pm file a a bundle (239k; the actual CPAN.pm module!) If this is what's going on here, you'd remove the above mentioned Bundle\CPAN.pm file, then do an install CPAN and a reload cpan and then you should have success running the install Bundle::CPAN again. Something like this should definitely work. -- andreas
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Wed, 15 Feb 2006 07:36:17 -0500, John Peacock [EMAIL PROTECTED] said:
jp Andreas J. Koenig wrote:
On Wed, 15 Feb 2006 13:29:34 +1100, Adam Kennedy [EMAIL PROTECTED]
said:
So as a result, any MB-using dist cannot be installed on any current
production Perl. Installation requires an undocumented (to the
installer) undeclared non-core module MB to be hand-installed because
any of these dists will work.
CPAN.pm 1.83_56 introduced a protection against this sometimes missing
prerequisite declaration. 1.84 is really close to a release, so this
gap is closed then.
jp Actually, I was going to point out that I took one of the rare machines
that I
jp have access to that isn't infected with my entire toolchain and installed
jp Bundle::CPAN. The very last thing it installed was Module::Build itself;
I was
jp trying to see how long the Bundle::CPAN that is distributed with CPAN has
jp included M::B, but search.cpan.org is having some issues at the present
time. :(
It entered 2005-12-19, short before 1.80_57. But note, that the
protection I was talking about is not the fact that M:B is in the
Bundle:CPAN. The protecion looks instead like so:
if (-f Build.PL ! -f Makefile.PL ! exists
$req-{Module::Build}) {
$CPAN::Frontend-mywarn( Warning: CPAN.pm discovered Module::Build as
.
undeclared prerequisite.\n.
Adding it now as a prerequisite.\n
);
This code ensure that M:B gets installed right at the moment where it
is actually required.
--
andreas
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 15, 2006, at 8:19 PM, Adam Kennedy wrote: But now I'm just getting annoyed and I doubt I can contribute any further to this conversation without repeating myself or resorting to outright flaming, so I'll step out here. Why do you think these threads keep happening on lists that AREN'T M::B's list? It's very frustrating for me. If there are problems we can solve in M::B, please bring them to our attention. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 12:10 PM, John Peacock wrote: I would certainly accept a mandatory warning during './Build dist' if there was no Makefile.PL present, but I think that assuming that everyone wants to release to CPAN is grossly inappropriate. Yes, I was going to make that point too but I forgot. CPAN isn't the whole world. I personally have released modules to CPAN lacking a Makefile.PL, but mostly because I forgot to add one (and since I now try to use Module::Starter::PBP, that isn't going to happen again). I strongly support any author who wants to include only a Build.PL because they don't care if people who refuse to upgrade their core modules get burned. ;-) I agree on the personal rights aspect here. =) I'd still recommend that people include a Makefile.PL, but we can't force it. That would just mean people would have to find creative method to break the enforcement if they really know what they're doing. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On 2/14/06, Ken Williams [EMAIL PROTECTED] wrote: On Feb 14, 2006, at 5:43 AM, demerphq wrote: On 2/14/06, Adam Kennedy [EMAIL PROTECTED] wrote: Yitzchak Scott-Thoennes wrote: On Sun, Feb 12, 2006 at 09:26:06PM -0800, Randal L. Schwartz wrote: chromatic == chromatic [EMAIL PROTECTED] writes: chromatic On Sunday 12 February 2006 18:32, Randal L. Schwartz wrote: My prefer_installer is EUMM. And the value of mbuild_install_arg shouldn't matter, because it should always be using EUMM, not MB. chromatic That's going to be difficult for distributions that only provide a Build.PL chromatic file. I recognize that, but (a) those distros should not exist, so that's A couple of months ago I would have agreed. Now I'm not so sure. If you'd care to take time, I'd be interested in hearing your views on what level of MB support would be necessary before such distros should exist. For me it comes down to one simple structural problem (I consider things like PREFIX nigglies that can be fixed). Module::Build (specifically ONLY dists without a Makefile.PL) simply doesn't bootstrap. I think I'm coming into this discussion late. =( What do you mean by doesn't bootstrap? M::B does indeed use itself to install itself, so you must have something else in mind. Could you elaborate briefly to bring me up to date on this discussion? My understanding of this (and i hope im not putting words in Adams mouth) is that anybody using an old CPAN can't install a distribution that requires Module::Build unless a Makefile.PL is present. Since this is a big chunk of the cpan's out there it affects a lot of users, and in my experience is one of the reasons that people often get a bad impression of MB on their first exposure as there is a good chance that the first time they notice something uses MB will be when CPAN fails to install because of the missing Makefile.pl At the very least the Makefile.pl could create a tiny makefile that then runs Build.pl and Build as needed. If someone can explain why this is impossible, then id like to hear it. We already do that, using the 'passthrough' or 'small' options for auto-creating a Makefile.PL. See the docs for Module::Build::Compat. Module::Build itself also ships with such a Makefile.PL so that automated tools like CPAN(PLUS) can install it. The point is that if you can get a Makefile.PL based script that can get EUMM to produce a makefile that will then do the MB dance then there should NEVER be a module that omits the Makefile.pl, and the arguments that weve seen to date saying that there are circumstances where such is ok are actually wrong. IOW, no dist should ever be released to CPAN without a Makefile.PL and MB should not allow anyone to create such a dist. There is no need to make the Makefile.PL do any more than signal that MB needs to be installed and then hand over to it to do the dirty work. Such an implementation should work transparently on every CPAN ever released. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 12:36 PM, Tyler MacDonald wrote: Could create_makefile_pl = passthrough Become the default, and a new option, create_makefile_pl = skip be created to satisfy those who wish to screw over legacy users? :) If we did that, we'd screw over people who are already maintaining their Makefile.PL separately by hand. Not everybody has as many modules to maintain as we do, Tyler. =) -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 5:43 AM, demerphq wrote: On 2/14/06, Adam Kennedy [EMAIL PROTECTED] wrote: Yitzchak Scott-Thoennes wrote: On Sun, Feb 12, 2006 at 09:26:06PM -0800, Randal L. Schwartz wrote: chromatic == chromatic [EMAIL PROTECTED] writes: chromatic On Sunday 12 February 2006 18:32, Randal L. Schwartz wrote: My prefer_installer is EUMM. And the value of mbuild_install_arg shouldn't matter, because it should always be using EUMM, not MB. chromatic That's going to be difficult for distributions that only provide a Build.PL chromatic file. I recognize that, but (a) those distros should not exist, so that's A couple of months ago I would have agreed. Now I'm not so sure. If you'd care to take time, I'd be interested in hearing your views on what level of MB support would be necessary before such distros should exist. For me it comes down to one simple structural problem (I consider things like PREFIX nigglies that can be fixed). Module::Build (specifically ONLY dists without a Makefile.PL) simply doesn't bootstrap. I think I'm coming into this discussion late. =( What do you mean by doesn't bootstrap? M::B does indeed use itself to install itself, so you must have something else in mind. Could you elaborate briefly to bring me up to date on this discussion? At the very least the Makefile.pl could create a tiny makefile that then runs Build.pl and Build as needed. If someone can explain why this is impossible, then id like to hear it. We already do that, using the 'passthrough' or 'small' options for auto-creating a Makefile.PL. See the docs for Module::Build::Compat. Module::Build itself also ships with such a Makefile.PL so that automated tools like CPAN(PLUS) can install it. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Ken Williams [EMAIL PROTECTED] wrote: If we did that, we'd screw over people who are already maintaining their Makefile.PL separately by hand. OK... but if they are doing that, the Makefile.PL will be in their *build* directory already... as far as I understand, our Makefile.PL only needs to be generated in the *dist* directory. The current behaviour is to not create a Makefile.PL during ./Build, only create it when distdir is run. However, the distdir action creates Makefile.PL in the current directory and then copies it over. The generated Makefile.PL's first line clearly says auto-generated by Module::Build::Compat... s if somebody was maintaining a Makefile.PL manually, we could easily auto-detect that by checking for the presence of that line. Maybe echo a Big Fat Warning on the distdir action as well, if they havent explicitly set create_makefile_pl = skip. Do you think that would make everybody happy? Not everybody has as many modules to maintain as we do, Tyler. =) Hah, you're way ahead of me on that one. ;) What scares me is how many *nearly* complete modules i have sitting in my CVS tree that need just a few more changes to be ready... each night I load up one and add a few more methods/test cases/etc and think that's the night it's going to be ready to release just to find a whole days' worth of work I hadn't considered... - Tyler
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Chris Dolan [EMAIL PROTECTED] wrote: Well it would only clobber the file if it contained the auto-generated line, so I think that's safe, but if you want to be *really* paranoid, how about having the dist actions fail if you havent specified a create_makfile_pl arg? (one of the exsitng ones or skip). I just tested and CVS HEAD M::B happily overwrote a hand-made Makefile.PL when I added 'traditional' to Build.PL and ran Build distdir. Luckily, I had it in SVN so it was an easy restore. But that's exactly what you asked it to do. ;-) Seriously though, it sounds like having at least a loud warning I did not write this Makefile.PL, move it out of the way first is worthwhile. - Tyler I understand that. I was simply saying that your assertion that it wouldn't clobber a file that lacked the auto-generated line was not the current reality. It was unclear to me from that message whether you were discussing actual behavior or ideal behavior, so I tested it myself. Sorry, I should have put a smiley after my SVN comment. :-D Heh. This is all proposed behaviour. Everybody seems to agree the current behaviour isn't ideal, so before I write a patch (looks like John Peacock might have beat me too it anyway) I just wanted to be clear on the solution. Bitching about an existing Makefile.PL seems to be the lowest common denominator among all the ideas that have gone back and forth, so that should definately be implemented first. What's still in the air; - Whether or not we check for the auto-generated by MB::Compat line - Whether or not we add an explicit 'skip' argument to create_makefile_pl, which follows through to; - Whether or not we complain and/or fail to function if the module developer has not specified create_makefile_pl at all. Cheers, Tyler
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
Tyler MacDonald wrote: Ken Williams [EMAIL PROTECTED] wrote: If we did that, we'd screw over people who are already maintaining their Makefile.PL separately by hand. OK... but if they are doing that, the Makefile.PL will be in their *build* directory already... as far as I understand, our Makefile.PL only needs to be generated in the *dist* directory. The current behaviour is to not create a Makefile.PL during ./Build, only create it when distdir is run. However, the distdir action creates Makefile.PL in the current directory and then copies it over. It's not so simple a change. The Makefile.PL gets generated by distmeta, which distdir depends on. distmeta also generates README and META.yml. I tend to run distmeta before checking in a release, so I have exactly the Makefile.PL, README, and META.yml that get packaged up and uploaded to CPAN. I don't think anything that could clobber files should be switched on by default. That's just asking for trouble. Regards, David Golden
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
David Golden [EMAIL PROTECTED] wrote: It's not so simple a change. The Makefile.PL gets generated by distmeta, which distdir depends on. distmeta also generates README and META.yml. I tend to run distmeta before checking in a release, so I have exactly the Makefile.PL, README, and META.yml that get packaged up and uploaded to CPAN. I don't think anything that could clobber files should be switched on by default. That's just asking for trouble. Well it would only clobber the file if it contained the auto-generated line, so I think that's safe, but if you want to be *really* paranoid, how about having the dist actions fail if you havent specified a create_makfile_pl arg? (one of the exsitng ones or skip). That way CPAN etc would not be affected (since they don't run the 'dist' action), but module developers would be forced to specify the create_makefile_pl action before they uploaded a new release. I see maintaining both your own Build.PL and Makefile.PL as a bit of an edge case (not to mention a maintainer's nightmare), but there's gotta be a way we can both support it and make the default Module::Build behaviour friendly towards the CPAN.pm that's shipped with perl. - Tyler
