module-build-general Mailing List for Module::Build (Page 28)

Status: Beta

Brought to you by: kwilliams

This project can now be found here.

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

You can subscribe to this list here.

2002	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug (24)	_Sep (2)	_Oct (18)	_Nov (36)	_Dec (17)
2003	_Jan (3)	_Feb (96)	_Mar (82)	_Apr (63)	_May (90)	_Jun (52)	_Jul (94)	_Aug (89)	_Sep (75)	_Oct (118)	_Nov (101)	_Dec (111)
2004	_Jan (159)	_Feb (155)	_Mar (65)	_Apr (121)	_May (62)	_Jun (68)	_Jul (54)	_Aug (45)	_Sep (78)	_Oct (80)	_Nov (271)	_Dec (205)
2005	_Jan (128)	_Feb (96)	_Mar (83)	_Apr (113)	_May (46)	_Jun (120)	_Jul (146)	_Aug (47)	_Sep (93)	_Oct (118)	_Nov (116)	_Dec (60)
2006	_Jan (130)	_Feb (330)	_Mar (228)	_Apr (203)	_May (97)	_Jun (15)	_Jul (6)	_Aug	_Sep	_Oct	_Nov	_Dec

Flat | Threaded

<< < 1 .. 26 27 28 29 30 .. 185 > >> (Page 28 of 185)

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

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.

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

From: Tyler M. <ty...@yi...> - 2006-02-17 19:54:05

Stephen Adkins <spa...@gm...> wrote:
> Hi,
>=20
> 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=
=2EPL
> 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.

	Similar case with mod_perl2: If you install an apache2 module that
uses Apache::TestMB, you can't run the tests properly unless mod_perl2 was
installed *before* the Build.PL was run.

	I suspect this is also the case with App::Build.

	Thanks,
		Tyler



> --------------------------------------------
> use lib "lib";   # so we can find Module::Build::Foo before it is install=
ed
> use Module::Build::Foo;
> my $build =3D Module::Build::Foo->new (
>     dist_name         =3D> "Foo",
>     dist_version      =3D> "0.50",
>     dist_author       =3D> "spa...@gm...",
>     license           =3D> "perl",
>     requires =3D> {
>         "Module::Build"  =3D> 0,  # needed for installing the software
>     },
> );
> $build->create_build_script;
> --------------------------------------------
> Then your install module is in your distribution as
> "lib/App/Build/Foo.pm".
> Does this solve the problem?
>=20
> Stephen
>=20
> Note: On replying, I replied to mod...@li...=
t and
> did *not* cross-post to cpa...@pe... and mo...@pe....
>=20
> On 2/17/06, Tyler MacDonald <ty...@yi...> wrote:
> > Here's what I've got so far:
> >
> >         http://search.cpan.org/src/CRAKRJACK/Schema-RDBMS-AUS-0.01/Buil=
d.PL
> >
> > I'm forcing the "install" action to fail without the Module::Build subc=
lass
> > in DBIx::Migration::Directories (which I've noticed lately has a few
> > similarities with App::Build), because without this subclass, the insta=
ll
> > will be useless to a user.
> >
> > The problem is that if somebody doesn't have DBIx::Migration::Directori=
es
> > installed already, they'll have to go through CPAN twice, since CPAN wo=
n't
> > re-run Build.PL after downloading the dependancies.
> >
> > I see this being a problem in the mod_perl world as well, with the
> > Apache::TestMB Module::Build subclass.
> >
> > I know this has been discussed a little bit before, if there's a mailing
> > list archive message with a definate solution or something just point me
> > there and I'll shut up. :)
> >
> > Is there a solution that will make sure that a package using a MB subcl=
ass
> > from another package installs cleanly out of CPAN, whether or not that
> > subclass is already installed on a system?
> >
> >         Thanks,
> >                 Tyler
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> > _______________________________________________
> > Module-build-general mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/module-build-general
> >
>=20

--=20
Tank will apprehensively negotiate virtual information.

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

From: Stephen A. <spa...@gm...> - 2006-02-17 19:46:44

Hi,

If I understand the problem right, it is that you wish to use a module in t=
he
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.P=
L
for it to be picked up properly.  (It does not need to be installed in the
standard places before you use it.)
--------------------------------------------
use lib "lib";   # so we can find Module::Build::Foo before it is installed
use Module::Build::Foo;
my $build =3D Module::Build::Foo->new (
    dist_name         =3D> "Foo",
    dist_version      =3D> "0.50",
    dist_author       =3D> "spa...@gm...",
    license           =3D> "perl",
    requires =3D> {
        "Module::Build"  =3D> 0,  # needed for installing the software
    },
);
$build->create_build_script;
--------------------------------------------
Then your install module is in your distribution as
"lib/App/Build/Foo.pm".
Does this solve the problem?

Stephen

