It seems like using an xt dir and an AUTHOR_TESTING env var is the
emerging standard for managing author-only tests.
Can we change Module::Build to include the xt dir if this env var is set?
-dave
/*
http://VegGuide.org
If I load a Module::Build subclass from a custom dir and then later, in a
separate process, call Module::Build->current, it blows up because it
can't find my subclass.
There is already code to account for this in the generated Build script.
Can this be moved to ::Base->resume instead somehow?
On Fri, 11 Sep 2009, David Golden wrote:
What do people think about changing M::B's default behavior to
generate all content (Makefile.PL, META.yml, README, LICENSE) in the
"distdir" generated directory rather than in the top source directory?
In theory, it sounds good. I do wonder if this wou
It'd be good to have the Makefile.PL that MB::Compat generates include
this line:
PL_FILES => {}
Otherwise some ancient versions of EUMM (pre-6.25) see the Build.PL and
try to process it.
See https://rt.cpan.org/Ticket/Display.html?id=43605 for some details and
discussion.
Alternately,
On Fri, 12 Dec 2008, Eric Wilhelm wrote:
# from Ken Williams
# on Friday 12 December 2008 11:03:
Does RT have any way to tag tickets arbitrarily, or as being toward
some milestone?
Not as-configured. I think the fields are able to be customized, but
that's still no good if it is offline dur
On Sun, 28 Sep 2008, Michael G Schwern wrote:
The former at least has the benefit of being a known quantity and once it
works, it always works. $VERSION scraping will always be a heuristic.
Well, in this particular case, Module::Build would be scraping for one
module's version, and that is i
On Wed, 5 Dec 2007, Eric Wilhelm wrote:
Something to do with the version sub and/or the compat layer?
I got a similar report from this Alex for a module of mine on Perl 5.005,
and I also used the passthrough Makefile.PL.
However, looking at where it's failing my guess is that the code just
a hardship. I
can see that the OP has entered another bug:
https://rt.cpan.org/Public/Bug/Display.html?id=27208
where Dave Rolsky responded much as I did.
Yeah, this was a very frustrating exchange.
I _still_ am not sure I understand the core problem.
To say it in my own words, t
Please stop cc'ing the [EMAIL PROTECTED] address for this
thread. I'm trying to keep that ticket closed, since this is a problem
with Module::Build only.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's
Arround line 4000 of the 0.2806 release, it assumes that $ENV{PERL5LIB} is
defined, but for me it's not, so I get some undef warnings with things
like "Build dist". Easy enough to fix, I think.
-dave
/*===
VegGuide.Orgwww
On Sun, 1 Oct 2006, Adam Kennedy wrote:
The "right" solution is the same one as mentioned before... that the
codebases of CPAN and Module::Build shouldn't be bleading into each other,
that the CPAN client and the module installer should remain seperate and
communicate by some sort of other mec
In newer versions of CPAN.pm which support Module::Build, there appears to
be a bug when dealing with a module that has a custom build module. I saw
this trying to install HTML::Mason with the cpan shell.
The bug comes about because of the CPAN::Distribution::prereq_pm() method.
It has the fol
12 matches
Mail list logo
