module-build-general — General discussion about Module::Build project

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[John P. <jpe...@ro...>]

Yitzchak Scott-Thoennes wrote:
> On Fri, Feb 17, 2006 at 02:01:30PM +0000, Nicholas Clark wrote:
>> 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?  

Here the thread (it started on the YAML list):

	http://tinyurl.com/barey

(I can't figure out how to get Mailman to show the thread properly).

> 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.  

It's a little more complicated than that.  M::B 0.2611 cannot be installed with
YAML support unless YAML is >= 0.35 and < 0.49 (it's an autofeature).  However
if you reinstall YAML 0.58 after you install M::B, then everything still works.
 If M::B 0.28 required YAML 0.58 for the YAML feature to be auto-enabled, and
the author had not already upgraded YAML, then the YAML feature would be
disabled without much in the way of warning.  It still wouldn't affect the users
(who don't need YAML at all).

However, this has just given me an idea:  Bundle::Module::Build::Authors.  This
would install all of the "recommends" modules as well as the latest YAML.

In any case, I've recommended that the version.pm support be pulled out of
consideration for 0.28, due to these complications.

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

[Module::Build] M::B and version.pm

[John P. <jpe...@ro...>]

Ken, et al -

Please withdraw from consideration my patch to include version.pm support in
Module::Build 0.28.  Now that we have made the obj->numify() change, M::B will
correctly handle the case where the module author uses version.pm, and
everything else will still work correctly.

It is clear that a lot more thought has to go into when/how to handle the YAML
dependency question, and I would much rather get 0.28 shipped (for my own
selfish reasons), and fight that other battle later.

Thanks

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] Making 0.28 a reality

[John P. <jpe...@ro...>]

Yitzchak Scott-Thoennes wrote:
> Maybe I'm changing the topic a little, but *why* are you making
> version dependent on Module::Build?

Reverse that.  We are trying to make Module::Build use version.pm for all of its
internal version comparisons.

> I don't like the idea of requiring YAML for non-module-authors at all.
> Maybe you could look more into declaring a version::yaml_dump routine
> that might work for YAML 0.3[5-9]?  I'm sure the YAML people would be
> glad to give pointers.

I tried that and could get YAML to call the version::yaml_dump routine.  I'd be
happy to go that route if someone could tell me how to do it.  YAML pre-0.50
didn't handle objects very well (lots of warnings and malformed output).  And
unlike one would expect, YAML didn't just do $obj->can('yaml_dump') and then
call the routine, it just bullies along and dumps version objects weirdly.

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] Making 0.28 a reality

[Yitzchak Scott-T. <sth...@ef...>]

On Fri, Feb 17, 2006 at 09:57:57PM -0500, John Peacock wrote:
> What can I do to help get 0.28 out the door.  I was using 0.27_07 and released
> version-0.54 to CPAN and promptly broke every module trying to upgrade that
> depends on version due to a limitation in 0.2611.  It seems that
> have_c_compiler() depends on _build/ existing, yet _build/ isn't created until
> you call create_build_script() which I wasn't doing until after I found out
> whether there was a compiler available.  Chicken <=> Egg.  Needless to say,
> version-0.55 is out now. :(

FWIW, I just tried a stock cygwin perl (with no additional modules
installed), installed Module-Build 0.27_07, and tried to install
version-0.55 and got:

$ perl Build.PL
Checking whether your kit is complete...
Looks good

Checking prerequisites...
Looks good

Module::Build is not configured with C_support at /usr/lib/perl5/site_perl/5.8/Module/Build/Base.pm line 3478.

$ perl Makefile.PL
# running Build.PL
/usr/bin/perl Build.PL
Checking whether your kit is complete...
Looks good

Checking prerequisites...
Looks good

Module::Build is not configured with C_support at /usr/lib/perl5/site_perl/5.8/Module/Build/Base.pm line 3478.
Couldn't run Build.PL: Bad address at /usr/lib/perl5/site_perl/5.8/Module/Build/Compat.pm line 198.

Re: [Module::Build] Making 0.28 a reality

[Yitzchak Scott-T. <sth...@ef...>]

Maybe I'm changing the topic a little, but *why* are you making
version dependent on Module::Build?

I don't like the idea of requiring YAML for non-module-authors at all.
Maybe you could look more into declaring a version::yaml_dump routine
that might work for YAML 0.3[5-9]?  I'm sure the YAML people would be
glad to give pointers.

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[Yitzchak Scott-T. <sth...@ef...>]

On Fri, Feb 17, 2006 at 02:01:30PM +0000, 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.

Fwd: [Module::Build] Re: Summary was: Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker

[Ken W. <ke...@ma...>]

[Forwarded from Tels]

Begin forwarded message:

> From: Tels <nos...@bl...>
> Date: February 18, 2006 5:40:12 AM CST
> To: Ken Williams <ke...@ma...>
> Subject: Re: [Module::Build] Re: Summary was: Re: something broken 
> between Module::Build, CPAN.pm, and ExtUtils::MakeMaker
>
> Moin Ken,
>
> (I am not subscribed, so this reply is personally. You can forward this
> email to what list you see fit :)
>
> On Saturday 18 February 2006 05:44, you wrote:
>> Hi,
>>
>> This summary, like any summary, is most appreciated.  It helps me to
>> clarify where I see things differently, though I agree with some of
>> what's being said here.
>>
>>> On 2/16/06, Tels <nos...@bl...> wrote:
>>>> For any module, especially the ones for installing other modules
>>>> (e.g. M::B, EUMM, M::I and CPAN) there are three (not nec.
>>>> distinctive) crowds:
>>>>
>>>>   * A - the original source code author and maintainer.[0]
>>>>   * D - developers, e.g. other people who want (or must, via
>>>> dependencies)
>>>>     use the module in their code. Often includes A, too.
>>>>   * U - mere users, who just want (or must, see above) to _use_ the
>>>>     module's functionality. Can also include A and D.
>>>>
>>>> Fact of the Day:
>>>>  Any module which wants to replace the current build system (EUMM)
>>>> must
>>>>  please[8] all three crowds or it will fail.[1]
>>
>> M::B is of course trying to please all three of A, D, and U.  I had
>> hoped that would be obvious, but in case it's not, I'm re-stating it.
>
> Thanx for that. :)
>
>>>> Pleasing U does, among other things, require to solve the
>>>> chicken-egg problem.
>>
>> Well, M::B is a chicken which knows how to lay itself as an egg.  And
>> CPAN and CPANPLUS or whatever tool know how to install M::B because it
>> ships with both a Build.PL and a Makefile.PL and has since nearly day
>> one.  So at the top of the dependency tree there's a terminus.
>
> I appreciate the work you are doing and I didn't want to imply that 
> M::B
> is "bad" in this regard. What I meant to say is that M::B has a certain
> disadvantage (namely being not core and not "here" on most machines" 
> and
> this it must overcome it. That disadvanatage is, of course, not M::B's
> fault. But it is still there and you can either work around it (make it
> "easier" to use M::B as you do) or remove it (by making M::B core and
> then wait some time until all Perls are replaced).
>
>> The issue is thus reduced to making sure other distributions can
>> declare their dependency on M::B in a way that the tools will
>> recognize.  M::B::Compat is our current solution for this.  It
>> generates three different kinds of Makefile.PLs for authors to include
>> with their distributions.  We've put a lot of work into them, which
>> should be Exhibit A for showing that we care about such users.  I'm
>> sure we can improve our tools, but I do want to make it clear that 
>> they
>> exist and have since April of 2002.
>
> I think the point you missed is that there is *still* a disadvantage to
> M::B unless it gets core. And that people wanting install Foo::Bar 
> might
> have to install M::B first or update whatever, and this is not their 
> main
> goal. (The "Cant you just" covers this very nicely.) People simply get
> anoyed when they have to do things that are not really related to what
> their goal is - even tho it might be for the betterment of their 
> systems,
> world peace ect :)
>
> I know, you make it as easy as it can be, and work hard that it is as
> painless as it is. A lot of confusion stems from that fact that 
> somebody
> claims "M::B makes things hard (I suddenly have to install it, update
> CPAN etc") and then people come out and say "M::B is easy". Yes, it is
> easy, but it is still a bit harder than the current way. And thus
> perceived as "unneccessarily hard".
>
> IMHO no matter how easy you make it to install/use Module::Build, it 
> will
> fail for someone, or someone thinks it is too complicated and thus
> complains.
>
> My summary was all about how these complaints are answered. Did this 
> make
> it more clear?
>
>>>> What Module::Build claims is that it pleases A and D. From that is
>>>> infered that U will also be automatically pleased.
>>
>> I have never ever made such an assertion.
>
> I did not speak about any one in particular, should have made this more
> clear.
>
>> I do understand that there
>> are issues U considers critical that A and D don't really care much
>> about (unless they're wearing their U hats).
>>
>> Also, we do indeed try to please U in M::B.  Witness for example the
>> 'diff' action, and the fact that a huge motivator for the entire
>> project for me is to be able to generate *good* rpms/debs/ppms/etc for
>> any M::B-using CPAN module.  There's an immense infrastructure
>> necessary to do that well, and probably A and D will never care about
>> it at all.
>
> As I said, the work is appreciated, but this must also be communicated 
> to
> the users.
>
>> Who is making such an inference, anyway?
>
> Thats the impression I always get when U complain and somebody steps 
> out
> and tells us that A+D are very happy. Some people even go as far as to
> say that their easy-of-packaging trumps the user's desire to use the
> software :)
>
>>>> So, we have critism from U about not being pleased (Adam writes
>>>> about this, for instance). To this there are responses along the
>>>> lines:
>>>>
>>>> * U might be displeased or not, but D is very pleased[4]:
>>>>   http://tinyurl.com/du7yc
>>>>   Bzzzt. Wrong answer.
>>
>> It's here that you lose me.  I don't know if "Bzzzt. Wrong answer" and
>> the advocacy in the rest of the message is really "summary" fodder.
>
> These were specific examples of the main point, namely that people get
> confused a bit who's wanting what. The advocating was intentional, tho 
> I
> did cut it down as much as I could without losing the message.
>
> Maybe I should have choosen a better subject or sep. the parts of the
> message.
>
>> Anyway, we've identified some things about the Makefile.PLs that can 
>> be
>> improved.  We'll do so.
>>
>> Specific issues we can fix, or at least identify, are great.  But I
>> resent some of the implications going around that our whole philosophy
>> of the project is wrong, or that somehow we're evil for wanting to
>> create and release a better build system.  These things are
>> complicated, and if some area is substandard that's because it needs
>> tuits, not because we don't care about our users.
>
> Agreed. I did _not_ want to convey the meaning that M::B is bad, or 
> wrong
> or whatever. But wether your efforts are appreciated by the very people
> who have to use them depends not only on the "work" but also on the
> "talk" :)
>
> Thanx for your response,
>
> Tels
>
> -- 
>  Signed on Sat Feb 18 12:15:40 2006 with key 0x93B84C15.
>  Visit my photo gallery at http://bloodgate.com/photos/
>  PGP key on http://bloodgate.com/tels.asc or per email.
>
>  This email violates U.S. patent #5,978,791 <http://tinyurl.com/5t6ft>
>

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ken W. <ke...@ma...>]

