module-build-general Mailing List for Module::Build (Page 18)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ken W. <ke...@ma...> - 2006-03-13 21:59:22
|
BTW, is there a regression test that could have exposed this issue?
-Ken
On Mar 12, 2006, at 7:37 PM, Ken Williams wrote:
> Thanks Craig. Yup, CBuilder is separately maintained, the nexus
> for development is often the Module::Build list.
>
> I'll apply this patch and make a new release.
>
> -Ken
>
>
> On Mar 12, 2006, at 6:01 PM, Craig A. Berry wrote:
>
>> The attached provides the special handling needed for C compiler
>> defines
>> in ExtUtils::CBuilder. This is against blead but I'm hoping the right
>> number after -p supplied to patch will apply cleanly to the CPAN
>> version
>> (which is separately maintained, right?).
>> --- lib/ExtUtils/CBuilder/Platform/VMS.pm;-0 Wed Sep 28 19:54:07 2005
>> +++ lib/ExtUtils/CBuilder/Platform/VMS.pm Sat Mar 11 17:53:09 2006
>> @@ -9,6 +9,21 @@ $VERSION = '0.12';
>>
>> sub need_prelink { 0 }
>>
>> +sub arg_defines {
>> + my ($self, %args) = @_;
>> +
>> + s/"/""/g foreach values %args;
>> +
>> + my $config_defines = '';
>> +
>> + # VMS can only have one define qualifier; add the one from
>> config, if any.
>> + if ($self->{config}{ccflags} =~ s{/def[^=]+(?:=)+(?:\()?([^\/\)]
>> *)} {}i) {
>> + $config_defines = "$1,";
>> + }
>> +
>> + return ('/define=(' . $config_defines . join(',', map "\"$_=
>> $args{$_}\"", keys %args) . ')');
>> +}
>> +
>> sub arg_include_dirs {
>> my ($self, @dirs) = @_;
>>
>
|
|
From: Randy W. S. <ml...@th...> - 2006-03-13 12:15:46
|
Randy W. Sims wrote:
> Unfortunately, I don't have a broken system to test on so I'm mostly
> guessing. I do have an old 633 Mhz Pentium PC laying around somewhere
> that I can install one of the BSD variant on tonight or tomorrow.
I've been taking my time getting my BSD test system up because I was
assuming from previous reports that the BSD issue was mostly fixed. I
finally got it up and configured enough to do some testing, and it looks
like there are still failures because of the same issue, mostly.
The attached patch is my rough working code to get it fixed.
Module::Build::Base::_perl_is_same needs to set @INC in order to find
Config.pm when $ENV{PERL_CORE}. Is there a better alternative?
ExtUtils::CBuilder::Base::perl_src needs to check in the current
directory before moving up. Well, maybe. This really is just a result of
the way I rewrote Module::Build::Base::find_perl_interpreter to collect
a list of /all/ candidates before testing for the correct one. If $perl
and $abs_perl where tested and successful, we could return before the
call to perl_src(). It's not really a problem except for the spurious
warning about not find the perl source.
This is tested on FreeBSD 6.0 & Ubuntu Linux. I'll test later on Windows
& Cygwin.
Randy.
|
|
From: Ishigaki K. <ish...@tc...> - 2006-03-13 09:04:44
|
Hi, I upgraded M::B recently and found a warning on YAML_support.
Certainly YAML did something nasty while it was 0.50 to 0.54
(with Spiffy things), but current YAML ( > 0.55) seems to be
nothing wrong with M::B. So, this patch would work fine for us.
Regards,
Kenichi Ishigaki
--- Build.pl Fri Mar 3 13:29:16 2006
+++ Build_patch.pl Mon Mar 13 17:33:01 2006
@@ -45,7 +45,7 @@
YAML_support =>
{
description => "Can write fully-functional META.yml files",
- requires => { YAML => ' >= 0.35, < 0.49 ' },
+ requires => { YAML => '>= 0.35, != 0.50, != 0.51, != 0.52, != 0.53, != 0.54' },
},
},
|
|
From: Ken W. <ke...@ma...> - 2006-03-13 01:37:29
|
Thanks Craig. Yup, CBuilder is separately maintained, the nexus for
development is often the Module::Build list.
I'll apply this patch and make a new release.
-Ken
On Mar 12, 2006, at 6:01 PM, Craig A. Berry wrote:
> The attached provides the special handling needed for C compiler
> defines
> in ExtUtils::CBuilder. This is against blead but I'm hoping the right
> number after -p supplied to patch will apply cleanly to the CPAN
> version
> (which is separately maintained, right?).
> --- lib/ExtUtils/CBuilder/Platform/VMS.pm;-0 Wed Sep 28 19:54:07 2005
> +++ lib/ExtUtils/CBuilder/Platform/VMS.pm Sat Mar 11 17:53:09 2006
> @@ -9,6 +9,21 @@ $VERSION = '0.12';
>
> sub need_prelink { 0 }
>
> +sub arg_defines {
> + my ($self, %args) = @_;
> +
> + s/"/""/g foreach values %args;
> +
> + my $config_defines = '';
> +
> + # VMS can only have one define qualifier; add the one from
> config, if any.
> + if ($self->{config}{ccflags} =~ s{/def[^=]+(?:=)+(?:\()?([^\/\)]
> *)} {}i) {
> + $config_defines = "$1,";
> + }
> +
> + return ('/define=(' . $config_defines . join(',', map "\"$_=$args
> {$_}\"", keys %args) . ')');
> +}
> +
> sub arg_include_dirs {
> my ($self, @dirs) = @_;
>
|
|
From: Randy W. S. <ml...@th...> - 2006-03-12 08:02:21
|
Ken Williams wrote: > Hi, > > I've just released M::B 0.27_09 with the following changes. In > particular, when I use this copy of Module/Build.pm in bleadperl, all > the M::B-related tests now pass (though with considerable complaining). > > > 0.27_09 Sat Mar 11 22:48:54 EST 2006 Attached is a patch against bleed. Randy. |
|
From: Ken W. <ke...@ma...> - 2006-03-12 04:04:29
|
Hi,
I've just released M::B 0.27_09 with the following changes. In
particular, when I use this copy of Module/Build.pm in bleadperl, all
the M::B-related tests now pass (though with considerable complaining).
0.27_09 Sat Mar 11 22:48:54 EST 2006
- Fixed find_perl_interpreter() so we can find the perl executable
when running from uninstalled perl even when $^X contains a
relative path. [Yitzchak Scott-Thoennes]
- Fixed warning message where we were printing the wrong field names.
[Chris Dolan]
- Added a 'testpodcoverage' action that runs a POD coverage check for
all modules in the distribution. [Yanick Champoux]
- Added a Cookbook example of subclassing to modify an action. [Dylan
Martin and David Golden]
- When building HTML documentation, we were opening the POD file and
not checking whether the open succeeded, which of course caused
problems down the line if it failed. Now we do "or die(...)" like
everywhere else. [Spotted by Joerg Braun]
-Ken
|
|
From: Ken W. <ke...@ma...> - 2006-03-12 03:31:32
|
On Mar 10, 2006, at 9:13 PM, Peter Scott wrote: > What wasn't obvious until I spent some time doing it wrong was that > the config.yml above *must* be in a subdirectory called 'yml'. I > had initially called it 'etc' and finally hauled out the debugger > which led me to where the code does > > my $localdir = File::Spec->catdir( $blib, $type ); Yeah, that's kind of a David-specific thing. =) He was working on getting the whole contents of a directory $foo/ installed into $install_base/$foo/ . -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-12 03:29:06
|
On Mar 9, 2006, at 4:53 AM, Paul Marquess wrote: > > The patch to C::Z earlier this week moved a pile of files around. > If you > didn't specify the "--delete" option when you rsync the blead you > end up > with multiple copies of some of these files. Thanks for letting me know. My rsync fu wasn't strong enough to get --delete to work, but just deleting that part of the file tree and resyncing did the trick. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-12 03:27:40
|
On Mar 9, 2006, at 3:34 PM, Graham Barr wrote: > Look at the example in the docs > > resources: > license: http://dev.perl.org/licenses/ > homepage: http://sourceforge.net/projects/module-build > bugtracker: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build > MailingList: > http://lists.sourceforge.net/lists/listinfo/module-build-general > > to which you could add > > repository: http://sourceforge.net/cvs/?group_id=45731 So added, thanks. Should auto-publish to the web site within a few hours. -Ken |
|
From: Nick Ing-S. <ni...@in...> - 2006-03-11 16:46:56
|
Graham Barr <gb...@po...> writes: >On Thu, March 9, 2006 3:25 am, Randy W. Sims wrote: >> >> The repository field could be constructed as a mapping: >> >> repository: >> type: cvs >> location: >> :pserver:ano...@cv...:/cvsroot/module-build >> >> or possibly some type of (icky) compound field: >> >> repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata > >I think it would be good to keep the field as a URL. Why does it have to >actually give the direct access point. Why could it not be a link to a >page that gives details about the repository. What does it take to get a new 'part-before-the-:' in a URL? repository: svn://svn.versiondude.net/randys/CPAN-Metadata |
|
From: David G. <da...@hy...> - 2006-03-11 14:24:46
|
Graham Barr wrote: > On Thu, March 9, 2006 3:25 am, Randy W. Sims wrote: >> The repository field could be constructed as a mapping: >> >> repository: >> type: cvs >> location: >> :pserver:ano...@cv...:/cvsroot/module-build >> >> or possibly some type of (icky) compound field: >> >> repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata > > I think it would be good to keep the field as a URL. Why does it have to > actually give the direct access point. Why could it not be a link to a > page that gives details about the repository. I second the URL idea. Among other things, it avoid having to maintain types and access data for different types of repositories. Unless we expect automated tools to be using META.yml to access repositories, let's leave it a simple URL. If people really want a direct access point, let them do it as a pseudo-URL: repository: cvs:pserver:anonymous@... Regards, David Golden |
|
From: Peter S. <Pe...@PS...> - 2006-03-11 02:12:29
|
At 03:40 AM 3/9/2006, Randy W. Sims wrote:
>As David said there will be better way to do this after 0.28.
Joy :-)
>As of current cvs the way I would probably write this is:
>
>use strict;
>use warnings;
>
>use Module::Build;
>
>my $build_class = Module::Build->subclass(code => <<'EOC');
>
> sub new {
> my $class = shift;
> my $self = $class->SUPER::new(@_);
>
> $self->install_path->{'yml'} =
> $self->localize_file_path($self->install_base . '/etc');
>
> return $self;
> }
>
>EOC
>
>my $builder = $build_class->new(
> dist_name => 'Foo',
> dist_version_from => 'lib/Foo.pm',
>
> install_base => '/home/randys/tmp/Foo',
>
> yml_files => {'config.yml' => 'yml/config.yml'},
What wasn't obvious until I spent some time doing it wrong was that the
config.yml above *must* be in a subdirectory called 'yml'. I had
initially called it 'etc' and finally hauled out the debugger which led
me to where the code does
my $localdir = File::Spec->catdir( $blib, $type );
That was something I did not glean at all from reading the "Adding new
file types to the install process" section of the cookbook, which
somehow avoids having to put .dat files into a /dat directory.
>);
>
>$builder->add_build_element('yml');
>$builder->create_build_script;
>
>__END__
>
>(tested on 0.2612 & 0.27x)
>Your examples below don't do anything with the 'yml' files as shown;
>they are not installed when './Build install' is run.
You're right. I was following the wrong path in the code and looking
at stuff that happens at build time.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
http://www.perlmedic.com/
|
|
From: <and...@fr...> - 2006-03-10 04:08:03
|
>>>>> On Thu, 9 Mar 2006 14:34:52 -0600 (CST), "Graham Barr" <gb...@po...> said: > Yes, but they do not have to be links to the repository itself. There is > no format that could easily cover every repository out there, so much > better tolink to an info page. And for mailinglist, do you put > mailto:li...@fo... or mailto:lis...@fo... ? Better to link to a > page which could also have archives on them. > Look at the example in the docs > resources: > license: http://dev.perl.org/licenses/ > homepage: http://sourceforge.net/projects/module-build > bugtracker: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build > MailingList: > http://lists.sourceforge.net/lists/listinfo/module-build-general > to which you could add > repository: http://sourceforge.net/cvs/?group_id=45731 Yes, this would be sufficient and solve the format problem. -- andreas |
|
From: Graham B. <gb...@po...> - 2006-03-09 20:35:13
|
On Thu, March 9, 2006 2:08 pm, Andreas J. Koenig wrote: >>>>>> On Thu, 9 Mar 2006 09:50:39 -0600, Ken Williams <ke...@ma...= > >>>>>> said: > > >>> repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata > >> > >> I think it would be good to keep the field as a URL. Why does it > >> have to > >> actually give the direct access point. Why could it not be a link t= o a > >> page that gives details about the repository. > > > Yeah, that's what I'm thinking too. For a mailing list, for exampl= e, > > you don't want to give a mailto: URL or something, you want to poin= t > > to an info page. Probably the same thing is true with repositories= . > > In my experience you can go in circles when you search for the > repository address from a homepage. People tend to forget to publish > it in a prominent place. There's simply no tie to a certain place: > download? contact? mailing list? FAQ? links? documentation? Ahh, of > course, it is in the Wiki:) But these are links to specific info pages > Folks at the German Perl Workshop seem to have the same experience. It > would really help to have a defined field for the repository address. Yes, but they do not have to be links to the repository itself. There is no format that could easily cover every repository out there, so much better tolink to an info page. And for mailinglist, do you put mailto:li...@fo... or mailto:lis...@fo... ? Better to link to = a page which could also have archives on them. Look at the example in the docs resources: license: http://dev.perl.org/licenses/ homepage: http://sourceforge.net/projects/module-build bugtracker: http://rt.cpan.org/NoAuth/Bugs.html?Dist=3DModule-Build MailingList: http://lists.sourceforge.net/lists/listinfo/module-build-general to which you could add repository: http://sourceforge.net/cvs/?group_id=3D45731 Graham. |
|
From: <and...@fr...> - 2006-03-09 20:08:47
|
>>>>> On Thu, 9 Mar 2006 09:50:39 -0600, Ken Williams <ke...@ma...> said: >>> repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata >> >> I think it would be good to keep the field as a URL. Why does it >> have to >> actually give the direct access point. Why could it not be a link to a >> page that gives details about the repository. > Yeah, that's what I'm thinking too. For a mailing list, for example, > you don't want to give a mailto: URL or something, you want to point > to an info page. Probably the same thing is true with repositories. In my experience you can go in circles when you search for the repository address from a homepage. People tend to forget to publish it in a prominent place. There's simply no tie to a certain place: download? contact? mailing list? FAQ? links? documentation? Ahh, of course, it is in the Wiki:) Folks at the German Perl Workshop seem to have the same experience. It would really help to have a defined field for the repository address. The field "homepage" is already listed under the resources topic and that is fine and imho needs to be supplemented. -- andreas |
|
From: Nick Ing-S. <ni...@in...> - 2006-03-09 18:25:22
|
Andy Dougherty <dou...@la...> writes: >On Tue, 7 Mar 2006, Yitzchak Scott-Thoennes wrote: > >You can add Solaris to that list. It's also getting $^X=3D./perl,=20 >and then failing to find it in .../t/_tmp/Simple/perl .=20=20 I thought Alan had given us the magic to get absoulte path? Have we just not incorporated it yet? |
|
From: Ken W. <ke...@ma...> - 2006-03-09 15:50:46
|
On Mar 9, 2006, at 8:16 AM, Graham Barr wrote: > On Thu, March 9, 2006 3:25 am, Randy W. Sims wrote: >> >> The repository field could be constructed as a mapping: >> >> repository: >> type: cvs >> location: >> :pserver:ano...@cv...:/cvsroot/module-build >> >> or possibly some type of (icky) compound field: >> >> repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata > > I think it would be good to keep the field as a URL. Why does it > have to > actually give the direct access point. Why could it not be a link to a > page that gives details about the repository. Yeah, that's what I'm thinking too. For a mailing list, for example, you don't want to give a mailto: URL or something, you want to point to an info page. Probably the same thing is true with repositories. -Ken |
|
From: Graham B. <gb...@po...> - 2006-03-09 14:16:18
|
On Thu, March 9, 2006 3:25 am, Randy W. Sims wrote: > > The repository field could be constructed as a mapping: > > repository: > type: cvs > location: > :pserver:ano...@cv...:/cvsroot/module-build > > or possibly some type of (icky) compound field: > > repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata I think it would be good to keep the field as a URL. Why does it have to actually give the direct access point. Why could it not be a link to a page that gives details about the repository. IMO, that would be more useful as then sites like CPAN search gave provid= e the link on the distribution page. Graham. |
|
From: Randy W. S. <ml...@th...> - 2006-03-09 11:40:31
|
Peter Scott wrote:
> My question about add_property was Warnocked; I'm going to give it one
> more go on the theory that folk may have been too busy with the P5P
> thread on M::B that started at the same time.
Sorry, not Warnocked. Just trying to sort through a backlog. I still
have your original message marked for follow-up...
As David said there will be better way to do this after 0.28. As of
current cvs the way I would probably write this is:
use strict;
use warnings;
use Module::Build;
my $build_class = Module::Build->subclass(code => <<'EOC');
sub new {
my $class = shift;
my $self = $class->SUPER::new(@_);
$self->install_path->{'yml'} =
$self->localize_file_path($self->install_base . '/etc');
return $self;
}
EOC
my $builder = $build_class->new(
dist_name => 'Foo',
dist_version_from => 'lib/Foo.pm',
install_base => '/home/randys/tmp/Foo',
yml_files => {'config.yml' => 'yml/config.yml'},
);
$builder->add_build_element('yml');
$builder->create_build_script;
__END__
(tested on 0.2612 & 0.27x)
Your examples below don't do anything with the 'yml' files as shown;
they are not installed when './Build install' is run.
Before 0.28, I hope to write some accessors for install_path() and
friends to make things a bit cleaner. I really want to deprecate the
return of references to internal data, if possible.
Randy.
> I'm wondering why the add_property() method isn't exposed to the user?
> It seems that it would be handy for my case; I have a config.yml file
> that I want installed in the etc/ directory off my target, and I'm
> hardwiring the install_base here because this is something that gets
> used at a client site. I started with:
>
> my $builder = Module::Build->new
> (
> install_base => '/path/to/install',
> script_files => [ 'dummy' ],
> yml_files => { 'config.yml' =>
> '/path/to/install/etc/dummy.yml' },
> dist_name => 'dummy',
> dist_version_from => 'dummy',
> );
> $builder->add_build_element('yml');
> $builder->create_build_script;
>
> However, I don't like having to repeat /path/to/install in there. To
> remove the duplication I ended up doing:
>
> my $builder = Module::Build->new
> (
> install_base => '/path/to/install',
> script_files => [ 'dummy' ],
> dist_name => 'dummy',
> dist_version_from => 'dummy',
> );
> sub Module::Build::find_yml_files {
> my $self = shift;
> return { map $self->localize_file_path($_),
> 'config.yml' => $self->install_base . '/etc/dummy.yml'
> };
> }
> $builder->add_build_element('yml');
> $builder->create_build_script;
>
>
> But it seems that if I had been able to call add_property, it would have
> been simpler:
>
> my $builder = Module::Build->new
> (
> install_base => '/path/to/install',
> script_files => [ 'dummy' ],
> dist_name => 'dummy',
> dist_version_from => 'dummy',
> );
> $builder->add_property('yml_files'); # Method not found
> $builder->yml_files({ 'config.yml' => $self->install_base .
> '/etc/dummy.yml' });
> $builder->add_build_element('yml');
> $builder->create_build_script;
|
|
From: Paul M. <pau...@nt...> - 2006-03-09 09:53:59
|
From: Randy W. Sims [mailto:ml...@th...] > Ken Williams wrote: > > > > On Mar 8, 2006, at 2:50 AM, Dominic Dunlop wrote: > > > >> On 2006-03-07, at 21:37, Randy W. Sims wrote: > >> > >>> Unfortunately, I don't have a broken system to test on so I'm mostly > >>> guessing. I do have an old 633 Mhz Pentium PC laying around somewhere > >>> that I can install one of the BSD variant on tonight or tomorrow. > >> > >> That looks like the way to go, as I can't guarantee to respond quickly > >> when asked to run tests -- and I don't know the code anyway. Good luck > >> with that install. Alternatively, does anybody on the M::B list have a > >> Mac with some version of Mac OS X on it lying around? > > > > My main machine (powerbook) runs OS X 10.4.something. Obviously M::B's > > tests pass for me in its standalone distro, I'll try testing blead. > > Right now blead is failing to build for me though, because it's missing > > a constants.xs file for Compress::Zlib or something. I'll try to get > > creative with symlinks. > > Note, I get this same error running blead on Windows XP. But it runs > fine on Ubuntu Linux. I got FreeBSD installed on an old computer at > home, but still have some work configuring and pulling down blead to > test. I've not taken the time to look into this. > > Randy. > > > ..\..\..\miniperl.exe "-I..\..\..\lib" "-I..\..\..\lib" > ..\..\..\lib\Ext > Utils\xsubpp -typemap ..\..\..\lib\ExtUtils\typemap -typemap typemap > Zlib.xs > > Zlib.xsc && C:\home\randys\src\perl-current\miniperl.exe > "-I..\..\..\lib" "-I.. > \..\..\lib" -MExtUtils::Command -e mv Zlib.xsc Zlib.c > Cannot open 'constants.xs': No such file or directory in Zlib.xs, line 698 > NMAKE : fatal error U1077: '..\..\..\miniperl.exe' : return code '0x1' > Stop. > Unsuccessful make(Compress/Zlib): code=512 at buildext.pl line 142. > NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' > Stop. The patch to C::Z earlier this week moved a pile of files around. If you didn't specify the "--delete" option when you rsync the blead you end up with multiple copies of some of these files. For what it's worth, I was bitten by this one myself. Paul ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com |
|
From: Randy W. S. <Ra...@Th...> - 2006-03-09 09:25:50
|
Ken Williams wrote:
>
> On Mar 6, 2006, at 4:44 PM, Randy W. Sims wrote:
>> There are a number of problems it could be intended to solve, but I'm
>> not sure which one(s).
>>
>> 1) For automated builders/testers, it could indicate that a module
>> requires user intervention. Eg. it queries the user for input during
>> install.
>>
>> 2) The dependencies listed in META.yml are not static. Maybe a
>> Win32::* module is required only when run under Windows, but is not
>> listed in META.yml because there is currently no way to express
>> conditional dependencies.
>>
>> 3) The description in the spec would seem to imply that a static
>> config indicates that module can be installed without the builder
>> (i.e. Module::Build)), that the modules could simply be copied into
>> the proper folders by any tool. This would mean any module with with
>> XS or compiled code as well as anything under (1) and (2) above are
>> dynamic?
>
>
> I'd intended it as 1 & 2 but not 3. In other words, whether the
> information in the META.yml is definitive or not. If it weren't, then
> a cautious or curious user might want to read the Build.PL before
> installing.
>
> Everything is on the honor system of course, so it's not really a
> security thing, just a convenience thing.
Maybe that section could be clarified a bit:
:>>>
(Spec 1.0) [optional] {boolean} A boolean flag indicating that the
content of the META.yml does *not* represent a complete and static
description of the distribution. If the properties of the distribution
as described by META.yml change depending on operating environment or
user choice, this should be set to 1 (true).
For example, if one of the prerequisites this distribution 'requires' is
only needed on BSD flavored platforms, the metadata would be considered
"dynamic", so the 'dynamic_config' field should be set to 1 (true).
If this field is omitted, it defaults to 1 (true).
:<<<
The above with other clarifications and corrections you've made could
maybe be a 1.2.1 release maybe?
And/Or with the following a 1.3 release:
The alternative listed under "recommends" should probably be removed or
made an official part of the spec.
The repository field could be constructed as a mapping:
repository:
type: cvs
location: :pserver:ano...@cv...:/cvsroot/module-build
or possibly some type of (icky) compound field:
repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata
Randy.
|
|
From: Randy W. S. <ml...@th...> - 2006-03-09 04:48:23
|
Ken Williams wrote: > > On Mar 6, 2006, at 6:04 PM, Randy W. Sims wrote: > >> Chris Dolan wrote: >>> If you use the "dist_name" style of Build.PL instead of >>> "module_name", then you need to include the "dist_abstract" field >>> too, or you will see the following error when running "Build distmeta": >>> ERROR: Missing required field 'abstract' for META.yml >>> This is very misleading because it's the "dist_abstract" field that's >>> missing, not "abstract". The following simple patch changes the >>> error message. I've confirmed that with the patch it now says: >>> ERROR: Missing required field 'dist_abstract' for META.yml >>> but I haven't tested any fields other than "abstract". >>> Chris >>> diff -u -r1.552 Base.pm >>> --- lib/Module/Build/Base.pm 4 Mar 2006 03:59:28 -0000 1.552 >>> +++ lib/Module/Build/Base.pm 5 Mar 2006 20:45:41 -0000 >> >> Thanks, applied. >> > > Ideally I think the message would look something like: > > ERROR: Missing required data 'abstract' for META.yml, please provide > 'dist_abstract' field. That message wraps on the screen. Would something like: ERROR: Property '$_' not defined for META.yml field '$name' convey the same intent? Or we could manually wrap ERROR: Missing required data 'abstract' for META.yml. Please provide 'dist_abstract' field. Or does it matter if it wraps? Randy. |
|
From: Ken W. <ke...@ma...> - 2006-03-09 03:02:05
|
On Mar 8, 2006, at 8:50 PM, Ken Williams wrote:
> OK, I got blead to build and now I do indeed see M::B failures in
> testing. The errors are indeed in find_perl_interpreter(), because
> if I change it to always return the constant value of my
> bleadperl's perl, tests start passing.
>
> I'll investigate a fix.
So I've finally grasped the problem - probably I'm the last person
to. What's happening is that $^X is relative ('./perl'), and then we
chdir('_tmp/Simple') so perl can't be found anymore.
I think we either need to explicitly tell M::B where perl is in this
situation (e.g. by doing find_perl_interpreter() before chdir() and
passing the subbuild the complete path), or avoid the chdir() in the
first place.
Either of those would be preferable to the guessing game of trying './
perl' and '../perl' and '../../perl' and so on, but of course that
would be the quickest band-aid.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2006-03-09 02:50:14
|
On Mar 8, 2006, at 7:24 PM, Ken Williams wrote: > > On Mar 8, 2006, at 2:50 AM, Dominic Dunlop wrote: > >> On 2006=9603=9607, at 21:37, Randy W. Sims wrote: >> >>> Unfortunately, I don't have a broken system to test on so I'm =20 >>> mostly guessing. I do have an old 633 Mhz Pentium PC laying =20 >>> around somewhere that I can install one of the BSD variant on =20 >>> tonight or tomorrow. >> >> That looks like the way to go, as I can't guarantee to respond =20 >> quickly when asked to run tests -- and I don't know the code =20 >> anyway. Good luck with that install. Alternatively, does anybody =20 >> on the M::B list have a Mac with some version of Mac OS X on it =20 >> lying around? > > My main machine (powerbook) runs OS X 10.4.something. Obviously =20 > M::B's tests pass for me in its standalone distro, I'll try testing =20= > blead. Right now blead is failing to build for me though, because =20 > it's missing a constants.xs file for Compress::Zlib or something. =20 > I'll try to get creative with symlinks. OK, I got blead to build and now I do indeed see M::B failures in =20 testing. The errors are indeed in find_perl_interpreter(), because =20 if I change it to always return the constant value of my bleadperl's =20 perl, tests start passing. I'll investigate a fix. -Ken |
|
From: Randy W. S. <ml...@th...> - 2006-03-09 01:30:47
|
Ken Williams wrote:
>
> On Mar 8, 2006, at 2:50 AM, Dominic Dunlop wrote:
>
>> On 2006–03–07, at 21:37, Randy W. Sims wrote:
>>
>>> Unfortunately, I don't have a broken system to test on so I'm mostly
>>> guessing. I do have an old 633 Mhz Pentium PC laying around somewhere
>>> that I can install one of the BSD variant on tonight or tomorrow.
>>
>> That looks like the way to go, as I can't guarantee to respond quickly
>> when asked to run tests -- and I don't know the code anyway. Good luck
>> with that install. Alternatively, does anybody on the M::B list have a
>> Mac with some version of Mac OS X on it lying around?
>
> My main machine (powerbook) runs OS X 10.4.something. Obviously M::B's
> tests pass for me in its standalone distro, I'll try testing blead.
> Right now blead is failing to build for me though, because it's missing
> a constants.xs file for Compress::Zlib or something. I'll try to get
> creative with symlinks.
Note, I get this same error running blead on Windows XP. But it runs
fine on Ubuntu Linux. I got FreeBSD installed on an old computer at
home, but still have some work configuring and pulling down blead to
test. I've not taken the time to look into this.
Randy.
..\..\..\miniperl.exe "-I..\..\..\lib" "-I..\..\..\lib"
..\..\..\lib\Ext
Utils\xsubpp -typemap ..\..\..\lib\ExtUtils\typemap -typemap typemap
Zlib.xs >
Zlib.xsc && C:\home\randys\src\perl-current\miniperl.exe
"-I..\..\..\lib" "-I..
\..\..\lib" -MExtUtils::Command -e mv Zlib.xsc Zlib.c
Cannot open 'constants.xs': No such file or directory in Zlib.xs, line 698
NMAKE : fatal error U1077: '..\..\..\miniperl.exe' : return code '0x1'
Stop.
Unsuccessful make(Compress/Zlib): code=512 at buildext.pl line 142.
NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2'
Stop.
|
7 messages has been excluded from this view by a project administrator.
