Thread: [Module-build-general] no prereq detection with Module::Build->dispatch
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Jos I. B. <ka...@xs...> - 2003-09-12 14:39:36
|
Hi, i'm trying to add proper module::build support for CPANPLUS, but
i'm getting quite confused by the docs. On top of that, i think i've
run into a bug:
[kane@coke ~...Perl/mb_test]$ cat mb.pl
use Module::Build;
use Data::Dumper;
chdir 'Class-DBI-ToSax-0.09';
my $m = new Module::Build (module_name => 'Class::DBI::ToSax' );
$m->dispatch('build');
print Dumper $m->{properties};
[kane@coke ~...Perl/mb_test]$ perlc mb.pl
Checking whether your kit is complete...
Looks good
$VAR1 = {
'script_files' => [],
'build_script' => 'Build',
'perl' => '/opt/perl/bin/perl',
'build_requires' => {},
'dist_name' => 'Class-DBI-ToSax',
'base_dir' =>
'/Users/kane/Documents/Perl/mb_test/Class-DBI-ToSax-0.09',
'module_name' => 'Class::DBI::ToSax',
'conflicts' => {},
'requires' => {},
'recommends' => {},
'config_dir' => '_build',
'dist_version_from' => 'lib/Class/DBI/ToSax.pm',
'dist_version' => '0.09'
};
as you can see, it's not detecting any prerequisites...
however, seeing the Build.PL:
Module::Build->new(
module_name => 'Class::DBI::ToSax', license => 'perl',
requires => {
# Bug in 5.6.0 isa()...
'perl' => '5.6.1',
'Test::More' => 0,
# Both of these are required by Class::DBI, so shouldn't be too
# onerous...
'Class::Accessor' => 0,
'Class::Data::Inheritable' => 0,
# DCONWAY rocks.
'NEXT' => 0,
# Most people will want this and it's good for testing.
'XML::SAX::Writer' => 0,
},
)->create_build_script;
i've tried this for a few more modules, but none of them come up with
the prereqs.
A few more questions though.
* With a normal installation, one would do:
perl Build.PL
perl Build
perl Build test
perl Build install
this translates to the following dispatch table:
build
test
install
what action for 'dispatch' is equivalent to 'perl Build.PL' ?
is that the new call? i don't see that documented....
* Is there a nicer way to get the prereqs out of the $m object, rather
than poking into it?
--
Jos Boumans
"You know you are never more indignant in life than when you're
shopping at a store you feel is beneath you and one of the other
customers mistakes you for one of the employees of that store."
- Dennis Miller
CPANPLUS http://cpanplus.sf.net
|
|
From: Ken W. <ke...@ma...> - 2003-09-12 18:16:46
|
Hey Jos,
It's not a bug, but you can't actually do what you want to do yet, at
least not very easily. Of course, what you want to do would be useful.
I'm working on a couple small patches to M::B that should get it to
work in an even simpler way. You'll essentially end up doing something
like this:
chdir("whatever/mb_test/");
my $build = Module::Build->new_from_context();
$build->dispatch('build');
$build->dispatch('test');
$build->dispatch('install');
Still not sure the best name for the new_from_context() method. Its
purpose is to look at the META.yml file, then run the Build.PL script
if necessary (non-interactive builds won't require it), and return a
M::B object the user can act on.
-Ken
On Friday, September 12, 2003, at 09:35 AM, Jos I. Boumans wrote:
> Hi, i'm trying to add proper module::build support for CPANPLUS, but
> i'm getting quite confused by the docs. On top of that, i think i've
> run into a bug:
>
> [kane@coke ~...Perl/mb_test]$ cat mb.pl
> use Module::Build;
> use Data::Dumper;
> chdir 'Class-DBI-ToSax-0.09';
> my $m = new Module::Build (module_name => 'Class::DBI::ToSax' );
> $m->dispatch('build');
> print Dumper $m->{properties};
>
> [kane@coke ~...Perl/mb_test]$ perlc mb.pl
> Checking whether your kit is complete...
> Looks good
> $VAR1 = {
> 'script_files' => [],
> 'build_script' => 'Build',
> 'perl' => '/opt/perl/bin/perl',
> 'build_requires' => {},
> 'dist_name' => 'Class-DBI-ToSax',
> 'base_dir' =>
> '/Users/kane/Documents/Perl/mb_test/Class-DBI-ToSax-0.09',
> 'module_name' => 'Class::DBI::ToSax',
> 'conflicts' => {},
> 'requires' => {},
> 'recommends' => {},
> 'config_dir' => '_build',
> 'dist_version_from' => 'lib/Class/DBI/ToSax.pm',
> 'dist_version' => '0.09'
> };
>
> as you can see, it's not detecting any prerequisites...
> however, seeing the Build.PL:
>
> Module::Build->new(
> module_name => 'Class::DBI::ToSax', license => 'perl',
> requires => {
> # Bug in 5.6.0 isa()...
> 'perl' => '5.6.1',
> 'Test::More' => 0,
> # Both of these are required by Class::DBI, so shouldn't be too
> # onerous...
> 'Class::Accessor' => 0,
> 'Class::Data::Inheritable' => 0,
> # DCONWAY rocks.
> 'NEXT' => 0,
> # Most people will want this and it's good for testing.
> 'XML::SAX::Writer' => 0,
> },
> )->create_build_script;
>
> i've tried this for a few more modules, but none of them come up with
> the prereqs.
>
> A few more questions though.
> * With a normal installation, one would do:
> perl Build.PL
> perl Build
> perl Build test
> perl Build install
>
> this translates to the following dispatch table:
> build
> test
> install
>
> what action for 'dispatch' is equivalent to 'perl Build.PL' ?
> is that the new call? i don't see that documented....
>
> * Is there a nicer way to get the prereqs out of the $m object, rather
> than poking into it?
>
>
> --
>
> Jos Boumans
>
> "You know you are never more indignant in life than when you're
> shopping at a store you feel is beneath you and one of the other
> customers mistakes you for one of the employees of that store."
> - Dennis Miller
>
> CPANPLUS http://cpanplus.sf.net
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: Ken W. <ke...@ma...> - 2003-09-12 18:19:11
|
On Friday, September 12, 2003, at 09:35 AM, Jos I. Boumans wrote: > > * Is there a nicer way to get the prereqs out of the $m object, rather > than poking into it? Try the prereq_failures() method - or do you need more than just the unfulfilled prereqs? -Ken |
|
From: Jos I. B. <ka...@xs...> - 2003-12-08 13:58:27
|
On 12-sep-03, at 20:19, Ken Williams wrote: > On Friday, September 12, 2003, at 09:35 AM, Jos I. Boumans wrote: >> >> * Is there a nicer way to get the prereqs out of the $m object, >> rather than poking into it? > > Try the prereq_failures() method - or do you need more than just the > unfulfilled prereqs? just a reminder -- for proper integration with the cpanplus build process, i need the dispatch methods to work properly, as well as a full listing of prereqs (not just the failed ones). I've mentioned this already some time ago, but then radio silence occurred... -- Jos Boumans "We are not far from the kind of moral decay that has brought on the fall of other nations and peoples" - Senator Barry Goldwater, 1964 CPANPLUS http://cpanplus.sf.net |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-08 19:40:45
|
On 12/8/2003 8:58 AM, Jos I. Boumans wrote: > > On 12-sep-03, at 20:19, Ken Williams wrote: > >> On Friday, September 12, 2003, at 09:35 AM, Jos I. Boumans wrote: >> >>> >>> * Is there a nicer way to get the prereqs out of the $m object, >>> rather than poking into it? >> >> >> Try the prereq_failures() method - or do you need more than just the >> unfulfilled prereqs? > > > just a reminder -- for proper integration with the cpanplus build > process, i need the dispatch methods to work properly, as well as a full > listing of prereqs (not just the failed ones). > > I've mentioned this already some time ago, but then radio silence > occurred... > Just curious, but why does CPANPLUS need a list of all prereqs and not just the failed ones? And in what way are the dispatch methods not working properly? I didn't see this explained in previous messages. Thanks, Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-09 03:21:43
|
On Monday, December 8, 2003, at 01:40 PM, Randy W. Sims wrote: > > Just curious, but why does CPANPLUS need a list of all prereqs and not > just the failed ones? It would be nice if we could just tell CPANPLUS the failures, because then CPANPLUS wouldn't have to know how to parse the version dependency specifications. > And in what way are the dispatch methods not working properly? I > didn't see this explained in previous messages. I think it's just that new_from_context() doesn't have a stable name yet, right Jos? I think that if nobody can think of a more appropriate name, we should just ratify the current one. -Ken |
Thanks for helping keep SourceForge clean.
X