On Feb 18, 2006, at 2:34 AM, Ingy dot Net wrote:

> On 17/02/06 21:52 -0600, Ken Williams wrote:
>> It needs to be removed from build_requires, then, because when it's in
>> there, installation tools will think they need to fetch & install it.
>>
>>  -Ken
>
> You mean in the META.yml? Module::Install generates that for me. Is it 
> wrong?
>

Yeah, it's wrong in this case.  CPAN reads it to determine dependencies 
it will need to fetch & install.

  -Ken

Re: Build disttest (Was: [Module::Build] Making 0.28 a reality)

[John P. <jpe...@ro...>]

Andreas J. Koenig wrote:
>>>>>> On Fri, 17 Feb 2006 21:57:57 -0500, John Peacock <jpe...@ro...> said:
> 
>   > I know, *my fault*, not Module::Build's, but still, it makes me want to use
>   > Module::Install now... ;-)
> 
> Would using "./Build disttest" have uncovered the bug?
> 

No, because I had M::B 0.27_07 installed, which doesn't have this limitation
(and actually I use Module::Release, so `make disttest` _was_ run).

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] Making 0.28 a reality

[Julian M. <ju...@me...>]

Rob Kinyon wrote:
> On 2/18/06, Julian Mehnle <ju...@me...> wrote:
> > That would require YAML on _every_ Module::Build installation of the
> > world, not just on module authors' systems.  E.g. if I wanted to
> > install (not repackage) version.pm, I'd have to install YAML first.
>
> So? Perl requires MLDBM on every Perl installation in the world. How
> many times has anyone on this list used that module? Buehler ....
> Buehler ....
>
> Prereqs are the name of the game in Perl. Minimizing them is a nice to
> have, but YAML is rapidly becoming the better XML (which I'm grateful
> for) and I'm not sure "forcing" people to install YAML is a bad plan.