Note: On replying, I replied to mod...@li... =
and
did *not* cross-post to cpa...@pe... and mo...@pe....

On 2/17/06, Tyler MacDonald <ty...@yi...> wrote:
> Here's what I've got so far:
>
>         http://search.cpan.org/src/CRAKRJACK/Schema-RDBMS-AUS-0.01/Build.=
PL
>
> I'm forcing the "install" action to fail without the Module::Build subcla=
ss
> in DBIx::Migration::Directories (which I've noticed lately has a few
> similarities with App::Build), because without this subclass, the install
> will be useless to a user.
>
> The problem is that if somebody doesn't have DBIx::Migration::Directories
> installed already, they'll have to go through CPAN twice, since CPAN won'=
t
> re-run Build.PL after downloading the dependancies.
>
> I see this being a problem in the mod_perl world as well, with the
> Apache::TestMB Module::Build subclass.
>
> I know this has been discussed a little bit before, if there's a mailing
> list archive message with a definate solution or something just point me
> there and I'll shut up. :)
>
> Is there a solution that will make sure that a package using a MB subclas=
s
> from another package installs cleanly out of CPAN, whether or not that
> subclass is already installed on a system?
>
>         Thanks,
>                 Tyler
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>

Re: [Module::Build] Document install_base_relpaths

From: David W. <da...@ki...> - 2006-02-17 19:30:12

On Feb 16, 2006, at 21:33, David Wheeler wrote:

> I just discovered install-base_relpaths, and for setting up new  
> elements to simply be installed relative to whatever the  
> install_base happens to be, it's very convenient. I'd like to see  
> it documented in the cookbook. The attached patch adds a note about  
> it there. Think you might let this be documented?

Or perhaps better still, add_build_element could make it the default?  
That patch would look like this:

--- Base.pm	16 Feb 2006 22:06:21 -0800	1.546
+++ Base.pm	17 Feb 2006 11:28:54 -0800	
@@ -449,8 +449,9 @@


sub add_build_element {
-  my $self = shift;
-  push @{$self->build_elements}, shift;
+    my ($self, $elem) = @_;
+    $self->install_base_relpaths->{$elem} ||= [$elem];
+    push @{$self->build_elements}, $elem;

}

sub ACTION_config_data {

Thanks,

David

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

From: Tyler M. <ty...@yi...> - 2006-02-17 19:16:20

Here's what I've got so far:

	http://search.cpan.org/src/CRAKRJACK/Schema-RDBMS-AUS-0.01/Build.PL

I'm forcing the "install" action to fail without the Module::Build subclass
in DBIx::Migration::Directories (which I've noticed lately has a few
similarities with App::Build), because without this subclass, the install
will be useless to a user.

The problem is that if somebody doesn't have DBIx::Migration::Directories
installed already, they'll have to go through CPAN twice, since CPAN won't
re-run Build.PL after downloading the dependancies.

I see this being a problem in the mod_perl world as well, with the
Apache::TestMB Module::Build subclass.

I know this has been discussed a little bit before, if there's a mailing
list archive message with a definate solution or something just point me
there and I'll shut up. :)=20

Is there a solution that will make sure that a package using a MB subclass
=66rom another package installs cleanly out of CPAN, whether or not that
subclass is already installed on a system?

	Thanks,
		Tyler

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

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

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

From: Chris D. <ch...@cl...> - 2006-02-17 15:04:23

On Feb 17, 2006, at 8:55 AM, David Golden wrote:

> Chris Dolan wrote:
>> On Feb 17, 2006, at 3:51 AM, 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?
>> I had the same question, but I then noticed that those are both  
>> included in the inc/ dir.
>
> But it's still listed in the META.yml file as a build_requires.  I  
> think that will cause CPAN/CPANPLUS to try to install/upgrade it,  
> regardless of its presence in inc/.
>
> David Golden

That is correct, but the point is (I believe) that if you don't use  
CPAN/CP+ then the install will succeed anyway.  Just as an  
experiment, I tried a CPAN install and said NO to Test::Base.  The  
install succeeded.

cpan> install YAML
...
Running install for module YAML
Running make for I/IN/INGY/YAML-0.58.tar.gz
Fetching with LWP:
   ftp://mirrors.kernel.org/pub/CPAN/authors/id/I/IN/INGY/ 
YAML-0.58.tar.gz
CPAN: Digest::MD5 loaded ok
Fetching with LWP:
   ftp://mirrors.kernel.org/pub/CPAN/authors/id/I/IN/INGY/CHECKSUMS
Checksum for /root/.cpan/sources/authors/id/I/IN/INGY/ 
YAML-0.58.tar.gz ok
...
   CPAN.pm: Going to build I/IN/INGY/YAML-0.58.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for YAML
---- Unsatisfied dependencies detected during [I/IN/INGY/ 
YAML-0.58.tar.gz] -----
     Test::Base
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes] n
...
All tests successful, 17 subtests skipped.
Files=32, Tests=415, 47 wallclock secs (39.81 cusr +  2.69 csys =  
42.50 CPU)
   /usr/bin/make test -- OK
