Thread: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: demerphq <dem...@gm...> - 2006-02-14 11:43:23
|
On 2/14/06, Adam Kennedy <cp...@al...> wrote: > Yitzchak Scott-Thoennes wrote: > > On Sun, Feb 12, 2006 at 09:26:06PM -0800, Randal L. Schwartz wrote: > >>>>>>> "chromatic" =3D=3D chromatic <chr...@wg...> 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 sh= ouldn't > >>>> matter, because it should always be using EUMM, not MB. > >> chromatic> That's going to be difficult for distributions that only pr= ovide 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. Nothing I'm going to say below has any applicability > if you do have a Makefile.PL. > > When every existing distribution in the CPAN is expected to install > without special instructions to the user, it's completely unfair to > expect that users should have to go do some additional work in order to > even _attempt_ to install a Build.PL-only module. > > Making MB core only partially fixes this, because we still have older > versions of Perl (by which I even mean < 5.8.8) that don't have MB by > default. > > If you can create a way to have a single standard Makefile.PL that > achieves a fix for the back-compatibility and bootstrapping problem, > then please at least make it the default. > > I don't see how we can have a Build.PL only distribution until 5 years > after MB goes core, unless you find a way to get past the bootstrapping > problem. Thank you. This one of the best and least vitriolic explanations of this issue ive seen. . I've never gotten my head around why it would ever make sense not to provide a 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. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: John P. <jpe...@ro...> - 2006-02-14 20:30:56
|
Nick Ing-Simmons wrote: > Chromatic <chr...@wg...> writes: >> M::B provides the minimal features to get the module built, tested, and >> installed. The bare tarball doesn't. No slope. > > I would like to switch to module build but AFAIK it still can't > do nested builds. That discussion is happening on the Module-Build list even now. The problem is that what "nested build" means is different for different people. Personally, I'd like blib/lib and blib/arch to contain all sub blib's below the current one (strictly speaking a recursive build). And at any level, a './Build command' will run all lower level ./Build files with the same command depth-first. Is this what EUMM does now? This seems to be what GNU automake/autoconf seems to expect. 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 |
|
From: Nick Ing-S. <ni...@in...> - 2006-02-16 18:27:11
|
John Peacock <jpe...@ro...> writes: >Nick Ing-Simmons wrote: >> Chromatic <chr...@wg...> writes: >>> M::B provides the minimal features to get the module built, tested, and= =20 >>> installed. The bare tarball doesn't. No slope. >>=20 >> I would like to switch to module build but AFAIK it still can't=20 >> do nested builds. > >That discussion is happening on the Module-Build list even now.=20=20 Hmm, my subscription to that list seems to have gone AWOL. >The=20 >problem is that what "nested build" means is different for different=20 >people. Personally, I'd like blib/lib and blib/arch to contain all sub=20 >blib's below the current one (strictly speaking a recursive build). And= =20 >at any level, a './Build command' will run all lower level ./Build files= =20 >with the same command depth-first. That is roughly what my Tk and Audio::* want as well. The potential issue is when the depth-first part kicks in. - The Build.PL process needs to be top down so that toplevel Build.PL can do the confugure-like tests needed by the children.=20 - I have no trouble with actual build being depth first. - I need to control the order of child builds somehow, this could=20 be by tweaking the depth ! e.g. for Tk: - Toplevel Build.PL figures out where Xlib lib and inc are.=20 - One special child is pTk which is wrapper on core tk - other descendants are the major widgets. =20=20 For Audio (::Data et. al) - Top level Build.PL decides which children _can_ be built i.e. what audio hardware we have and which math and file format libs are available. - Child builds are more-or-less independant > >Is this what EUMM does now?=20=20 Yes - with the possible exception of the depth-first, for some meaning of= =20 depth-first. It works for both cases above ;-) >This seems to be what GNU automake/autoconf=20 >seems to expect. > >John |
|
From: John P. <jpe...@ro...> - 2006-02-16 18:38:37
|
Nick Ing-Simmons wrote: > John Peacock <jpe...@ro...> writes: >> That discussion is happening on the Module-Build list even now. > > Hmm, my subscription to that list seems to have gone AWOL. Mailman gets bored easily. It's too bad that SF.net doesn't run ezmlm, so you will get a challenge email if things start bouncing for any reason. > That is roughly what my Tk and Audio::* want as well. > The potential issue is when the depth-first part kicks in. > - The Build.PL process needs to be top down so that toplevel Build.PL > can do the confugure-like tests needed by the children. > - I have no trouble with actual build being depth first. > - I need to control the order of child builds somehow, this could > be by tweaking the depth ! It may be possible to extend Build.PL so that if you need a specific execution order (or Build.PL execution order) then the toplevel file can impose that. Otherwise a simple recursive tree walk collecting the sub-projects could be the default (cake->eat_too()); Ken already said that recursive builds are on the plate for post-0.28, so rejoin the M::B list for the cagematch^Wdiscussion, since you have insights that those of us with simple modules cannot dream of... 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 |
|
From: Nick Ing-S. <ni...@in...> - 2006-02-16 19:52:51
|
Nick Ing-Simmons <ni...@in...> writes: >>That discussion is happening on the Module-Build list even now.=20=20 > >Hmm, my subscription to that list seems to have gone AWOL. Now repaired but I can't think of a way to get this spliced into=20 existing thread. So here is what I said on perl5-porters: > >>The=20 >>problem is that what "nested build" means is different for different=20 >>people. Personally, I'd like blib/lib and blib/arch to contain all sub= =20 >>blib's below the current one (strictly speaking a recursive build). And= =20 >>at any level, a './Build command' will run all lower level ./Build files= =20 >>with the same command depth-first. > >That is roughly what my Tk and Audio::* want as well. >The potential issue is when the depth-first part kicks in. > - The Build.PL process needs to be top down so that toplevel Build.PL > can do the confugure-like tests needed by the children.=20 > - I have no trouble with actual build being depth first. > - I need to control the order of child builds somehow, this could=20 > be by tweaking the depth ! > >e.g. for Tk: > - Toplevel Build.PL figures out where Xlib lib and inc are.=20 > - One special child is pTk which is wrapper on core tk > - other descendants are the major widgets. >=20=20 >For Audio (::Data et. al) > - Top level Build.PL decides which children _can_ be built > i.e. what audio hardware we have and which math and file format libs > are available. > - Child builds are more-or-less independant > So in both cases the descendants cannot run without the parent, and need parent's blib etc. about to run their tests. Parent has some tests of its own. Different children can be=20 built and tested without siblings being built/present. In this scheme a branch of tree can be lopped off or a new one=20 grafted on.=20 |
|
From: Ken W. <ke...@ma...> - 2006-02-16 21:23:47
|
On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote: > So in both cases the descendants cannot run without the parent, > and need parent's blib etc. about to run their tests. > Parent has some tests of its own. Different children can be > built and tested without siblings being built/present. The main problem I see with this approach is what happens when you 'install' from a child directory. You've tested with other blibs active, but I'm hearing people say an 'install' here should only install the child stuff, so there's a good chance things will be broken after installing since it tested with different sibling code. I can think of a few solutions to this but none so far that seem to satisfy all the use cases. -Ken |
|
From: alan <al...@pa...> - 2006-02-16 22:05:33
|
On Thu, 16 Feb 2006, Ken Williams wrote: > On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote: > > So in both cases the descendants cannot run without the parent, > > and need parent's blib etc. about to run their tests. > > Parent has some tests of its own. Different children can be > > built and tested without siblings being built/present. > > The main problem I see with this approach is what happens when you > 'install' from a child directory. You've tested with other blibs > active, but I'm hearing people say an 'install' here should only > install the child stuff, so there's a good chance things will be broken > after installing since it tested with different sibling code. One proposed solution for this which came up in the "recursive build" thread in early 2004 was to distinguish between "developer mode" and "end user mode," and to disallow end users from shooting their foot off unless they explicitly put on a "developer" hat. Developers deserve to get what they ask for. In my personal experience with recursive builds in large/deep project trees, the developer time saved in a build-test cycle is substantial, if you can manually build/test/install the two dependant directories separately, instead of having to build/test/install Everything from the closest common ancestor in the build tree. All of my recursive build requirements are specifically aimed at the developer's development cycle, and not at end users; my end users are insulated from the code. I agree that end users generally do not need to do anything other than "./Build; ./Build test; ./Build install" at the root (or, "choose some packages; ./Build install"). Alan Ferrency pair Networks, Inc. al...@pa... |
|
From: Nick Ing-S. <ni...@in...> - 2006-02-16 22:10:00
|
Ken Williams <ke...@ma...> writes: >On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote: >> So in both cases the descendants cannot run without the parent, >> and need parent's blib etc. about to run their tests. >> Parent has some tests of its own. Different children can be >> built and tested without siblings being built/present. > >The main problem I see with this approach is what happens when you=20 >'install' from a child directory.=20=20 I agree that makes no sense in this scheme.=20 In the MakeMaker world there is nothing in child blib so=20 install in there has nothing to copy and is naturally a no-op. I would be happy to put an explict install-does-nothing over-ride=20 in child Build.PL file(s). >You've tested with other blibs=20 >active, but I'm hearing people say an 'install' here should only=20 >install the child stuff, so there's a good chance things will be broken=20 >after installing since it tested with different sibling code. > >I can think of a few solutions to this=20 Such as? (appologies if they have been discussed already...) >but none so far that seem to=20 >satisfy all the use cases. I suspect that there are "a few" typical cases e.g.: A. A bundle of more or less unrelated modules put in a tree for convienience of building whole or sub-projects. B. Toplevel + a "library" subdir that builds a .a file for=20 toplevel. e.g. Compress::Zlib could have "the" open-source zlib=20 distribution as a child dir with addition of a Build.PL to build=20 libz.a if system didn't have -lz C. Framework module (like Tk or DBI) with tightly coupled=20 sub-dirs. Tk itself has all those elements but is (I hope!) not typical. So we need a "few" kinds of child Build.PL - an un-adorned one=20 could handle the "simpl" (A) case, with specialist cases being handled=20 by overrides of some kind. > > -Ken |
|
From: demerphq <dem...@gm...> - 2006-02-16 08:40:31
|
On 2/16/06, Adam Kennedy <cp...@al...> wrote: > demerphq wrote: > > On 2/15/06, John Peacock <jpe...@ro...> wrote: > >> Adam Kennedy wrote: > >>>> to be even easier. But "perl Build.PL; ./Build test; sudo ./Build > >>>> install" is a close second. > >>> That doesn't work for me, 50% of my machines require an alternative > >>> syntax of > >>> > >>> C:\Program Files... etc etc > >> Directories with spaces are evil (but I'm sure you know that already). > >> Build.cmd (or Build.bat) support may or may not make it into M::B 0.28= , > >> depending on how motivated people are, since Ken/Randy are trying to g= et 0.28 > >> out the door RSN. > >> > > > > Actually i think that this is not that well known advice and it should > > probably be added to the perl docs. > > > > Perl and everything that Perl uses for installation via CPAN should be > > installed ONLY into spaceless paths (in you want a low pain life that > > is). The easiest way to make your CPAN life hell is to put your > > compiler (im my case VC7) in a path with spaces in it. > > > > IIRC the AS installer defaults to a non space path. C:\Perl iirc (i > > usually override this so i dont remember for sure). > > > > Although Adam, i think its fair to say that in your case you should jus= t do > > > > set path=3D%path%;LOCATIONOFYOURPERL > > > > before you use MB. > > The problem is not me personally. > > Like pretty much every person on this list, I know enough to work around > such problems when they come up. > > The problem is for people that aren't on this list. At Sydney.pm last > night I met one of the maintainers of TWiki. It was enlightenment. Ok. Im sorry, i had the impression you were mostly dealing on a work context where many machines are present. Of course these things are trial and error for a newbie. And also the docs could be more helpful in this area. > For his userbase, the "things we don't tell you about using > Module::Build" would look like. > > - The zip file won't work on its own, you need to install this thing > called Perl first. > - You can't click anything, you have to go to start -> run and type in > arcane commands. > - You can't install Perl in the normal Program Files location, you have > to install it in c:\perl like an old DOS program. > - You have to answer a whole bunch of technical jargon-loaded questions > in the CPAN(PLUS) first-time process. To be fair to the Module::Build crew I think its worth pointing out that the above applies to any install that happens via CPAN, and at least one of those points applies even to ppm. > - You can't install modules with Build.PL using the CPAN installers that > come with Perl, you have to upgrade them first. > - You can't install modules with Build.PL through the CPAN installer, > you have to manually install Module::Build directly first. Ok, these are MB issues in my mind. And are consequences of what i consider to be bad design decisions early in the process. > This sort of situation is why we try to place a focus on making it > easier for the users. What's the point of making things easier for > authors if you end up serially annoying or altogether excluding 99% fo > the potential userbase. Yes i agree. In my view this has been the main misunderstanding of the MB project. The folks involved were very focued on author related concerns to the detriment of user related concerns. And typically when MB was criticised someone would come out of the woodwork and tell us how happy we should be as MB was much easier to extend and that we should just get used to MB because it was the future. (We even saw something along those lines in this thread.) The problem is they didnt seem to grok that very few of us cared if MB was easier to extend or maintain than EUMM was. All we wanted to do was install some package on CPAN using the usual tools and were prevented from doing so because MB was in the picture somewhere. And in my mind, the author focus had some interesting consequences. Users are generally not that clueful, and people trying to install a module because it supposedly solves some problem that they need to solve arent going to spend a lot of time debugging why the module failed. What they would see is a failure and that module build was involved and that any time they expended on figuring out why would be wasted when they could just go and find a different module. So no bug reports. (Or rather less bug reports than they probably needed). Not only that but author level users are more likely to have taken time and care in setting up their system, so the feedback there was probably less typical than it would have been if every install failure had been reported. Expecting users trying to install module X to diagnose and the report a failure in Y that is only in the picture because its the installer is unrealistic. Only a module author level programmer has the skills to even begin the process, and even there that assumes they have time to do so. What i reckon is much more likely is that there are a lot of MB related bugs filed against various module X's out there, and much less reports directly to MB. I mostly write this because I think that there are lessons to be learned from this. MB is a good idea, everybody who has had to fight with EUMM knows that. But the project made some signifigant mistakes that should be noted and learned from. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Rob K. <rob...@gm...> - 2006-02-16 12:27:20
|
On 2/16/06, demerphq <dem...@gm...> wrote: > Yes i agree. In my view this has been the main misunderstanding of > the MB project. The folks involved were very focued on author related > concerns to the detriment of user related concerns. And typically when > MB was criticised someone would come out of the woodwork and tell us > how happy we should be as MB was much easier to extend and that we > should just get used to MB because it was the future. (We even saw > something along those lines in this thread.) This points out a very big and well-known difference between the author and user communities. More below. > I mostly write this because I think that there are lessons to be > learned from this. MB is a good idea, everybody who has had to fight > with EUMM knows that. But the project made some signifigant mistakes > that should be noted and learned from. I think the biggest lesson is that the toolset(s) used by the author to build and package the distro shouldn't be the same toolset(s) used by the user to install the distro. Oh, the author's Build.PL (or whatever) should be available for those 1% of uesrs who are actually interested in extending a distro. But, it shouldn't be what the user HAS to use. This has come up in several incarnations on the MB list in the few months I've been lurking. Most recently, there was the discussion on author tests vs. installation tests. This past week, I've been trying to figure out if it's worth my time to create an Author.PL that I use when building which creates and uses a subclass of MB and provide a Build.PL that uses the "stock" MB. In discussions with other CPAN authors, the sentiment has been near-complete agreement with the need for such a distinction. And, I think this ties in with the move to split out the functionality in EUMM into manageable pieces that can be depended upon separately. As for Win32 ... what's wrong with having something that creates a .msi? There are free (as in beer) installer makers that will create a full installer. Need some modules? Put them in there! Need Perl? Put it in there! Let the installer figure out what's needed for installation (and where to put it!) and what's not. As for requiring "C:\perl", that's a whole lot of people not understanding how to make Win32 work for them. I don't know what the solution is as I'm not a Win32 expert, but I know it has to be there because Win32 is that easy for the user to use and for the developer to develop to. The plethora of shareware points to the fact that there are tools we as a community are not using. And, we should be. Supposedly, the Perl community is one of the premiere hacker communities. We can't ALL be Win32-clueless. In short, I think we need to do the following: 1) Create a harder separation between the installer functionality and the builder functionality. I would LOVE to see a Module::Build::Author and a separate Author.PL become a community standard. 2) The Win32-capable among us should be providing some direction as to the tools we're not using. If you know a shareware author, find out what they used to build and package their product for installation. Italian teenagers are writing software that's easier to use than ours. What are they doing that we're not? Rob |
|
From: Ron S. <ro...@sa...> - 2006-02-16 22:11:11
|
On Thu, 16 Feb 2006 07:27:13 -0500, Rob Kinyon wrote: Hi Rob > 2) The Win32-capable among us should be providing some direction as > to the tools we're not using. If you know a shareware author, find http://www.jrsoftware.org/isinfo.php -- Cheers Ron Savage, ro...@sa... on 17/02/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: Ron S. <ro...@sa...> - 2006-02-17 00:05:24
|
On Fri, 17 Feb 2006 09:07:24 +1100, Ron Savage wrote: Hi Ron > http://www.jrsoftware.org/isinfo.php I should have mentioned this one too: http://nsis.sourceforge.net/Main_Page -- Cheers Ron Savage, ro...@sa... on 17/02/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: Ken W. <ke...@ma...> - 2006-02-18 05:00:36
|
On Feb 16, 2006, at 2:40 AM, demerphq wrote: > On 2/16/06, Adam Kennedy <cp...@al...> wrote: > >> - You can't install modules with Build.PL using the CPAN installers >> that >> come with Perl, you have to upgrade them first. >> - You can't install modules with Build.PL through the CPAN installer, >> you have to manually install Module::Build directly first. > > Ok, these are MB issues in my mind. And are consequences of what i > consider to be bad design decisions early in the process. Not sure what issues you mean, but after looking at the way we do our 'passthrough' and 'small' auto-generated Makefile.PLs this is just a bug. We can fix it before 0.28. We could have fixed it long ago if I'd known about it better - as someone in one of these threads observed, I tend to have M::B installed already on my machine, so I never noticed the error. And unless I just completely missed it, nobody ever submitted a bug report either - I can only remember messages like "authors must be forced to include Makefile.PL files!" and the like, not a report of the real issue, which is that the Makefile.PL creates its pseudo-Makefile too late in the process for CPAN.pm to notice the prereqs (CPAN.pm pulls its list of prereqs for modules it's installing from a special comment in the Makefile). That lack of bug reports is probably, as you described, because the people who experience the bug aren't experienced enough to see the root of the problem. -Ken |
|
From: demerphq <dem...@gm...> - 2006-02-17 17:21:51
|
---------- Forwarded message ---------- From: Adam Kennedy <cp...@al...> Date: Feb 17, 2006 6:11 PM Subject: Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=3D1 To: per...@pe... Nicholas Clark wrote: > On Wed, Feb 15, 2006 at 12:07:02PM +0100, Rafael Garcia-Suarez wrote: >> On 2/15/06, Adam Kennedy <cp...@al...> 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 stab= le > 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 >=3D0.50 suggests that solving these "Module::Bu= ild > needs upgrading" issues isn't yet battle tested. Indeed, for example I just installed the new Vanilla Perl and following the "you need the latest toys" tried to install Bundle::CPAN, which both installs YAML 0.58 then seems to have a bunch of Module::Build things fail because it wants < 0.50. So for now CPAN.pm is seemingly not upgrading properly any more either on Win32 at least. Or at least you can't install Build.PL-only modules on Win32, once you hack your way past the Bundle installation problems. I actually suspect the final solution will be to make Module::Build do a limited version of the Module::Install trick and bundle just enough code to boot up and check to see if Module::Build needs upgrading first. Compulsory upgrading of the installation infrastructure seems the norm in a lot of places. Adam K -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Steven S. <sch...@cp...> - 2006-02-18 00:37:45
|
On Tue, Feb 14, 2006 at 11:04:15AM -0800, chromatic wrote: > I didn't say M::B made things easier *to install*, just that I consider it > *possible* to write and maintain Build.PL files that do something more than > build, test, and install pure-Perl modules that need no customization. > > I realize this discussion has veered off toward the "But this is HARD for > END-USERS" morass, but if it's painful and difficult and unpleasant for me to > package my software, I'll find other things to do and there won't be software > for end-users to be unable to install. I don't think I'm too abnormal in > that. I don't think so either; but hey, there's even a tool(kit) out there to ease most pain when transforming to a possible coexistance of Makefile.PL & Build.PL! It comes as package, namely Module::Build::Convert, which does try to convert the majority of nowadays available Makefile.PLs to compliant Build.PL ones. It's being shipped with a practicle frontend "shell" script named make2build. I guess, it roughly gets about 70% "right" - although this is not exactly a represantive statement as I have only tested it against a rather small bunch of CPAN distributed packages. May I suggest (as I previously did, but my requests didn't receive much attention and were warnocked) to at least honor the existance[1] of Module::Build::Convert on CPAN with a humble linkage in each, MakeMaker's & Module::Build's docs with a short outline. And then, there's even a article/howto[2]. I'm certainly regretful if it sounds like too much of avocacy, but I thought the knowledge about such a converter should be proliferated stronger so that users will be able to benefit of it (I rarely receive any feedback/suggestions/opinions, so I'd appreciate any of it!). [1] http://search.cpan.org/search?query=Module::Build::Convert [2] http://accognoscere.org/papers/perl-module-build-convert/module-build-convert.html -- You step in the stream, But the water has moved on. This page is not here. |
|
From: <and...@fr...> - 2006-02-18 11:31:42
|
>>>>> On Sat, 18 Feb 2006 01:37:26 +0100, Steven Schubiger <sch...@cp...> said: > I rarely receive any feedback/suggestions/opinions, > so I'd appreciate any of it! I've added your two links to the CPAN.pm manpage. Thanks! -- andreas |
|
From: Ken W. <ke...@ma...> - 2006-02-14 17:05:04
|
On Feb 14, 2006, at 5:43 AM, demerphq wrote: > On 2/14/06, Adam Kennedy <cp...@al...> wrote: >> Yitzchak Scott-Thoennes wrote: >>> On Sun, Feb 12, 2006 at 09:26:06PM -0800, Randal L. Schwartz wrote: >>>>>>>>> "chromatic" == chromatic <chr...@wg...> 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 |
|
From: demerphq <dem...@gm...> - 2006-02-14 17:23:18
|
On 2/14/06, Ken Williams <ke...@ma...> wrote: > > On Feb 14, 2006, at 5:43 AM, demerphq wrote: > > > On 2/14/06, Adam Kennedy <cp...@al...> wrote: > >> Yitzchak Scott-Thoennes wrote: > >>> On Sun, Feb 12, 2006 at 09:26:06PM -0800, Randal L. Schwartz wrote: > >>>>>>>>> "chromatic" =3D=3D chromatic <chr...@wg...> 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. =3D( 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=3Ddebug -e "/just|another|perl|hacker/" |
|
From: John P. <jpe...@ro...> - 2006-02-14 18:10:20
|
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 |
|
From: Ken W. <ke...@ma...> - 2006-02-14 18:19:35
|
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 |
|
From: Tyler M. <ty...@Ac...> - 2006-02-14 18:36:41
|
Ken Williams <ke...@ma...> wrote: > 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. With that in mind, I decided to see what happens with the most minimal build.PL possible. It ends up being this: use Module::Build; Module::Build->new( 'dist_name','foo', 'dist_version',0.01, 'dist_author','me', 'dist_abstract','you bet' )->create_build_script; faraway@pipewrench:~/dev/foo$ perl Build.PL Checking prerequisites... Looks good Creating new 'Build' script for 'foo' version '0.01' faraway@pipewrench:~/dev/foo$ ./Build distdir No license specified, setting license = 'unknown' Deleting META.yml Creating META.yml WARNING: Possible missing or corrupt 'MANIFEST' file. Nothing to enter for 'provides' field in META.yml Can't create distdir without a MANIFEST file - run 'manifest' action first at /usr/local/share/perl/5.8.7/Module/Build/Base.pm line 2754. faraway@pipewrench:~/dev/foo$ ./Build manifest File 'MANIFEST.SKIP' does not exist: Creating a default 'MANIFEST.SKIP' Added to MANIFEST: Build.PL Added to MANIFEST: MANIFEST Added to MANIFEST: META.yml faraway@pipewrench:~/dev/foo$ ./Build distdir No license specified, setting license = 'unknown' Deleting META.yml Creating META.yml Creating foo-0.01 faraway@pipewrench:~/dev/foo$ ls foo-0.01/ Build.PL MANIFEST META.yml faraway@pipewrench:~/dev/foo$ No Makefile.PL. :-( 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? :) - Tyler |
|
From: Ken W. <ke...@ma...> - 2006-02-14 18:42:39
|
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 |
|
From: Tyler M. <ty...@yi...> - 2006-02-14 19:16:52
|
Ken Williams <ke...@ma...> 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"... soooo 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 |
|
From: David G. <da...@hy...> - 2006-02-14 20:11:11
|
Tyler MacDonald wrote: > Ken Williams <ke...@ma...> 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 |
|
From: Tyler M. <ty...@yi...> - 2006-02-14 20:40:52
|
David Golden <da...@hy...> 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 |
Thanks for helping keep SourceForge clean.
X