_I_, for that matter, certainly wouldn't have anything against having YAML=
=20
in core, which is what would have to happen if M::B will be going into=20
core.  But you should probably go convince the core people first.

Re: [Module::Build] Making 0.28 a reality

[Rob K. <rob...@gm...>]

On 2/18/06, Julian Mehnle <ju...@me...> wrote:
> That would require YAML on _every_ Module::Build installation of the worl=
d,
> not just on module authors' systems.  E.g. if I wanted to install (not
> repackage) version.pm, I'd have to install YAML first.

So? Perl requires MLDBM on every Perl installation in the world. How
many times has anyone on this list used that module? Buehler ....
Buehler ....

Prereqs are the name of the game in Perl. Minimizing them is a nice to
have, but YAML is rapidly becoming the better XML (which I'm grateful
for) and I'm not sure "forcing" people to install YAML is a bad plan.

Rob

Re: [Module::Build] Making 0.28 a reality

[Julian M. <ju...@me...>]

John Peacock wrote:
> Where we left the earlier discussion was that the version.pm patch to
> M::B would require upgrading the YAML dependency to 0.58.  The issue was
> that this would [mostly] silently disable the YAML support for people
> who didn't notice.  There seems to be two ways around it:
>
> 1) write a routine to query the user whether they wanted to upgrade YAML
> at the same time and then make it a prereq;
>
> or
>
> 2) just go ahead and make YAML a prereq of 0.28.
>
> Is there any reason why #2 isn't the way to go?

