Re: ExtUtils::Install dependency

Michael G Schwern wrote: > Eric Wilhelm wrote: >> # from David Golden >> # on Sunday 08 February 2009 08:21: >> I strongly encourage Module::Build to require/use the latest EUI. If there are any backcompat problems that arise from doing so please let me know. The latest release is 1.

Re: ExtUtils::Install dependency

David Golden wrote: > On Sun, Feb 8, 2009 at 5:37 PM, Michael G Schwern > wrote: > > MakeMaker already ships a minimum version of ExtUtils::Install and > has for > some time. Module::Build has latest.pm to deal > with exactly this prob

Re: ExtUtils::Install dependency

On Sun, Feb 8, 2009 at 5:37 PM, Michael G Schwern wrote: > > > MakeMaker already ships a minimum version of ExtUtils::Install and has for > some time. Module::Build has latest.pm to deal with exactly this problem. > But does EU::MM actually *install* the bundled EU::Install? Or just uses it t

Re: bundling ExtUtils::Install

# from Michael G Schwern # on Sunday 08 February 2009 14:37: >MakeMaker already ships a minimum version of ExtUtils::Install and has > for some time.  Module::Build has latest.pm to deal with exactly this > problem. From my understanding, latest.pm is equipped to locally rely on a bundled module

Re: ExtUtils::Install dependency

Zefram wrote: > Michael G Schwern wrote: >> Since EUI ships with both a Build.PL and a Makefile.PL this introduces a >> circular dependency between EUI and Module::Build. > > Only if EUI depends on an MB recent enough to require a new EUI. I don't > see why it would do that; presumably EUI can be

Re: ExtUtils::Install dependency

On Sun, Feb 8, 2009 at 2:45 PM, Michael G Schwern wrote: > > There's two ways out of this. MB can do what MakeMaker does and ship their > own copy of EUI. This would let MB eat it's own dog food in the form of > latest.pm. This would probably be an overall good thing. > > Or EUI can drop the B

Re: ExtUtils::Install dependency

Michael G Schwern wrote: >Since EUI ships with both a Build.PL and a Makefile.PL this introduces a >circular dependency between EUI and Module::Build. Only if EUI depends on an MB recent enough to require a new EUI. I don't see why it would do that; presumably EUI can be installed using an old MB

Re: ExtUtils::Install dependency

David Golden wrote: > On Sun, Feb 8, 2009 at 9:20 AM, demerphq wrote: > >> I strongly encourage Module::Build to require/use the latest EUI. If >> there are any backcompat problems that arise from doing so please let >> me know. The latest release is 1.52, which has been stable for some >> time.

Re: ExtUtils::Install dependency

Eric Wilhelm wrote: > # from David Golden > # on Sunday 08 February 2009 08:21: > >>> I strongly encourage Module::Build to require/use the latest EUI. If >>> there are any backcompat problems that arise from doing so please >>> let me know. The latest release is 1.52, which has been stable for >>

Re: ExtUtils::Install dependency

# from David Golden # on Sunday 08 February 2009 08:21: >> I strongly encourage Module::Build to require/use the latest EUI. If >> there are any backcompat problems that arise from doing so please >> let me know. The latest release is 1.52, which has been stable for >> some time. > >Committed to t

Re: ExtUtils::Install dependency

On Sun, Feb 8, 2009 at 9:20 AM, demerphq wrote: > > I strongly encourage Module::Build to require/use the latest EUI. If > there are any backcompat problems that arise from doing so please let > me know. The latest release is 1.52, which has been stable for some > time. > Committed to trunk. --

Re: ExtUtils::Install dependency

2009/2/8 Zefram : > M:B declares an unversioned dependency on ExtUtils::Install. There is a > bug in EU:I 0.29 that causes a M:B fakeinstall to be insufficiently fake: > it actually creates the libdir and the directory to contain the packlist. > This shows up in the M:B test suite, if one is testi

ExtUtils::Install dependency

M:B declares an unversioned dependency on ExtUtils::Install. There is a bug in EU:I 0.29 that causes a M:B fakeinstall to be insufficiently fake: it actually creates the libdir and the directory to contain the packlist. This shows up in the M:B test suite, if one is testing as an unprivileged user