On Sat, Feb 4, 2012 at 5:17 PM, Adam Kennedy a...@ali.as wrote:
That's how Module::Install's requires_from does it too.
I should look at zilla's code and see how it runs, might be worth
aligning M:I and it's detection.
It uses Ricardo's Perl::PrereqScanner, which does a pretty sane job of
it
On Sat, Feb 4, 2012 at 9:43 PM, Adam Kennedy a...@ali.as wrote:
If the goal is only to pick up versioned dependencies, I'm surprised
we even need to bother with that.
It picks up as many standard dependencies as it can, but treats
anything without a version as requesting version 0.
-- David
On Sat, Feb 4, 2012 at 9:51 PM, Adam Kennedy a...@ali.as wrote:
I was thinking about dropping anything without a specific numberic
version completely and requiring manual, because I figure the chances
for misidentification is too high (whereas a number will only really
be there after a human
On Wed, Dec 14, 2011 at 10:25 AM, Phil Kasten pskas...@gmail.com wrote:
I am using the cpan tool to install modules on a FreeBSD system that I do
not have root permission on. I have a provided a PREFIX for the makepl_arg,
to install everything in my local path. Almost everything works fine.
I'm very, very pleased to announce that Leon Timmermans has
volunteered to be the new M::B patch/release manager and received his
co-maint bit today.
Leon has been working on abstracting the Build.PL API through his work
on Module::Build::Tiny and has gotten very familiar with the guts of
On Oct 18, 2011 3:39 AM, Leon Timmermans faw...@gmail.com wrote:
On Mon, Oct 17, 2011 at 5:08 AM, Fields, Christopher J
cjfie...@illinois.edu wrote:
This appears to be due to the version for the modules being set to '0'
in META.yml/json instead of not being defined (yes, we know this is a
On Tue, Oct 18, 2011 at 9:36 AM, Fields, Christopher J
cjfie...@illinois.edu wrote:
https://github.com/bioperl/bioperl-network
I can work on a minimal test case. If needed I can also fork the specific
github code and try to weed out the problem.
No need to do the test case. I was able to
On Wed, Mar 16, 2011 at 7:52 PM, Ron Savage r...@savage.net.au wrote:
Hi Folks
I've just started to get the warning msg in the Subject.
I assume it's a side-effect of V 0.3800.
I could not see any reference to a provides key in the docs for M::B,
nor via googling, altho I assume it goes in
to speak up and volunteer to take on
the release manager role.
Regards,
David Golden
2011/1/26 Alberto Simões al...@alfarrabio.di.uminho.pt:
Hello
Is there any action that I can subclass in mybuilder that is run during
perl Build.PL ?
Not really. You can subclass new or any of the methods that it
calls, of course.
What are you trying to accomplish?
-- David
As part of my campaign to eliminate redundancies, I've started on the following:
* Deprecating Module::Build::ModuleInfo in favor of Module::Metadata,
which mst extracted into its own dist so it could be used by EU:MM and
other toolchain modules.
* Deprecating Module::Build::Version in favor of
2010/6/14 Alberto Simões al...@alfarrabio.di.uminho.pt:
Unfortunately Build --debug is too laconic :) it just hows ACTION_code.
There isn't any way to force a more in-depth trace?
Only the normal perl approaches. (e.g. perl -D with a debugging perl)
(Though I'd welcome patches that improve
2010/6/8 Alberto Simões al...@alfarrabio.di.uminho.pt:
Hello
Anybody can confirm this, from a module user, that was asking me to
include some build dependencies in the module tarball?
My motivation is asking this comes
from the fact that not a few users had a problem similar to this one:
On Thu, Jun 3, 2010 at 3:38 PM, Seth Daniel
perl-module-bu...@sethdaniel.org wrote:
I've been using Module::Build for several years. Typically subclassing
it to help build a module. I read with interest David Golden's blog post
about Dist::Zilla:
If you could please send me a new patch (or a git pull request), I'll
apply it to the repo.
Thanks,
David
On Thu, May 27, 2010 at 10:11 PM, Elliot Shank p...@galumph.com wrote:
On 5/27/10 2:37 PM, Eric Wilhelm wrote:
# from Elliot Shank
# on Thursday 27 May 2010 05:46:
it uses Storable,
On Sat, May 1, 2010 at 9:23 PM, Michael G Schwern schw...@pobox.com wrote:
I say no_index should influence the generation of provides, yes?
+1
The new CPAN::Meta package has methods for determining if particular
packages should be indexed or not given a no_index. As we convert
M::B to use
On Sat, May 1, 2010 at 2:12 PM, Michael G Schwern schw...@pobox.com wrote:
I've just written Object-ID which contains UNIVERSAL::Object::ID. This
contains the code:
package UNIVERSAL;
use Object::ID;
Module::Build sees that and adds UNIVERSAL to the provides info in META.yml.
Ok, I
I'm looking to see if we can make the generated one temporary easily.
David
On Fri, Apr 16, 2010 at 10:53 AM, Curtis Jewell
p...@csjewell.fastmail.us wrote:
And if people really need a skeleton MANIFEST.SKIP, we can add Build
manifest_skip to generate a default one (that then persists)
--
Now that Module-Build has migrated to git and is hosted on github,
there are several options for post-commit hooks to post commits to
various channels.
Here's a list of what's available:
* Post-Receive URLs (0)
* Basecamp
* CIA
* Campfire
* Email
* FogBugz
* Freckle
Pushed to the repo the following changes:
* When generating MANIFEST.SKIP for distcheck, it will be removed
immediately when the action is completed. (This means that
subsequently added MANIFEST.SKIP will not be deleted during clean.)
* Added Build manifest_skip to generate one permanently if
On Fri, Apr 16, 2010 at 6:01 PM, Curtis Jewell
p...@csjewell.fastmail.us wrote:
I'd like to see, at a minimum, a Twitter feed and some sort of IRC
notification. After that, hmmm...
What IRC channel? #toolchain? Something more specific to Module::Build?
-- David
On Thu, Apr 15, 2010 at 4:57 AM, Steffen Schwigon s...@renormalist.net wrote:
Hi!
I did not expect that my MANIFEST.SKIP file (either self-written or
auto-generated) gets deleted during ./Build distclean.
What is the rationale behind that?
I couldn't read that out of the documentation.
The
On Wed, Apr 14, 2010 at 2:25 AM, Klaus Eichner via RT
bug-module-bu...@rt.cpan.org wrote:
Now that Perl 5.12 is out,
can we discuss the changes to Module::Build::Base (and a new module
ActivePerl::PPM::InstallHist) ? as per the attachment -- two files
'Base.36032.pm' and 'InstallHist.00100.pm'
I have completed a migration of the Module::Build repository from
Subversion to git.
The new repository is available publicly on github.com:
* browse it: http://github.com/dagolden/module-build/
* clone it: git://github.com/dagolden/module-build.git
I have done my best to clean up the
On Sat, Mar 27, 2010 at 7:25 AM, Gabor Szabo szab...@gmail.com wrote:
I am now trying to get Bugzilla packaged to CPAN and it is explicitely
licensed
under mozilla1.1
Would it be possible to add those two keys to the valid list of values
of the license field?
Software::License
On Sat, Mar 27, 2010 at 7:45 AM, Gabor Szabo szab...@gmail.com wrote:
That's what I did but I expect some arguments from the core Bugzilla
developers
and their lawyers. I'll use your point if needed. Thanks
The license field in Module::Build just sets the same field in
META.yml. If they
I'm going to step *way* back in this discussion. I've been able to
replicate the issue, which is the first step to finding a thoughtful
resolution:
(1) All prerequisites to actually run the signature test file are
satisfied. (E.g. $ENV{TEST_SIGNATURE}, etc.
(2) MANIFEST.SKIP is in MANIFEST.SKIP
On Tue, Feb 23, 2010 at 6:54 PM, Eric Wilhelm enoba...@gmail.com wrote:
We've run into a Build.PL vs Makefile.PL problem with cpanminus. The
situation is that if M::B requires anything with a Build.PL file, that
it becomes impossible to bootstrap.
We should remove Build.PL from anything that
On Mon, Feb 22, 2010 at 10:36 PM, Michael G Schwern schw...@pobox.com wrote:
Eric Wilhelm wrote:
$master:~/cpan/perlids./Build disttest
Creating Makefile.PL
Creating META.yml
*File 'MANIFEST.SKIP' does not include 'MYMETA.yml'. Adding it now.*
...
*t/00-signature.t . Not in MANIFEST:
On Fri, Feb 19, 2010 at 4:14 PM, Michael G Schwern schw...@pobox.com wrote:
Hi,
I want to set a $VERSION for my whole project, same in every .pm file. I
used to just use a script that did some s/// but its gotten a bit more
complicated now that I'm using version.pm.
Is *not* using version.pm
2010/2/16 Alberto Simões al...@alfarrabio.di.uminho.pt:
OK, because there isn't a $builder-binary_files option or a
$builder-executable_files option :P
Long, sordid history here. This is more or less correct as a summary of it:
* Used to have a 'scripts' property that defaulted to the
2010/2/16 Alberto Simões al...@alfarrabio.di.uminho.pt:
Interested in a patch to add bin_files to Module::Build?
(not sure if I will be able to write it but I offer to try...)
I'd discuss the logic on the list first. On the one hand, I like it,
but on the other hand, explaining that
Alberto -- could you please send patches to the M::B RT queue? I've
been using that aggressively to triage and stage issues and it's very
helpful to make sure things don't get lost.
I'm very supportive of your changes, but I'm only doing critical M::B
patches at the moment as I'm very overloaded
2010/2/12 Alberto Simões al...@alfarrabio.di.uminho.pt:
Hello
Before, the question (later the history): I need to compile a library
that is pure C. I would like this process to be the more portable
possible (strawberry Perl is one of my targets).
Later, this library will be used to:
- be
Scott -- that sounds like a great analysis and bit of work. I'm not
doing any non-critical M::B patching at the moment, so could you
please add your comments and patch to the RT#53478 ticket so it
doesn't get lost?
Thanks,
David
On Tue, Jan 26, 2010 at 8:27 PM, Scott Renner sren...@comcast.net
I think we now say deprecated but because there are people in your
situation, I don't see actually removing it for a while -- like around the
time that 5.10 is standard and 5.8 is rare.
David
On Jan 24, 2010 9:15 AM, Marvin Humphrey mar...@rectangular.com wrote:
On Sat, Jan 23, 2010 at
distros for
the last few years, and they seem to have done what I needed them to do:
stop
Makefile.PL loyalists from taking up my time with complaints.
However, I recently saw this on cpan-testers-discuss from David Golden:
http://markmail.org/message/jzzobzsrgc6vi7tr
Module::Build::Compat
:
On Sun, 6 Dec 2009, David Golden wrote: This is Release Candidate 3.
Unless something pops up on...
I tested on OpenSolaris/x86, which ships with perl-5.8.4 as the default
system perl.
I noted one odd thing:
$ perl Build.PL
Checking prerequisites...
requires:
! ExtUtils::CBuilder
***
- The old API for prepare_metadata() has been restored to avoid breaking
distributions that were overriding it (e.g. BioPerl), but the method
has been marked deprecated and may be made private or may disappear in
some future version of Module::Build. [David Golden]
- A new get_metadata
On Sun, Dec 6, 2009 at 11:29 PM, Craig A. Berry craig.a.be...@gmail.com wrote:
Thanks for the heads up. Below is a quick build and test, which is
not all good news, but not entirely bad news either. This is just a
where we are post and I have not even looked at the test output in
any detail
On Wed, Dec 2, 2009 at 1:42 PM, Eric Wilhelm enoba...@gmail.com wrote:
This has triggered my semi-biyearly ponderance of plugins. I
think tools for authors should be doable outside of M::B. And/or
more easily customized than via subclassing, plus more easily shared
between distributions than
On Wed, Dec 2, 2009 at 6:17 PM, Eric Wilhelm enoba...@gmail.com wrote:
# from David Golden
# on Wednesday 02 December 2009 14:59:
Anyway, when that's done, I think I'll have a clearer sense of what in
M::B is really core and what is author support. That said,
plugins are probably not on my
On Thu, Nov 26, 2009 at 1:43 AM, Adam Kennedy
adamkennedybac...@gmail.com wrote:
Addition to David's reply, the use of xt was suggested as a
convenience (not as a requirement) that tools may or may not choose to
use to indicate tests that run during RELEASE_TESTING. They won't
define tests
On Tue, Nov 24, 2009 at 2:12 AM, Slaven Rezic sla...@rezic.de wrote:
I had setup a parallel smoker to find regressions between MB 0.35 and MB
0.35_09 on a perl 5.10.1 system.
So far the list of differences is this one (left is new MB, right is old
MB):
Bio-Chado-Schema-0.04300
On Tue, Nov 24, 2009 at 1:23 PM, Dave Rolsky auta...@urth.org wrote:
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?
The Oslo Consensus [1] agreed to
Golden]
- Fix compilation error in Module::Build::Platform::VMS (RT#51766)
[David Golden]
- Don't generate a MANIFEST.SKIP during distclean and add any generated
MANIFEST.SKIP to cleanup list [reported by Zefram, fixed by David Golden]
- Module::Build::ModuleInfo version parsing would
I found the problem and it should now be fixed in blead.
Unfortunately, too late for 5.11.2, but with a monthly release cycle,
we'll soon be back on track.
When dual-core modules moved to the cpan/ directory in the Perl source
tree, the idea was in part that updating them would be a matter of
On Fri, Nov 20, 2009 at 3:59 PM, Andreas J. Koenig
andreas.koenig.7os6v...@franz.ak.mind.de wrote:
Something is seriously broken in the combination of
bleadperl/Module::Build, I wonder why nobody has reported this problem
besides me (or have they). Please try out what I did:
No problems for
On Wed, Nov 18, 2009 at 4:29 AM, Chris 'BinGOs' Williams
ch...@bingosnet.co.uk wrote:
With the version of Module::Build installed on that smoker (0.35) the action
'prereq_data' should be
available for the toolchain to determine which prereqs have been defined in
the Build.PL
EekBoek bundles
Hello Module-Build and CPAN-Testers-Discuss.
Module::Build 0.35_06 has arrived on CPAN. This closes all all
Critical, Important and Normal bug tickets from RT that are not
stalled for upstream fixes. I consider it RC0 for 0.36 and aim to
have it added to bleadperl for inclusion in the
On Sat, Nov 14, 2009 at 11:39 AM, David E. Wheeler da...@kineticode.com wrote:
++dagolden Thanks! One note on the changes: I saw that you committed the
change in the detection of authors and the module name to ignore the case of
the =head1 tag, but I didn't see it in the Changes. Did I miss
Apparently, I accidentally uploaded an earlier tarball for 0.35_06
without some bug fixes. (I couldn't tell you how that happened).
Please test 0.35_07 instead. Sorry about that!
David
On Tue, Nov 10, 2009 at 2:06 PM, smanzer
sman...@chemistry.ohio-state.edu wrote:
I want the module to install to a
~/lib/ subfolder of my home directory. I have the following .modulebuildrc
file set up to do this:
install --install_base /Users/smanzer/
This installation method works if I
a YAML::Node object as an
argument for modification. The method now takes no arguments and just
returns a hash reference of metadata. [David Golden]
Enhancements
- Command line options may be set via the PERL_MB_OPT environment
variable (similar to PERL_MM_OPT in ExtUtils::MakeMaker
On Fri, Oct 2, 2009 at 2:31 PM, Christopher J. Madsen p...@cjmweb.net wrote:
3. Reconstruct the MB object. Tempting, but as brian d foy found, it's
not as simple as just calling Module::Build-resume.
It should be easy in most cases. brian was expecting Module::Build to
remember @INC at the
On Thu, Oct 1, 2009 at 1:26 PM, brian d foy brian.d@gmail.com wrote:
In article
5d4beb40909301455r6b9094d2t9e60597bdad67...@mail.gmail.com, David
Golden xda...@gmail.com wrote:
brian, is there any code you can share? Even some simplified examples of
what you want in code would help us
brian, is there any code you can share? Even some simplified examples of
what you want in code would help us give you a solution.
David
On Sep 30, 2009 11:54 PM, Eric Wilhelm enoba...@gmail.com wrote:
# from brian d foy
# on Tuesday 29 September 2009 17:19:
eval require $build_class; 1 or
With the responses to far to design questions favoring only messing
with inc/ in distdir, I've worked up a first-draft adapted from
Eric's code.
You can find it in the subversion branch:
http://svn.perl.org/modules/Module-Build/branches/inc-bundling
Here's what a Build.PL would look like
On Sat, Sep 12, 2009 at 12:57 AM, Ron Savage r...@savage.net.au wrote:
My concern is authors choosing to include a dev version of module, which
is in conflict with my policy of - as far as humanly possible - of never
installing a dev version. Simple!
Now what happens when they do that, and
12 13:41:02 2009
@@ -15,6 +15,8 @@
Other:
- Replaced use of YAML.pm with YAML::Tiny; Module::Build::YAML is now
based on YAML::Tiny as well [David Golden]
+ - Reduced amount of console output under normal operation (use --verbose
+ to see all output)
0.35_02 - Mon Sep 7 22:37:42 EDT 2009
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?
David
On Fri, Sep 11, 2009 at 2:03 PM, Dave Rolsky auta...@urth.org wrote:
In theory, it sounds good. I do wonder if this would require _always_
generating the manifest a the same time though.
I think the way it would work is that you wouldn't have those files in
your $src/MANIFEST, but when they are
On Fri, Sep 11, 2009 at 2:45 PM, Eric Wilhelm enoba...@gmail.com wrote:
I actually prefer to check-in the MANIFEST because that gives me a diff
each time it is generated, which catches bugs in MANIFEST.SKIP.
Otherwise, I guess I would have to somehow review what went into the
package and that
On Fri, Sep 11, 2009 at 8:07 PM, Ron Savage r...@savage.net.au wrote:
o Obviously module authors can just not implement anything based on this
new mechanism, but for those who do...
Nothing would happen by default. The idea is that if you replace use
Module::Build in your Build.PL with use
On Fri, Sep 11, 2009 at 10:11 PM, Ron Savage r...@savage.net.au wrote:
o Development releases: Can you guarantee (nothing personal :-) we won't
have another fiasco a la Data::Dumper (I think it was) a few years ago,
which seemed to have been officially released with a dev version number
On Fri, Sep 11, 2009 at 9:14 PM, Eric Wilhelm enoba...@gmail.com wrote:
I would rather that we do it without a net connection, or at least
ensure that it's the same combination of stuff that the author is
using. This is partly why I lean toward a .packlist-based scheme. You
can't really make
On Fri, Sep 11, 2009 at 10:42 PM, Eric Wilhelm enoba...@gmail.com wrote:
Like I said, ScanDeps/TraceDeps should work most of the time.
Devel::TraceDeps is very different from Module::ScanDeps. There's
no most of the time about it -- it tells you everything that got
loaded via require() or
Eric and I have had a intense off-list discussion over some design
issues for inc/ bundling. I suspect a number of our differences of
opinion may stem from different starting points or assumptions about
the design, so I'd like to step back, be structured in my thinking
about the issues and seek
And anything you bundle automatically goes in configure_requires.
Or perhaps the reverse -- anything you put in configure_requires would
be bundled.
No, because then we have to check whether you've got a
'use inc::latest ...' for each of those in Build.PL.
Let's just say that they need to be
On Tue, Sep 8, 2009 at 12:22 AM, Eric Wilhelmenoba...@gmail.com wrote:
But that leaves the possibility that your Build.PL won't have the
necessary code to load the version from inc/ -- thus my wanting to
trigger it by simply adding the use inc::latest 'Module::Build' line.
Then there needs to
Having looked at latest.pm (c.f. inc/latest.pm in the M::B source) I
have to say that I like it. How about 'newest.pm' as an alternate
name? (Apologies to rgs and ex::newest)
Getting the dwimmery to work is a bigger issue. There's a
quick-and-dirty way and there's a correct way. (And probably
On Tue, Sep 8, 2009 at 12:10 PM, John
Peacockjohn.peac...@havurah-software.org wrote:
I don't see #2 as necessarily being /more/ correct; the author has
[presumably] tested with the packages installed in the current Perl library
path. Putting potentially [untested] newer releases into the
On Wed, Sep 9, 2009 at 12:12 AM, Adam
Kennedyadamkennedybac...@gmail.com wrote:
I also think that blindly using a newer version of something without
knowing if it's compatible with the bundled one is asking for trouble.
But that's more a call to make sure a compatibility assurance
mechanism is
On Mon, Sep 7, 2009 at 2:15 AM, Eric Wilhelmenoba...@gmail.com wrote:
I would be very sad to see a runtime module requirement just to
declare some rarely-used meta info. Ditto for requiring a new Perl.
POD? Hell, no.
Why not? If it's properly specified and pod-renderable, things like the
On Mon, Sep 7, 2009 at 4:55 PM, David E. Wheelerda...@kineticode.com wrote:
On Sep 7, 2009, at 11:24 AM, Eric Wilhelm wrote:
https://svn.perl.org/modules/Module-Build/trunk/contrib/bundle.pl
What is missing is:
1) some interface to 1-step-setup the bundle,
2) detection/updating the
Change log:
0.35_02 - Mon Sep 7 22:37:42 EDT 2009
Enhancements:
- Added 'needs_compiler' property. Defaults to true if XS or c_source
exist. If true, ExtUtils::CBuilder is also added to build_requires.
[David Golden]
- File::ShareDir automatically added to 'requires' if 'share_dir
On Sun, Sep 6, 2009 at 2:39 AM, Eric Wilhelmenoba...@gmail.com wrote:
Drawbacks? It's assuming that # ALPHA is a comment -- but really what
sort of crazy stuff are you doing with the $VERSION line where
including the string # ALPHA in a non-alpha release is necessary and
not confusing?
It
What do people think about quieting more of the messages that
Module::Build prints to the terminal?
For example, there tends to be a lot of checking this... looks good,
checking that... looks good, Deleting this, Removed this, etc.
type messages.
I think we should try to make the overall
URL: https://rt.cpan.org/Ticket/Display.html?id=48918
Patched in repository trunk
On Mon, Aug 31, 2009 at 10:00 PM, Ron Savager...@savage.net.au wrote:
I want to ensure all files in the dir return the same version number, if
I print them using version.pm.
Assuming your *.pm files are in Module::Build distros...
perl -MModule::Build -E '$mb=Module::Build-new_from_context;
On Fri, Aug 28, 2009 at 2:22 AM, Eric Wilhelmenoba...@gmail.com wrote:
# from David Golden
# on Thursday 27 August 2009 19:08:
I think this END block is redundant given a temp dir with CLEANUP =
1.
remove() does a chdir out of the directory. That's important or the
tempdir can't be removed
URL: https://rt.cpan.org/Ticket/Display.html?id=48918
I'm bumping this to normal severity. Even if new features are needed
the behavior is a bug and we should fix it.
On Fri, Aug 28, 2009 at 11:36 AM, Eric Wilhelmenoba...@gmail.com wrote:
Of course, maybe what we really need is for DistGen to be able to create
the temp dir in the constructor, then call remove() from DESTROY.
Could have DistGen create a tmp dir that doesn't set CLEANUP and
records initial
On Fri, Aug 28, 2009 at 1:17 PM, Eric Wilhelmenoba...@gmail.com wrote:
Perhaps:
mbload('Module::Build');
mbload('Module::Build::YAML');
Make it a load and check, but not an actual Test:::More test? I'm ok with that.
David
protocol for
communicating configuration results between toolchain components)
[David Golden]
+ - Added 'share_dir' property top provide File::ShareDir support;
+ set automatically if a directory called 'share' exists
+ [David Golden]
Bug fixes:
- Fix the t/destinations.t fix. [David
On Thu, Aug 27, 2009 at 6:48 PM, Eric Wilhelmenoba...@gmail.com wrote:
# from dagol...@cvs.perl.org
# on Thursday 27 August 2009 14:08:
+ my $dist = DistGen-new( dir = MBTest-tmpdir );
+
+ # generate the skeleton files and also schedule cleanup
+ $dist-regen;
+ END{ $dist-remove }
I think
On Thu, Aug 27, 2009 at 6:39 PM, Eric Wilhelmenoba...@gmail.com wrote:
# from dagol...@cvs.perl.org
# on Tuesday 25 August 2009 13:30:
Log:
Fix t/destinations.t segfault on 5.6.2
- local $mb-install_sets-{site} = \%test_config;
+ my $old = $mb-install_sets-{site} = \%test_config;
...
+
I'm forwarding this commit message to the full Module::Build list as I
consider it a relative 'big' change with some degree of risk that
everyone needs to be aware of.
Please read the extensive log message. Anyone who knows this code
passably well, please skim the commit. Anyone who does any
On Wed, Aug 19, 2009 at 1:00 PM, David E. Wheelerda...@kineticode.com wrote:
This sounds completely reasonable to me. I've added a
[comment](http://github.com/SamuraiJack/module-build-jsan/commit/bb3842316052fdcf2240ca545f200b3745c724de#comment_27710)
to a GitHub commit to Module::Build::JSAN
On Mon, Aug 17, 2009 at 11:59 PM, Seth
Danielperl-module-bu...@sethdaniel.org wrote:
My suggested workaround is to fix the bug. That's not immediate,
however. Sorry.
Fair enough, but considering I have no idea why $self-_set_install_paths
was introduced to resume() I don't know that I'm the
On Mon, Aug 17, 2009 at 5:14 PM, Seth
Danielperl-module-bu...@sethdaniel.org wrote:
http://rt.cpan.org/Public/Bug/Display.html?id=43515
I have been bit by this bug. I use install_base_relpaths quite a bit in
my build system and Module::Build overwrites all these paths when the
'Build' script
Thanks, Ilya. Committed to the repository trunk.
David
On Sun, Aug 9, 2009 at 5:42 PM, Ilya Zakharevichnospam-ab...@ilyaz.org wrote:
A lot of thanks for maintaining Module::Build. The patches below make
it pass the test suite on OS/2, and make it not leave temporary dirs
in $TMP.
On Mon, Aug 10, 2009 at 2:56 PM, Adam
Kennedyadamkennedybac...@gmail.com wrote:
So if someone who owns one of the pieces of the toolchain says the REALLY
want something patched, it's usually for reasons like this. Because that
patch is 80% or 90% less useful if it's stuck outside.
I agree with
Unfortunately, the way Module::Build::PPMMaker is implemented, you
have to fix it afterwards.
To do this correctly, Module::Build::PPMMaker would need to access the
CPAN index files that map module names to distribution names. (the
02packages.details.txt.gz file in the modules/ directory of a
On Sun, Aug 9, 2009 at 12:47 AM, Adam
Kennedyadamkennedybac...@gmail.com wrote:
It says Please make sure a woefully antiquated version of M:B completely
insufficient for install this module is available.
The previous stable release is better, but ignores any use of new dev
features.
On Sun, Aug 9, 2009 at 4:02 PM, Eric Wilhelmenoba...@gmail.com wrote:
For a less-fiddly automatic setting of configure_requires, we might want
to have a table of named features mapped to version numbers. But I
would still use alpha numbers in that table - just warn the user during
of M::B. That fixes this problem and ensures 5.10.1 is not
broken for M::B module authors on release.
David
On Aug 9, 2009 7:28 PM, Dave Mitchell da...@iabyn.com wrote:
On Sat, Aug 08, 2009 at 11:41:08AM -0400, David Golden wrote: It wouldn't
be the first time a dev ...
Well, I've understood
File::ShareDir support is something I'd like to add to the Module::Build
core. I just haven't had time to work on it.
I suspect it requires:
* adding a share_dir property
* adding an ACTION_share_dir routine (that does nothing if sharedir is
undef) to copy things to the right spots in blib
*
On Sat, Aug 8, 2009 at 11:35 AM, Elliot Shankp...@galumph.com wrote:
David Golden wrote:
(3) You built and released a non-dev Perl::Critic using a dev
Module::Build
#3 is... um... unwise. I'll leave it at that, but appreciate your
vote of confidence in M::B dev releases. ;-)
Well, I
With Ken's permission, I have migrated the ExtUtils::CBuilder
repository from svn.perl.org to github.com.
http://github.com/dagolden/extutils-cbuilder/tree/master
git://github.com/dagolden/extutils-cbuilder.git
Please use this repository for any future contributions.
If there are any questions
1 - 100 of 279 matches
Mail list logo