That would require YAML on _every_ Module::Build installation of the world,=
=20
not just on module authors' systems.  E.g. if I wanted to install (not=20
repackage) version.pm, I'd have to install YAML first.

Build disttest (Was: [Module::Build] Making 0.28 a reality)

[<and...@fr...>]

>>>>> On Fri, 17 Feb 2006 21:57:57 -0500, John Peacock <jpe...@ro...> said:

  > I know, *my fault*, not Module::Build's, but still, it makes me want to use
  > Module::Install now... ;-)

Would using "./Build disttest" have uncovered the bug?

-- 
andreas

[Module::Build] Re: [ANNOUNCE] Module::Build::Convert

[<and...@fr...>]

>>>>> 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

Re: [Module::Build] How to require an MB subclass in a CPAN friendly way?

[<and...@fr...>]

>>>>> On Fri, 17 Feb 2006 11:53:50 -0800, Tyler MacDonald <ty...@yi...> said:

  > Stephen Adkins <spa...@gm...> wrote:
 >> Hi,
 >> 
 >> If I understand the problem right, it is that you wish to use a module in the
 >> current distribution (a subclass of Module::Build) to do the installing.
 >> If this is correct, you only need to put a 'use lib "lib";' in your Build.PL
 >> for it to be picked up properly.  (It does not need to be installed in the
 >> standard places before you use it.)

  > 	Nope, that problem is handled already in
  > DBIx::Migration::Directories.

  > 	I now have a Schema::RDBMS::AUS package, which needs the subclass
  > that DBIx::Migration::Directories supplies.
  > DBIx::Migration::Directories::Build needs to be available at the time
  > Build.PL is run so that it can alter Module::Build's config and supply extra
  > actions.