...

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: [Yaml-core] yaml_dump on version objects

From: David G. <da...@hy...> - 2006-02-17 14:55:56

Chris Dolan wrote:
> On Feb 17, 2006, at 3:51 AM, 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?
> 
> I had the same question, but I then noticed that those are both included 
> in the inc/ dir.

But it's still listed in the META.yml file as a build_requires.  I think 
that will cause CPAN/CPANPLUS to try to install/upgrade it, regardless 
of its presence in inc/.

David Golden

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

From: Chris D. <ch...@cl...> - 2006-02-17 14:33:26

On Feb 17, 2006, at 3:51 AM, 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?

I had the same question, but I then noticed that those are both  
included in the inc/ dir.
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

From: Nicholas C. <ni...@cc...> - 2006-02-17 14:01:47

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

[Module::Build] ExtUtils::CBuilder: cygwin gcc in mingw mode misparses command line

From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 13:32:27

Cygwin programs when run by non-cygwin programs do not interpret \" as
an escaped " except within "".  This results in errors like the
following when using cygwin gcc in "mingw" mode:

gcc -mno-cygwin -c -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX -s -O2 -DXS_VERSION=\"0.01\" -DVERSION=\"0.01\" -I"..\..\..\lib\CORE" -I"C:\MinGW\include" -o "lib\Simple.o" "lib\Simple.c"
gcc: no input files
error building dll file from 'lib\Simple.c' at C:\cygwin\home\sthoenna\bleadperl\wp\lib/ExtUtils/CBuilder/Platform/Windows.pm line 143.

The first backslash in -DXS_VERSION=\"0.01\" is treated as a literal
backslash, and the " after it starts a quoted string, resulting in gcc
getting everything after -O2 as a single argument:

  -DXS_VERSION=\0.01" -DVERSION="0.01" -I......libCORE -IC:MinGWinclude -o libSimple.o libSimple.c

The following patch fixes this and in theory should not cause any
problems.

--- lib/ExtUtils/CBuilder/Platform/Windows.pm.orig	2005-10-04 04:32:20.000000000 -0700
+++ lib/ExtUtils/CBuilder/Platform/Windows.pm	2006-01-09 19:55:07.807132800 -0800
@@ -93,7 +93,7 @@
 sub arg_defines {
   my ($self, %args) = @_;
   s/"/\\"/g foreach values %args;
-  return map "-D$_=$args{$_}", keys %args;
+  return map qq{"-D$_=$args{$_}"}, keys %args;
 }
 
 sub compile {

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

From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 09:51:27

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?

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

From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 09:47:57

On Thu, Feb 16, 2006 at 12:46:34PM -0500, John Peacock wrote:
> Ken Williams wrote:
> >
> >On Feb 15, 2006, at 4:06 PM, John Peacock wrote:
> >>Never mind.  Upgrading YAML to current (0.58) works much better and 
> >>setting $YAML::Stringify does exactly what we want.
> >
> >Is there no way to support YAML 0.35?  That's our current YAML 
> >prerequisite.
> 
> Nope.  Once you throw an object into the mix, YAML gets very confused. 
> Apply my patch and try it with 0.35 and you will see:
> 
> 1) a screenful of warnings thrown during the META.yml creation;
> 2) worse yet, the META.yml is malformed (it doesn't include either a 
> dump of the version object as hash nor the correct stringified 
> representation).
> 
> I can, with some more difficulty, patch M::B to force a stringification 
> of version objects prior to inserting them into the $node, but it isn't 
> nearly as clean.
> 
> 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).

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

From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 08:25:18

On Thu, Feb 16, 2006 at 06:42:27PM +0100, demerphq wrote:
> PS: I cc'ed the MB and EUMM folks on this. No good summarizing if all
> the relevent people arent going to see it, but maybe me sending it is
> for the beter anyway, as im on the MB list so it wont go into
> moderator purgatory when it comes from me.

Just a reminder to anyone interested in posting to
mod...@li... but not actually wanting to
receive all the messages that you can "whitelist" yourself by
subscribing and then setting the nomail option.

[Module::Build] Document install_base_relpaths

From: David W. <da...@ki...> - 2006-02-17 05:33:21

Attachments: install_base_relpaths.patch.txt

Module::Builders,

I just discovered install-base_relpaths, and for setting up new  
elements to simply be installed relative to whatever the install_base  
happens to be, it's very convenient. I'd like to see it documented in  
the cookbook. The attached patch adds a note about it there. Think  
you might let this be documented?

Thanks!

David

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

From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 03:26:54

On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote:
> On 2/16/06, demerphq <dem...@gm...> 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.