module-build-general Mailing List for Module::Build
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: Jay T. <jtr...@gm...> - 2006-07-27 17:41:01
|
I tried again with just the old CPAN (i.e. perl -MCPAN -e shell, then install Module::Build) after blowing away the .cpan file and I get this error: ... Manifying blib/lib/Module/Build/Authoring.pod -> blib/libdoc/Module::Build::Authoring.3pm Manifying blib/lib/Module/Build/Compat.pm -> blib/libdoc/Module::Build::Compat.3pm /usr/bin/make -j3 -- OK Running make test /usr/bin/perl Build --makefile_env_macros 1 test t/basic...........ok t/compat..........ok 1/60Couldn't run Build.PL: Argument list too long at /root/.cpan/build/Module-Build-0.2804/blib/lib/Module/Build/Compat.pm line 200. # Failed test in t/compat.t at line 180. t/compat..........NOK 3 # Failed test 'Makefile should exist' # in t/compat.t at line 181. t/compat..........NOK 4make[1]: *** No targets specified and no makefile found. Stop. ... This is getting frustrating, I've never had a problem before installing anything from CPAN. |
|
From: Jay T. <jtr...@gm...> - 2006-07-27 17:30:35
|
I'm trying to build Mason which needs Module::Build. I can't get Module::Build to install via cpanplus. Environment is Centos 4.3 (RHEL). Here is the output when I try and build: -------------------------------------------------------------------------- CPAN Terminal> i Module::Build Installing Module::Build WARNING: This key is not certified with a trusted signature! Primary key fingerprint: ADCB DB05 B40E B2A2 A555 5462 82BB CC04 B7EF 9476 Not in MANIFEST: _build/auto_features Not in MANIFEST: _build/build_params Not in MANIFEST: _build/cleanup Not in MANIFEST: _build/config_data Not in MANIFEST: _build/features Not in MANIFEST: _build/magicnum Not in MANIFEST: _build/notes Not in MANIFEST: _build/prereqs Not in MANIFEST: _build/runtime_params Not in MANIFEST: Build ==> MISMATCHED content between MANIFEST and distribution files! <== [ERROR] Signature check failed for module 'Module::Build' -- Not trusting this module, aborting install Error installing 'Module::Build' Problem installing one or more modules *** You can view the complete error buffer by pressing 'p' *** ------------------------------------------------------------------------------------------------------------- Is CPAN not up-to-date or something? I have also seen this error, but not lately: Couldn't run Build.PL: Argument list too long at /root/.cpanplus/5.8.5/build/Module-Build-0.2804/blib/lib/Module/Build/Compat.pm line 200 There was a brief mention of this error in the list archives, but no solutiuon. I am currently stuck with the preceeding error. |
|
From: Ray Z. <rz...@co...> - 2006-07-20 23:12:40
|
Btw, the Module::Build list moved from module-build- ge...@li... to mod...@pe... Shouldn't somebody disable the old list? Ray On Jul 20, 2006, at 7:07 PM, John Peacock wrote: > David Golden wrote: >> [cc'd to perl-qa for awareness of the issue] >> >> The switch to version objects in Module::Build means that the >> generated >> META.yml now has this: > > Is this with or without YAML itself loaded (so I know where to start)? > > John |
|
From: John P. <jpe...@ro...> - 2006-07-20 23:07:08
|
David Golden wrote: > [cc'd to perl-qa for awareness of the issue] > > The switch to version objects in Module::Build means that the generated > META.yml now has this: Is this with or without YAML itself loaded (so I know where to start)? John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 |
|
From: David G. <da...@hy...> - 2006-07-20 22:51:34
|
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
name: Class-InsideOut
version: !!perl/hash:Module::Build::Version
original: 1.00
version:
- 1
- 0
That can't be good for backwards compatibility. I think that the
version object should be stringified when added to META.yml.
Regards,
David Golden
|
|
From: Steve H. <ste...@uk...> - 2006-07-18 12:54:36
|
UmFuZHkgVy4gU2ltcyB3cm90ZToKPiBTdGV2ZSBIYXkgd3JvdGU6Cj4+IFJhbmR5IFcuIFNpbXMg d3JvdGU6Cj4+PiBPaywgSSBmaW5hbGx5IGdvdCBhcm91bmQgdG8gbG9va2luZy4gVGhlIHByb2Js ZW0gaXMgd2hlcmUgSSAKPj4+IHN1c3BlY3RlZDogSXQncyB0aGUgcXVvdGluZyBvZiB0aGUgbWFj cm9zIFZFUlNJT04gJiBYU19WRVJTSU9OLiBPbiAKPj4+IHRoZSBjb21tYW5kIGxpbmUgeW91IGNh biB0eXBlOgo+Pj4KPj4+ICBiY2MzMiAtRFZFUlNJT049XCIxLjAxXCIgdGVzdC5jCj4+Pgo+Pj4g QnV0IHdlIHVzZSByZXNwb25zZSBmaWxlcyBmb3IgYWxsIGNvbXBpbGVycyBvbiBXaW5kb3dzIChH Q0MsIEJDQywgJiAKPj4+IE1TVkMpLCBhbmQgdGhlIHJlc3BvbnNlIGZpbGVzIHNlZW0gdG8gcmVx dWlyZSBhIGRpZmZlcmVudCBxdW90aW5nIAo+Pj4gc3ludGF4IHRoYXQgSSBoYXZlbid0IGZpZ3Vy ZWQgb3V0IHlldC4KPiBbLi4uXQo+IAo+Pj4gSSd2ZSBwb3N0ZWQgb24gb25lIG9mIHRoZSBib3Js YW5kIG5ld3Nncm91cHMgc2VlIGlmIGFueW9uZSBjYW4gaGVscCAKPj4+IHRoZXJlLiBJZiBJIGNh bid0IGZpbmQgYSBxdW90aW5nIHNvbHV0aW9uLCBJIGd1ZXNzIEkgY2FuIG1vdmUgbWFjcm9zIAo+ Pj4gb2YgdGhlIGtleT12YWx1ZSBmb3JtIGJhY2sgb250byB0aGUgY29tbWFuZGxpbmUsIGZvciBi Y2MuCj4+Cj4+IEkgZ2V0IHRoZSBzYW1lIHByb2JsZW1zIGhlcmUuICBJIGZvdW5kIHRoYXQgeW91 IGNhbiB1c2UgImNvbmZpZ3VyYXRpb24gCj4+IGZpbGVzIiAobGlrZSAicmVzcG9uc2UgZmlsZXMi LCBidXQgdGhleSBvbmx5IGNvbnRhaW4gY29tcGlsZXIgb3B0aW9ucywgCj4+IG5vdCBmaWxlbmFt ZXMgdG9vKSBhbmQgdGhhdCB0aGVzZSB3b3JrLCBidXQgeW91IGNhbiBvbmx5IHNlZW0gdG8gaGF2 ZSAKPj4gb25lIG9mIHRoZW0uCj4gWy4uLl0KPiAKPj4gVGhhdCBqdXN0IG1ha2VzIGl0IGFsbCB0 aGUgbW9yZSBpcnJpdGF0aW5nIHRoYXQgdGhlIHNhbWUgcXVvdGluZyAKPj4gZG9lc24ndCB3b3Jr IGluIHJlc3BvbnNlIGZpbGVzLgo+IAo+IEV4dHJlbWVseSBpcnJpdGF0aW5nLiBJJ3ZlIHJlY2Vp dmVkIHNldmVyYWwgcmVzcG9uc2VzIHRvIG15IHF1ZXJ5IGluIHRoZSAKPiBCb3JsYW5kIG5ld3Nn cm91cHMsIGJ1dCBubyBzb2x1dGlvbi4gSSdtIGxlZnQgd2l0aCB0aGUgYWx0ZXJuYXRpdmUgb2Yg Cj4gcHVsbGluZyB0aGVtIG91dCBvZiB0aGUgcmVzcG9uc2UgZmlsZSBmb3IgdGhhdCBjb21waWxl ci4KPiAKPiBUaGUgYXR0YWNoZWQgcGF0Y2ggaXMgd2hhdCBJJ3ZlIGNoZWNrZWQgaW50byBvdXIg cmVwb3NpdG9yeS4gVGVzdHMgbm93IAo+IHBhc3MuCj4gCj4gUmFuZHkuCgpJJ3ZlIGp1c3QgYXBw bGllZCB0aGlzIHBhdGNoIHRvIGJsZWFkcGVybCAoIzI4NTk3KSB0byByZWR1Y2UgdGhlIHNtb2tl IApmcm9tIEJvcmxhbmQgYnVpbGRzLgoKLS0gCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSYWRhbiBDb21wdXRhdGlvbmFsIEx0ZC4NCg0KVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgYWRkcmVz c2VlKHMpIG9ubHkuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciBv ciB0aGVyZSBhcmUgYW55IHByb2JsZW1zLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkuIFRoZSB1bmF1dGhvcml6ZWQgdXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGFsdGVy YXRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IGZvcmJpZGRlbi4gTm90ZSB0aGF0IGFu eSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBlbWFpbCBhcmUgc29sZWx5IHRo b3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhvc2Ug b2YgUmFkYW4gQ29tcHV0YXRpb25hbCBMdGQuIFRoZSByZWNpcGllbnQocykgb2YgdGhpcyBtZXNz YWdlIHNob3VsZCBjaGVjayBpdCBhbmQgYW55IGF0dGFjaGVkIGZpbGVzIGZvciB2aXJ1c2VzOiBS YWRhbiBDb21wdXRhdGlvbmFsIHdpbGwgYWNjZXB0IG5vIGxpYWJpbGl0eSBmb3IgYW55IGRhbWFn ZSBjYXVzZWQgYnkgYW55IHZpcnVzIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwuCg== |
|
From: <and...@fr...> - 2006-06-22 05:19:45
|
>>>>> On Wed, 21 Jun 2006 13:26:58 -0400, "Lindiakos, Fotios" <fli...@mi...> said:
> Thanks so much, that all worked perfectly.
> But I have a followup question, is there a way to actually install this
> with the CPAN shell from my tar.gz?
One option would be to upload the tarball with a name that matches
/\d_\d/, say
Foo-Bar-3.14_90.tar.gz
because such files are not indexed; and when it has propagated to your
mirror, install it with the command
install MYDIR/Foo-Bar-3.14_90.tar.gz
from the CPAN shell.
--
andreas
|
|
From: Lindiakos, F. <fli...@mi...> - 2006-06-21 17:27:11
|
Thanks so much, that all worked perfectly. =20
But I have a followup question, is there a way to actually install this
with the CPAN shell from my tar.gz?
-- fotios
-----Original Message-----
From: mod...@li...
[mailto:mod...@li...] On Behalf
Of Steffen Schwigon
Sent: Wednesday, June 21, 2006 3:09 AM
To: mod...@li...
Subject: Re: [Module::Build] Getting started help
"Lindiakos, Fotios" <fli...@mi...> writes:
> First, is there a way for me to put something like hc.conf into /etc
> (assuming I have permission to write there. Where would I have to
> put the file in the package (under lib, or can I have an etc folder
> or something too)?
I would create a subdir 'etc', put hc.conf into that directory and add
the following config to Build.PL:
my $build =3D Module::Build->new (
#
# ... all stuff you already have
#
=20
etc_files =3D> { 'etc/hc.conf' =3D> 'etc/hc.conf' },
install_path =3D> { 'etc' =3D> '/etc' }
);
$build->add_build_element('etc');
$build->create_build_script;
$build->create_makefile_pl;
But I don't know how to make that absolute path '/etc' to work with a
given '--prefix=3D/somewhere' option. Maybe there's a better way.
> Second, how can I have CPAN automatically build missing dependencies,
> or query for them or something.
That should already work automatically because you specified them with
'requires =3D> {...}'. The CPAN shell will install missing prerequisites
if you configured it to "follow automatically" or "ask".
> On that note (not M::B specific), is there a way that I can test
> using CPAN to install my modules?
I always do manually what the CPAN shell does, e.g. this way:
# from your project dir
./Build dist
cp My-Dist-0.1.tar.gz /tmp/
=20
# now everything in /tmp dir
cd /tmp
tar xzf My-Dist-0.1.tar.gz
cd My-Dist-0.1
perl Build.PL
./Build
./Build test
./Build fakeinstall # or install
=20
GreetinX
Steffen=20
--=20
Steffen Schwigon <sch...@we...>
Dresden Perl Mongers <http://dresden-pm.org/>
_______________________________________________
Module-build-general mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: Steffen S. <sch...@we...> - 2006-06-21 07:08:48
|
"Lindiakos, Fotios" <fli...@mi...> writes:
> First, is there a way for me to put something like hc.conf into /etc
> (assuming I have permission to write there. Where would I have to
> put the file in the package (under lib, or can I have an etc folder
> or something too)?
I would create a subdir 'etc', put hc.conf into that directory and add
the following config to Build.PL:
my $build = Module::Build->new (
#
# ... all stuff you already have
#
etc_files => { 'etc/hc.conf' => 'etc/hc.conf' },
install_path => { 'etc' => '/etc' }
);
$build->add_build_element('etc');
$build->create_build_script;
$build->create_makefile_pl;
But I don't know how to make that absolute path '/etc' to work with a
given '--prefix=/somewhere' option. Maybe there's a better way.
> Second, how can I have CPAN automatically build missing dependencies,
> or query for them or something.
That should already work automatically because you specified them with
'requires => {...}'. The CPAN shell will install missing prerequisites
if you configured it to "follow automatically" or "ask".
> On that note (not M::B specific), is there a way that I can test
> using CPAN to install my modules?
I always do manually what the CPAN shell does, e.g. this way:
# from your project dir
./Build dist
cp My-Dist-0.1.tar.gz /tmp/
# now everything in /tmp dir
cd /tmp
tar xzf My-Dist-0.1.tar.gz
cd My-Dist-0.1
perl Build.PL
./Build
./Build test
./Build fakeinstall # or install
GreetinX
Steffen
--
Steffen Schwigon <sch...@we...>
Dresden Perl Mongers <http://dresden-pm.org/>
|
|
From: Lindiakos, F. <fli...@mi...> - 2006-06-20 16:50:52
|
I am having a little trouble with 2 things, and I was hoping I could get some assistance. I apologize if you've seen me ask this elsewhere, but I am getting no responses from anybody. First, is there a way for me to put something like hc.conf into /etc (assuming I have permission to write there. Where would I have to put the file in the package (under lib, or can I have an etc folder or something too)? Second, how can I have CPAN automatically build missing dependencies, or query for them or something. On that note (not M::B specific), is there a way that I can test using CPAN to install my modules? =20 Any help is greatly appreciated, Fotios Lindiakos http://www.mitre.org =20 PS - this is what I have for the Build.PL so far, and it works manually installing it (via ./Build make etc....) save putting hc.conf into /etc ----------------------------------------------- my $build =3D Module::Build->new ( module_name =3D> 'HC::U', dist_author =3D> 'fo...@ba...' <mailto:kn...@mi...>'> = , dist_abstract =3D> 'A collection of packages', dist_version =3D> '0.01', license =3D> 'gpl', requires =3D> { 'Carp' =3D> 0, 'Config::General' =3D> 0, 'SOAP::Lite' =3D> '>=3D 0.67', 'SOAP::Transport::HTTP' =3D> 0, }, auto_features =3D> { YAML_support =3D> { description =3D> 'Use YAML.pm to write META.yml files', requires =3D> { YAML =3D> ' >=3D = 0.35, !=3D 0.49_01 ' }, }, manpage_support =3D> { description =3D> 'Create UNIX man = pages', requires =3D> { 'Pod::Man' =3D> 0 }, }, }, add_to_cleanup =3D> [ 'HC-*' ] ); $build->add_build_element('conf'); $build->create_build_script; |
|
From: Ken W. <ke...@ma...> - 2006-06-07 21:33:55
|
On Jun 5, 2006, at 1:15 PM, Ray Zimmerman wrote:
> Thanks for the suggestions Ken & Randy.
>
> On Jun 3, 2006, at 1:14 PM, Ken Williams wrote:
>> As a workaround, you could probably do "delete $INC{"Module/Build/
>> Base.pm"}; require Module::Build::Base;" each time through the loop.
>
> It turns out that I also need to do ...
>
> Symbol::delete_package('Module::Build::Base');
>
> ... every time through the loop as well in order to avoid tons of
> "subroutine foo redefined ..." warnings. This *appears* to work,
> however, the comments in the "BUGS" section of the docs for Symbol
> make me uncomfortable with using this approach.
If it's really just the build_elements structure that's causing
trouble, you could use the following chicanery:
my $orig_elements;
foreach my $dist ( @dist_list ) {
my $dir = File::Spec->join('my_build_dir', $dist);
chdir $dir or die "could not change to $dir";
$p = { <some build options> };
my $b = Module::Build->new_from_context( %$p );
if ($orig_elements) {
$b->build_elements($orig_elements);
} else {
$orig_elements = $b->build_elements;
}
$b->dispatch('build');
$b->dispatch('test');
$b->dispatch('install');
}
I suppose that if() business could all be abbreviated to
$b->build_elements($orig_elements ||= $b->build_elements);
-K
|
|
From: Chris D. <ch...@cl...> - 2006-06-06 04:31:25
|
On Jun 5, 2006, at 5:38 PM, Gene Boggs wrote:
> Maybe this is a question with an answer already but I don't see
> it... Is there a facility to create *.zip files instead of
> tar.gz's of your distribution? I thought at first that the ppmdist
> might be the answer but that creates a tar.gz also. I'd rather not
> do system("zip -r $distname.zip $distname"); if I can help it...
> I'm pretty sure I am missing something here. Hints? :-)
>
> Thanks,
>
> Gene Boggs
This can be accomplished with a subclass. The following (untested)
code should give you a head start:
my $class = Module::Build->subclass(<<'END_OF_SUBCLASS');
sub make_tarball {
my ($self, $dir, $file) = @_;
$file ||= $dir;
$self->log_info("Creating $file.zip\n");
$self->do_system('zip', '-r', "$file.zip", $dir);
}
END_OF_SUBCLASS
$class->new(
# Usual M::B declarations go here
)->create_build_script;
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
|
|
From: Ray Z. <rz...@co...> - 2006-06-06 02:53:13
|
Thanks for the suggestions Ken & Randy.
On Jun 3, 2006, at 1:14 PM, Ken Williams wrote:
> As a workaround, you could probably do "delete $INC{"Module/Build/
> Base.pm"}; require Module::Build::Base;" each time through the loop.
It turns out that I also need to do ...
Symbol::delete_package('Module::Build::Base');
... every time through the loop as well in order to avoid tons of
"subroutine foo redefined ..." warnings. This *appears* to work,
however, the comments in the "BUGS" section of the docs for Symbol
make me uncomfortable with using this approach. Anyone with more
experience care to give an opinion on whether I'm likely to get
bitten using this approach?
On Jun 5, 2006, at 2:40 AM, Randy W. Sims wrote:
> This is an unfortunate artifact of the current implementation.
> There are plans to fix this in the next iteration by moving
> properties into their own object.
Ah, nice ... looking forward to the next M::B iteration ...
Ray
|
|
From: Randy W. S. <ml...@th...> - 2006-06-06 02:44:19
|
Ken Williams wrote: > > On May 16, 2006, at 11:12 PM, Randy W. Sims wrote: > >> Ben Lavender wrote: >>> The supplied patch gets me to perl Build test, which fails at this >>> point: >>> t\runthrough......ok 13/28Use of uninitialized value in pattern match >>> (m//) at c >>> :/work/Perl/lib/File/Spec/Win32.pm line 72. >>> Use of uninitialized value in pattern match (m//) at >>> c:/work/Perl/lib/File/Spec/ >>> Win32.pm line 72. >>> Use of uninitialized value in pattern match (m//) at >>> c:/work/Perl/lib/File/Spec/ >>> Win32.pm line 140. >>> t\runthrough......ok 19/28 >>> t\runthrough......NOK 20# Failed test in t\runthrough.t at line 151. >>> # got: 'Can't locate object method "create_archive" via >>> package "Archiv >>> e::Tar" (perhaps you forgot to load "Archive::Tar"?) at >>> C:\work\mbtest\Module-Bu >>> ild-0.28\blib\lib/Module/Build/Base.pm line 3436. >>> # ' >>> # expected: '' >>> t\runthrough......ok 28/28# Looks like you failed 1 test of 28. >> >> The patch works because it throws away the volume part, but the volume >> shouldn't be there at all. > > Yeah, it shouldn't, but there it is. =) Older versions of File::Spec > include it, and even though it's not strictly incorrect to have a drive > letter on a relative path, if we don't jump through the byzantine > File::Spec hoops correctly we'll screw things up. > > Newer versions of File::Spec don't include the drive letter in this > situation - there are some regression tests in File::Spec now to ensure > that. File::Spec 0.84 seems to work ok. I'd recommend bumping the prereq. Otherwise, the attached patch allows it to work with 0.82. Randy. |
|
From: Randy W. S. <ml...@th...> - 2006-06-06 02:19:13
|
Ray Zimmerman wrote:
> I have an automated build, test and install process for a collection
> of in-house Perl packages* using a straightforward procedure which is
> basically ...
>
> foreach my $dist ( @dist_list ) {
> my $dir = File::Spec->join('my_build_dir', $dist);
> chdir $dir or die "could not change to $dir";
>
> $p = { <some build options> };
>
> my $b = Module::Build->new_from_context( %$p );
> $b->dispatch('build');
> $b->dispatch('test');
> $b->dispatch('install');
> }
>
> I ran into a problem when attempting to convert everything from using
> a slightly modified version of M::B 0.2608 to M::B 0.2801. The
> problem I am encountering has to do with the fact that $b-
> >build_elements appears to be cumulative in the above loop, even
> though $b is being recreated. That is, if one of the Build.PL files
> has ...
>
> $b->add_build_element('foo');
>
> ... then all subsequent $dist's in the above loop will attempt to
> build foo elements even though the corresponding Build.PL does not
> mention foo anywhere.
>
> I believe the %valid_properties closure in
> Module::Build::Base::ACTION_config_data is the culprit. Is this a
> bug? Shouldn't the list of build_elements (all config data, in fact)
> be an object property as opposed to class data?
This is an unfortunate artifact of the current implementation. There are
plans to fix this in the next iteration by moving properties into their
own object.
> Any suggestions for a workaround to start over with a completely
> fresh, clean M::B at the beginning of each loop?
Maybe fork a child process for each build...
Randy.
|
|
From: Randy W. S. <ml...@th...> - 2006-06-06 01:55:49
|
Ray Zimmerman wrote:
> I'm looking for recommendations for how where to put my Module::Build
> sub-classes and how to set up @INC to find them.
>
> Here's my scenario ... I'm working with a set of Perl packages that are
> organized as a base package A with a number of add-on packages. Let's
> call one of the add-on packages B. So A is a prerequisite for B (i.e. A
> must be installed in order to build, test and install any of B). I have
> a common Module::Build sub-class, call it Bbuilder, that I use for all
> B. Since A must be installed in order to build B anyway, it seems
> logical to have Bbuilder.pm be included as part of A. To build A, I have
> another M::B sub-class, call it Abuilder, which is a sub-class of Bbuilder.
>
> If Bbuilder.pm is placed in A/lib, it gets installed as part of A and
> the Build.PL script for B is very straightforward. The question is,
> where do I put Abuilder.pm, and how do I manipulate @INC inside the
> Build.PL script for A to get what I want. Are there conventions for
> where to put these things?
>
> I'm currently thinking of putting Abuilder.pm in A/t and Bbuilder in
> A/lib and doing ...
>
> use lib qw( lib t );
> require Abuilder;
>
> ... at the beginning of Build.PL. Any better ideas?
The de facto here is to place any modules needed only for the build
process into a directory named 'inc'. This is what M::B itself does.
Otherwise, it's exactly as I would do it.
So you have
App/
inc/
App/Builder.pm
lib/
App.pm
App/Plugin/Builder.pm
...
App-Plugin
...
The Build.PL for App would be something like:
use lib 'inc';
use App::Builder;
my $b = App::Builder->new(
module => 'App',
...
);
__END__
And the Build.PL for App::Plugin:
use App::Plugin::Builder;
my $b = App::Plugin::Builder->new(
module => 'App::Plugin',
build_requires => {
App => 0,
App::Plugin::Builder => 0,
},
);
__END__
|
|
From: Gene B. <gb...@si...> - 2006-06-06 01:53:13
|
Maybe this is a question with an answer already but I don't see it... =
Is there a facility to create *.zip files instead of tar.gz's of your =
distribution? I thought at first that the ppmdist might be the answer =
but that creates a tar.gz also. I'd rather not do system("zip -r =
$distname.zip $distname"); if I can help it... I'm pretty sure I am =
missing something here. Hints? :-)
Thanks,
Gene Boggs
|
|
From: Ken W. <ke...@ma...> - 2006-06-06 01:27:35
|
Hi all, Assuming this message ever makes it through the SourceForge system, I'm announcing that we're going to move the two Module::Build lists from SF to Perl.org today. The new list addresses will be mod...@pe... mod...@pe... Please adjust your personal filters, procmail rules, etc. accordingly. We'll move the current group of subscribers over (for the checkins list, that's only 4 people), then de-activate the old list. I think I'll probably put some kind of auto-responder on the old list telling them where to look for the new list. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-06-03 17:14:48
|
Hi Ray,
I think you're probably correct on all counts. I don't like that
information being class data either, I'm hoping we can migrate it to
instance data sometime. Certainly the use case you posted should be
supported.
As a workaround, you could probably do "delete $INC{"Module/Build/
Base.pm"}; require Module::Build::Base;" each time through the loop.
-Ken
On Jun 2, 2006, at 8:56 AM, Ray Zimmerman wrote:
> I have an automated build, test and install process for a collection
> of in-house Perl packages* using a straightforward procedure which is
> basically ...
>
> foreach my $dist ( @dist_list ) {
> my $dir = File::Spec->join('my_build_dir', $dist);
> chdir $dir or die "could not change to $dir";
>
> $p = { <some build options> };
>
> my $b = Module::Build->new_from_context( %$p );
> $b->dispatch('build');
> $b->dispatch('test');
> $b->dispatch('install');
> }
>
> I ran into a problem when attempting to convert everything from using
> a slightly modified version of M::B 0.2608 to M::B 0.2801. The
> problem I am encountering has to do with the fact that $b-
>> build_elements appears to be cumulative in the above loop, even
> though $b is being recreated. That is, if one of the Build.PL files
> has ...
>
> $b->add_build_element('foo');
>
> ... then all subsequent $dist's in the above loop will attempt to
> build foo elements even though the corresponding Build.PL does not
> mention foo anywhere.
>
> I believe the %valid_properties closure in
> Module::Build::Base::ACTION_config_data is the culprit. Is this a
> bug? Shouldn't the list of build_elements (all config data, in fact)
> be an object property as opposed to class data?
>
> Any suggestions for a workaround to start over with a completely
> fresh, clean M::B at the beginning of each loop?
>
> Thanks,
> - Ray
>
> * Consisting of a base package A and add-on packages B, as described
> in yesterday's post "M::B subclass .pm file locations".
>
>
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: Ray Z. <rz...@co...> - 2006-06-02 13:56:41
|
I have an automated build, test and install process for a collection
of in-house Perl packages* using a straightforward procedure which is
basically ...
foreach my $dist ( @dist_list ) {
my $dir = File::Spec->join('my_build_dir', $dist);
chdir $dir or die "could not change to $dir";
$p = { <some build options> };
my $b = Module::Build->new_from_context( %$p );
$b->dispatch('build');
$b->dispatch('test');
$b->dispatch('install');
}
I ran into a problem when attempting to convert everything from using
a slightly modified version of M::B 0.2608 to M::B 0.2801. The
problem I am encountering has to do with the fact that $b-
>build_elements appears to be cumulative in the above loop, even
though $b is being recreated. That is, if one of the Build.PL files
has ...
$b->add_build_element('foo');
... then all subsequent $dist's in the above loop will attempt to
build foo elements even though the corresponding Build.PL does not
mention foo anywhere.
I believe the %valid_properties closure in
Module::Build::Base::ACTION_config_data is the culprit. Is this a
bug? Shouldn't the list of build_elements (all config data, in fact)
be an object property as opposed to class data?
Any suggestions for a workaround to start over with a completely
fresh, clean M::B at the beginning of each loop?
Thanks,
- Ray
* Consisting of a base package A and add-on packages B, as described
in yesterday's post "M::B subclass .pm file locations".
|
|
From: Ray Z. <rz...@co...> - 2006-06-01 21:37:37
|
I'm looking for recommendations for how where to put my Module::Build sub-classes and how to set up @INC to find them. Here's my scenario ... I'm working with a set of Perl packages that are organized as a base package A with a number of add-on packages. Let's call one of the add-on packages B. So A is a prerequisite for B (i.e. A must be installed in order to build, test and install any of B). I have a common Module::Build sub-class, call it Bbuilder, that I use for all B. Since A must be installed in order to build B anyway, it seems logical to have Bbuilder.pm be included as part of A. To build A, I have another M::B sub-class, call it Abuilder, which is a sub-class of Bbuilder. If Bbuilder.pm is placed in A/lib, it gets installed as part of A and the Build.PL script for B is very straightforward. The question is, where do I put Abuilder.pm, and how do I manipulate @INC inside the Build.PL script for A to get what I want. Are there conventions for where to put these things? I'm currently thinking of putting Abuilder.pm in A/t and Bbuilder in A/lib and doing ... use lib qw( lib t ); require Abuilder; ... at the beginning of Build.PL. Any better ideas? Ray Zimmerman Director, Laboratory for Experimental Economics and Decision Research 428-B Phillips Hall, Cornell University, Ithaca, NY 14853 phone: (607) 255-9645 |
|
From: Eric W. <scr...@gm...> - 2006-05-29 17:09:58
|
# from Ken Williams
# on Sunday 28 May 2006 03:35 pm:
>In this thread the submitter describes a situation where he's seeing =A0
>the old "Argument list too long" error on Fedora Core when the test =A0
>suites try to run Build.PL scripts.
And here I was thinking this was a shell thing. I guess I should have=20
known better from the fact that the value is set as a kernel constant.
perl -e 'system(qw(perl -e), q(print @ARGV), 0..0xFFFF) and warn "$!";'
>Any idea what we should do here, and/or how this popped up again? =A0
>Assuming this is a problem with a long @INC, I was thinking we should
> =A0 perhaps optionally (default true?) not include any non-existent,
> absolute @INC entries in run_perl_script() or wherever it is that's
> currently failing.
If reducing @INC to the set of unique and existent entries doesn't do=20
the trick, maybe you could create a temp (or _build) file with a bunch=20
of 'use lib' statements and -Mthat instead?
If the longness comes from parameters, you could try xargs, but that=20
seems bound to cause trouble.
=2D-Eric
=2D-=20
Atavism n: The recurrence of any peculiarity or disease of an ancestor
in a subsequent generation, usually due to genetic recombination.
=2D--------------------------------------------------
http://scratchcomputing.com
=2D--------------------------------------------------
|
|
From: Ken W. <ke...@ma...> - 2006-05-28 22:35:50
|
Hi, http://rt.cpan.org/Ticket/Display.html?id=19406 In this thread the submitter describes a situation where he's seeing the old "Argument list too long" error on Fedora Core when the test suites try to run Build.PL scripts. Any idea what we should do here, and/or how this popped up again? Assuming this is a problem with a long @INC, I was thinking we should perhaps optionally (default true?) not include any non-existent, absolute @INC entries in run_perl_script() or wherever it is that's currently failing. -Ken |
|
From: Marvin H. <ma...@re...> - 2006-05-23 06:22:48
|
On May 22, 2006, at 4:58 PM, Randy W. Sims wrote: > Currently the only solution is to make the dependency explicit in > your module's build files by listing EU::CBuilder in > 'build_requires' as you already observed. OK, that's what I'll do. It's an easy workaround. Should ExtUtils::ParseXS get listed there, too? > I wonder if there should be a better way to express this > dependency. Maybe it could be declared like this: > > use Module::Build features => qw( C_support ); > > Instead of having indirect prereqs listed in build files where it > really has nothing directly to do with the distro. Module::Build > could then do whatever magic is needed under the hood to add the > appropriate prereqs. It seems to me that some items imply C_support -- otherwise they're not of any use. I'm thinking c_source, xs_files, etc. It's a little weird to have each one of them depend on an optional module. At the least they need to be documented. Better, IMO would be either transparent recognition that CBuilder is needed, or arranging to have CBuilder installed along with every Module::Build but not necessarily functional (if that's possible). Marvin Humphrey Rectangular Research http://www.rectangular.com/ |
|
From: Randy W. S. <ml...@th...> - 2006-05-23 00:06:26
|
Marvin Humphrey wrote: > Greets, > > It looks like in some cases my XS distro KinoSearch may not be able to > installed via CPAN without extra intervention since the release of > Module::Build 0.28. The problem seems to arise when Module::Build has > not been installed, and the passthrough Makefile.PL gets called. After > you reply yes at the prompt asking if you want to install Module::Build, > it installs without ExtUtils::CBuilder, even on systems where > ExtUtils::CBuilder can be installed later via the CPAN shell without a > problem. > > Is the answer to add ExtUtils::CBuilder to the build_requires hash? Hmm, Module::Build itself doesn't require EU::CBuilder, so it is only a recommended prereq. BUT, modules that use M::B may have an indirect & implicit dependency on EU::CBuilder. I.E. They depend on an optional feature of M::B. This dependency is never explicitly mentioned anywhere so installs can fail. Currently the only solution is to make the dependency explicit in your module's build files by listing EU::CBuilder in 'build_requires' as you already observed. I wonder if there should be a better way to express this dependency. Maybe it could be declared like this: use Module::Build features => qw( C_support ); Instead of having indirect prereqs listed in build files where it really has nothing directly to do with the distro. Module::Build could then do whatever magic is needed under the hood to add the appropriate prereqs. Randy. |
7 messages has been excluded from this view by a project administrator.