Add it to your "requires" hash, that way it will end up in META.yml
and if people have YAML installed, they can read it and everything
should work as you want.

If people have YAML not installed they will call either the
Makefile.PL or the Build.PL to hopefully find out what the
prerequisites are. That way you get the prerequisites but as you have
noticed, it is too late for your build process.

I don't know how I will fix that. Suggestions welcome. I put it into my
Todo file.


-- 
andreas

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ingy d. N. <in...@tt...>]

On 17/02/06 21:52 -0600, Ken Williams wrote:
> 
> On Feb 17, 2006, at 9:42 PM, Ingy dot Net wrote:
> 
> >On 17/02/06 01:51 -0800, Yitzchak Scott-Thoennes wrote:
> >>On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote:
> >>>Ken,
> >>>
> >>>You definitely want to use 0.58+ for your prereqs.
> >>>
> >>>For a couple of 0.5x releases there were Spiffy deps etc, but that's 
> >>>all been
> >>>resolved. Now YAML.pm requires no extra deps.
> >>
> >>You realize that you still have build_requires Test::Base 0.49
> >>and Test-Base requires Spiffy?
> >
> >These are bundled as testing artifacts. You need neither installed on 
> >your
> >machine and the YAML dist installs neither.
> 
> It needs to be removed from build_requires, then, because when it's in 
> there, installation tools will think they need to fetch & install it.
> 
>  -Ken

You mean in the META.yml? Module::Install generates that for me. Is it wrong?

Cheers, Ingy

Re: [Module::Build] Change install_base

[David W. <da...@ki...>]

On Feb 17, 2006, at 20:48, Ken Williams wrote:

> Sure, $self->install_base($new_val) should work.

Oh. Duh. Thanks. :-)

David

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ken W. <ke...@ma...>]

On Feb 17, 2006, at 9:04 AM, Chris Dolan wrote:

> That is correct, but the point is (I believe) that if you don't use 
> CPAN/CP+ then the install will succeed anyway.

Ooh, don't start down that road, man.  The 'passthrough' auto-generated 
Makefile.PL will succeed in manual mode and fail under CPAN, when M::B 
isn't installed, and look how upset that makes people.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMakerin5.8.8 for UINST=1

[Ken W. <ke...@ma...>]

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

Re: [Module::Build] Change install_base

[Ken W. <ke...@ma...>]

On Feb 16, 2006, at 6:57 PM, David Wheeler wrote:

> Hi All,
>
> Is there any way to change the install_base after constructing a 
> Module::Build object? I'm working on a subclass, and I'd like to 
> change the install_base in the subclass constructor, depending on 
> other properties that might be set (such as the location of a config 
> file that contains the install path in it).

Sure, $self->install_base($new_val) should work.

  -Ken

Re: [Module::Build] Re: Summary was: Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker

[Ken W. <ke...@ma...>]

Hi,

This summary, like any summary, is most appreciated.  It helps me to 
clarify where I see things differently, though I agree with some of 
what's being said here.



