Re: Possible bug?
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 problem with the bioperl code, but Andreas indicated that lack of a module version probably should not default to '0'. Any reason this is occurring? Meta 2.0 is quite clear it should be absent if no version is detected. Actually that is what Module::Build appears to be trying to do, I'm not sure why it fails. Could we please get a minimal test case that demonstrates the error? Or even just a repo URL for the code in question? Thanks, David
Re: Possible bug?
On Oct 18, 2011, at 8:29 AM, David Golden wrote: 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 problem with the bioperl code, but Andreas indicated that lack of a module version probably should not default to '0'. Any reason this is occurring? Meta 2.0 is quite clear it should be absent if no version is detected. Actually that is what Module::Build appears to be trying to do, I'm not sure why it fails. Could we please get a minimal test case that demonstrates the error? Or even just a repo URL for the code in question? 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. Thanks, David chris
Re: Possible bug?
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 load the bioperl dependency chain and see it directly. :-) I have two reactions: (a) Module::Build is doing it wrong -- in that it will normalize an undefined version to 0 and leave it in. The CPAN::Meta::Spec v2 says that the version metadata should only exist if a $VERSION string exists, but Module::Build does not produce v2 metadata and the v1.4 spec doesn't say anything about the subkeys of provides. (b) PAUSE is being too nitpicky. An undefined $VERSION is effectively treated as a 0 in code, so it doesn't really matter too much if the metadata says 0 or omits the key. Nevertheless, in a battle between M::B and PAUSE, clearly PAUSE should win. (I get to wear both hats: I'm PAUSE admin *and* M::B co/ex-maintainer, so I'm indifferent.) I'll commit a fix to the repo and if/when a new M::B maintainer volunteers (or I'm forced by p5p to do another release), then it will go live. I do encourage adding $VERSION to the bioperl code (it looks like you're heading down the dzil route -- which can solve that for you). -- David
Re: Is that possible?
On Mon, Sep 22, 2008 at 5:09 AM, Torsten Foertsch [EMAIL PROTECTED] wrote: By the way, you haven't answered my initial question. What is the right way to do that in M::B? This is Perl, so TIMTOWTDI. Personally, I generally only override ACTION_ subroutines. If I need code from a private subroutine, I cut/paste it. That insulates me from future M::B changes to internal functions. I have dozens of modules that generate external .pod files from simpler markup in the .pm files. If you look at http://search.cpan.org/dist/Pod-WikiDoc/ and read the Pod::WikiDoc::Cookbook file, you'll see an example of a Build.PL that creates a subclass to do this. However, rather than do that in Build.PL itself, I now usually create the subclass in inc/Module/Build/WikiDoc.pm and just load that from Build.PL. That keeps my Build.PL uncluttered. You can see an example of how I do that in http://search.cpan.org/dist/CPAN-Mini-Devel/ -- David
Re: Is that possible?
On Sat 20 Sep 2008, Adam Kennedy wrote: The existance of gzip on the system shouldn't really be assumed. Yes, but I need gzip only for ./Build dist and that is what I as the author do. And I have control over my environment. I find the default behavior annoying. When the gz file already exists gzip without -f asks do you really want to do that? On Fri 19 Sep 2008, Michael G Schwern wrote: * create a README file during ./Build dist using the mk_README.sh script and Override create_readme() I think. That was actually do_create_readme. However, in my case it was easier to override _main_docfile. * add the equivalent of a make target to create an RPM Just write an ACTION_rpm() in your subclass. That works. Thanks to both of you, Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: Is that possible?
On Sat, Sep 20, 2008 at 1:25 PM, Torsten Foertsch [EMAIL PROTECTED] wrote: Override create_readme() I think. That was actually do_create_readme. However, in my case it was easier to override _main_docfile. But _main_docfile() is a private undocumented method, which can (and very very likely will) change or disappear in future releases of M::B. It's fine with me if you override it, but be aware that you're way into unsupported-land. -Ken
Re: Is that possible?
On Sep 21, 2008, at 18:11, Ken Williams wrote: That was actually do_create_readme. However, in my case it was easier to override _main_docfile. But _main_docfile() is a private undocumented method, which can (and very very likely will) change or disappear in future releases of M::B. It's fine with me if you override it, but be aware that you're way into unsupported-land. Frankly, there are a lot of private, undocumented methods that I would like to see made public and documented. Just taking a quick look, these methods look to me like they'd be useful as public, override- able methods: _backticks() _pod_parse() _write_data() _enum_prereqs() _home_dir() _find_by_file_type() _find_pods() _add_to_manifest() _do_in_dir() _main_docfile() _write_default_maniskip() _files_in() _read_manifest() _resolve_module_versions() _relpaths() Some of these I've overridden, some I have not. Maybe some should stay private, but surely for others there's no harm in making them public, yes? Best, David
Is that possible?
Hi,
I am making my first steps with Module::Build. Maybe I haven't read the
large amount of docs thoroughly enough. But how do I say something like
the following to Module::Build?
dist = {
PREOP = './mk_README.sh',
COMPRESS = 'gzip -9f',
},
...
sub MY::postamble {
return 'EOF';
rpm: dist
$(PERL) -i -pe 's/^(Version:\s*).*/$${1}$(VERSION)/'
perl-IO-Handle-Record.spec
rpmbuild -ba perl-IO-Handle-Record.spec
EOF
}
I want it to do 3 things:
* use gzip -9f instead of simple gzip
* create a README file during ./Build dist using the mk_README.sh
script and
* add the equivalent of a make target to create an RPM
Is that possible?
For the first problem I found a workaround. gzip respects the GZIP
environment variable. So I subclass Module::Build:
use strict;
use warnings;
use Module::Build;
my $builder = Module::Build-subclass
(
code = q{
$ENV{GZIP}='-9f';
},
)-new
(
...
);
$builder-create_build_script();
Is that the way to do it? I believe there must be a better way!
Please CC replies to me since I am not subscribed.
Thanks,
Torsten
--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]
Re: Is that possible?
Torsten Foertsch wrote: I want it to do 3 things: * use gzip -9f instead of simple gzip There appear to be undocumented gzip and tar flags. I'd stick with what you've got. * create a README file during ./Build dist using the mk_README.sh script and Override create_readme() I think. * add the equivalent of a make target to create an RPM Just write an ACTION_rpm() in your subclass. -- 7. Not allowed to add In accordance with the prophesy to the end of answers I give to a question an officer asks me. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
optional_features possible?
I currently have a setup like:
my $build = Module::Build-new(
#...
recommends = {'Module' = 0}
)
I can then use ./Build distmeta to generate a META.yml file with content
like:
requires:
Module: 0
Is it possible to get Module::Build to generate the optional_features
syntax instead? So I want:
optional_features:
- foo:
description: Provides the ability to blah.
requires:
Module: 0
Also, where can I find full documentation for all of the methods
available? Eg. I couldn't find anything that even told me all the
possible options you can supply to Module::Build-new(), having looked
in these places:
http://search.cpan.org/~kwilliams/Module-Build-0.2805/lib/Module/Build.pm
http://search.cpan.org/~kwilliams/Module-Build-0.2805/lib/Module/Build/Authoring.pod
http://search.cpan.org/~kwilliams/Module-Build-0.2805/lib/Module/Build/Cookbook.pm
http://search.cpan.org/~kwilliams/Module-Build-0.2805/lib/Module/Build/Compat.pm
So far I've just looked through the code of Module/Build/Base.pm to
guess what I should be able to do, which isn't ideal.