> On 2/16/06, Tels <nos...@bl...> wrote:
>>
>> For any module, especially the ones for installing other modules (e.g.
>> M::B, EUMM, M::I and CPAN) there are three (not nec. distinctive) 
>> crowds:
>>
>>   * A - the original source code author and maintainer.[0]
>>   * D - developers, e.g. other people who want (or must, via 
>> dependencies)
>>     use the module in their code. Often includes A, too.
>>   * U - mere users, who just want (or must, see above) to _use_ the
>>     module's functionality. Can also include A and D.
>>
>> Fact of the Day:
>>  Any module which wants to replace the current build system (EUMM) 
>> must
>>  please[8] all three crowds or it will fail.[1]

M::B is of course trying to please all three of A, D, and U.  I had 
hoped that would be obvious, but in case it's not, I'm re-stating it.


>>
>> Pleasing U does, among other things, require to solve the chicken-egg
>> problem.


Well, M::B is a chicken which knows how to lay itself as an egg.  And 
CPAN and CPANPLUS or whatever tool know how to install M::B because it 
ships with both a Build.PL and a Makefile.PL and has since nearly day 
one.  So at the top of the dependency tree there's a terminus.

The issue is thus reduced to making sure other distributions can 
declare their dependency on M::B in a way that the tools will 
recognize.  M::B::Compat is our current solution for this.  It 
generates three different kinds of Makefile.PLs for authors to include 
with their distributions.  We've put a lot of work into them, which 
should be Exhibit A for showing that we care about such users.  I'm 
sure we can improve our tools, but I do want to make it clear that they 
exist and have since April of 2002.


>> What Module::Build claims is that it pleases A and D. From that is 
>> infered
>> that U will also be automatically pleased.

I have never ever made such an assertion.  I do understand that there 
are issues U considers critical that A and D don't really care much 
about (unless they're wearing their U hats).

Also, we do indeed try to please U in M::B.  Witness for example the 
'diff' action, and the fact that a huge motivator for the entire 
project for me is to be able to generate *good* rpms/debs/ppms/etc for 
any M::B-using CPAN module.  There's an immense infrastructure 
necessary to do that well, and probably A and D will never care about 
it at all.

Who is making such an inference, anyway?


>> So, we have critism from U about not being pleased (Adam writes about
>> this, for instance). To this there are responses along the lines:
>>
>> * U might be displeased or not, but D is very pleased[4]:
>>   http://tinyurl.com/du7yc
>>   Bzzzt. Wrong answer.

It's here that you lose me.  I don't know if "Bzzzt. Wrong answer" and 
the advocacy in the rest of the message is really "summary" fodder.

Anyway, we've identified some things about the Makefile.PLs that can be 
improved.  We'll do so.

Specific issues we can fix, or at least identify, are great.  But I 
resent some of the implications going around that our whole philosophy 
of the project is wrong, or that somehow we're evil for wanting to 
create and release a better build system.  These things are 
complicated, and if some area is substandard that's because it needs 
tuits, not because we don't care about our users.

  -Ken

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ken W. <ke...@ma...>]

On Feb 17, 2006, at 3:47 AM, Yitzchak Scott-Thoennes wrote:

> On Thu, Feb 16, 2006 at 12:46:34PM -0500, John Peacock wrote:
>> Is there some overriding reason you are avoiding upgrading the YAML
>> prereq to 0.50 (which in itself isn't even the current rev)?
>
> The newer YAMLs require 5.6.1 (plus a lot of other dependency-bloat).
>

Yeah, M::B targets perls back as far as 5.005_03.  The functionality we 
require from YAML is fairly trivial, just serializing strings & 
numbers.  If YAML itself is too heavyweight for our simple task, maybe 
we need to consider just reimplementing the parts of it we need.  Which 
we could then release as YAML::SmallSubset or something if desirable.

I dunno, none of the options sound fun.

  -Ken

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ken W. <ke...@ma...>]

On Feb 17, 2006, at 9:42 PM, Ingy dot Net wrote:

> On 17/02/06 01:51 -0800, Yitzchak Scott-Thoennes wrote:
>> On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote:
>>> Ken,
>>>
>>> You definitely want to use 0.58+ for your prereqs.
>>>
>>> For a couple of 0.5x releases there were Spiffy deps etc, but that's 
>>> all been
>>> resolved. Now YAML.pm requires no extra deps.
>>
>> You realize that you still have build_requires Test::Base 0.49
>> and Test-Base requires Spiffy?
>
> These are bundled as testing artifacts. You need neither installed on 
> your
> machine and the YAML dist installs neither.

It needs to be removed from build_requires, then, because when it's in 
there, installation tools will think they need to fetch & install it.

  -Ken

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ingy d. N. <in...@tt...>]

On 17/02/06 01:51 -0800, Yitzchak Scott-Thoennes wrote:
> On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote:
> > Ken,
> > 
> > You definitely want to use 0.58+ for your prereqs.
> > 
> > For a couple of 0.5x releases there were Spiffy deps etc, but that's all been
> > resolved. Now YAML.pm requires no extra deps.
> 
> You realize that you still have build_requires Test::Base 0.49
> and Test-Base requires Spiffy?

These are bundled as testing artifacts. You need neither installed on your
machine and the YAML dist installs neither.

Try installing YAML on a clean Perl. :)

Cheers, Ingy

[Module::Build] Making 0.28 a reality

[John P. <jpe...@ro...>]

Folks -

What can I do to help get 0.28 out the door.  I was using 0.27_07 and released
version-0.54 to CPAN and promptly broke every module trying to upgrade that
depends on version due to a limitation in 0.2611.  It seems that
have_c_compiler() depends on _build/ existing, yet _build/ isn't created until
you call create_build_script() which I wasn't doing until after I found out
whether there was a compiler available.  Chicken <=> Egg.  Needless to say,
version-0.55 is out now. :(

I know, *my fault*, not Module::Build's, but still, it makes me want to use
Module::Install now... ;-)

Where we left the earlier discussion was that the version.pm patch to M::B would
require upgrading the YAML dependency to 0.58.  The issue was that this would
[mostly] silently disable the YAML support for people who didn't notice.  There
seems to be two ways around it:

1) write a routine to query the user whether they wanted to upgrade YAML at the
same time and then make it a prereq;

or

2) just go ahead and make YAML a prereq of 0.28.

Is there any reason why #2 isn't the way to go?  Is M::B really wedded to the
_write_minimal_metadata code for some reason?  Isn't YAML stable enough?  YAML
doesn't appear to have any non-core dependencies (according to module_info):

Modules used:
    YAML::Base
    YAML::Dumper::Base
    YAML::Node
    base
    constant
    strict
    warnings

That would certainly be the cleanest way to deal with it.

As a third option, if I had to, I could produce a patch that would force the
version objects to stringify before being added to the YAML $node.  But this is
especially ugly and hackish.

Note also that I forgot this on my previous patch:

$ svk diff lib/Module/Build/Base.pm
=== lib/Module/Build/Base.pm
==================================================================
--- lib/Module/Build/Base.pm    (revision 1830)
+++ lib/Module/Build/Base.pm    (local)
@@ -1090,10 +1090,6 @@
   my $self = shift;
   my ($v1, $op, $v2) = @_;

-  # for alpha versions - this doesn't cover all cases, but should work for most:
-  $v1 =~ s/_(\d+)\z/$1/;
-  $v2 =~ s/_(\d+)\z/$1/;
-
   my $eval_str = "\$v1 $op \$v2";
   my $result   = eval $eval_str;
   $self->log_warn("error comparing versions: '$eval_str' $@") if $@;

since version objects work fine as alpha versions.  After 0.28 is out, I can
move more of the version code to Module::Build::version and simplify a lot of
code in the process.

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