module-build-general — General discussion about Module::Build project

Re: [Module::Build] PERL_MM_USE_DEFAULT

[Randy W. S. <ml...@th...>]

Yitzchak Scott-Thoennes wrote:
> On Thu, Apr 06, 2006 at 07:05:19AM -0400, Randy W. Sims wrote:
> 
>>Yitzchak Scott-Thoennes wrote:
>>
>>>On Tue, Mar 07, 2006 at 05:33:49AM -0500, Randy W. Sims wrote:
>>>
>>>
>>>>Sorry for responding late to this, but won't this break exististing 
>>>>distributions? Distros that currently use y_n() without defaults will 
>>>>start die-ing when users upgrade M::B.
>>
>>>It doesn't break them in the sense that they were already broken for some 
>>>users.  But maybe it would be better to pick an arbitrary default?
>>
>>I don't think there is a reasonable default.
> 
> 
> That's why I suggested an arbitrary one :)
> 
> 
>>I think the only way around 
>>the issue is to create new methods and deprecate the older ones or not 
>>require defaults.
> 
> 
> If you have a deprecated y_n method and replacements with longer names,
> people will continue to use y_n :(
> 
> 
>>It's not reasonable to have Build scripts failing just 
>>because a user upgrades to a new version of Module::Build.
>>
>>This needs to be resolved before 0.28. Any other ideas for solutions?
> 
> 
> I'll try to come up with one or more suggestions.

$builder->ask( prompt => "Do you want to continue?",
                options => ['&yes' '&no' 'may&be'],
                default => 'b',
              );

 > Do you want to continue? (Yes/No/mayBe) [b]

$builder->ask( prompt => "Enter your user name:",
                options => [],
                default => 'guest'
             );

 > Enter your username: [guest]

$builder->ask( prompt => "Enter your user name:",
                options => [],
                default => 'guest',
                hide_default => 1,
             );

 > Enter your username:


or Something like that ?

Randy.

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Apr 6, 2006, at 03:54, Randy W. Sims wrote:

> David, could you let me know if this provides a solid interim =20
> solution to the issues you've brought up. The repository has now =20
> moved to a subversion repository at <https://svn.perl.org/modules/=20
> Module-Build/> if you want to check it out.

Yeah, looks great. I was able to patch my subclass thusly:

Index: Base.pm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- Base.pm	(revision 2767)
+++ Base.pm	(working copy)
@@ -473,15 +473,15 @@
      }
      # Prevent installation into lib/perl5. We just want lib'.
-    $self->install_base_relpaths->{lib} =3D ['lib'];
+    $self->install_base_relpaths(lib =3D> 'lib');
      # Add www element and install path.
      $self->add_build_element('www');
-    $self->install_base_relpaths->{www} =3D ['www'];
+    $self->install_base_relpaths(www =3D> 'www');
      # Add config file element and install path.
      $self->add_build_element('conf');
-    $self->install_base_relpaths->{conf} =3D ['conf'];
+    $self->install_base_relpaths(conf =3D> 'conf');
      # Prompts.
      for my $class ( reverse Class::ISA::self_and_super_path(ref =20
$self) ) {

And it just worked. Sweet=97thanks!

David=

Re: [Module::Build] Link to cons

[Ken W. <ke...@ma...>]

Hi Nadim,

Sure, I'd be happy to add this link.  I wasn't sure whether cons was  
still active or not, but I'm glad to add something that is.

  -Ken


On Apr 5, 2006, at 2:43 PM, Nadim Khemir wrote:

> Hi,
>
> This is,somehow, little spammy. My apologies if this is an  
> inconveniance.
>
> Since you have a link to 'cons', an old, unmaintained sytem that  
> is, IMVHO,
> not that good and that doesn't allow you to use 'strictness', maybe  
> you could
> put a link to:
>
> http://search.cpan.org/~nkh/PerlBuildSystem-0.35/
>
> a new, maintained, quite good, easy and "forcing" you to stricness  
> module.
>
> PBS is more like make than cons/scons; it uses rules.
>
> Version 0.40 of PBS is comming out very soon and it _is_ better but  
> 0.35 will
> have to do the comming weeks. PBS welcomes new developers. Anyone  
> wanting to
> build a gmake interface (bits are done in makepp)? Work on super
> parallelization of builds for extremely big systems (in the 100  
> miilions
> lines code)? Any help, comments, welcome.

Re: [Module::Build] PERL_MM_USE_DEFAULT

[Yitzchak Scott-T. <sth...@ef...>]

On Thu, Apr 06, 2006 at 07:05:19AM -0400, Randy W. Sims wrote:
> Yitzchak Scott-Thoennes wrote:
> >On Tue, Mar 07, 2006 at 05:33:49AM -0500, Randy W. Sims wrote:
> >
> >>Sorry for responding late to this, but won't this break exististing 
> >>distributions? Distros that currently use y_n() without defaults will 
> >>start die-ing when users upgrade M::B.
> 
> >It doesn't break them in the sense that they were already broken for some 
> >users.  But maybe it would be better to pick an arbitrary default?
> 
> I don't think there is a reasonable default.

That's why I suggested an arbitrary one :)

> I think the only way around 
> the issue is to create new methods and deprecate the older ones or not 
> require defaults.

If you have a deprecated y_n method and replacements with longer names,
people will continue to use y_n :(

> It's not reasonable to have Build scripts failing just 
> because a user upgrades to a new version of Module::Build.
> 
> This needs to be resolved before 0.28. Any other ideas for solutions?

I'll try to come up with one or more suggestions.

[Module::Build] .modulebuildrc documentation out of sync with code

[David G. <da...@hy...>]

I posted this to RT, but I'll copy here as well:

Documentation for the location of .modulebuildrc says .modulebuildrc 
should be placed in $ENV{HOME}, but the code actually searches the 
following environment variables: APPDATA HOME USERPROFILE WINDIR SYS$LOGIN.

This is particularly confusing because HOME isn't listed first, so a
.modulebuildrc file place in $ENV{HOME} just mysteriously fails to work
on Win32 where $ENV{APPDATA} exists.

Re: [Module::Build] PERL_MM_USE_DEFAULT

[Randy W. S. <ml...@th...>]

Yitzchak Scott-Thoennes wrote:
> On Tue, Mar 07, 2006 at 05:33:49AM -0500, Randy W. Sims wrote:
> 
>>Sorry for responding late to this, but won't this break exististing 
>>distributions? Distros that currently use y_n() without defaults will 
>>start die-ing when users upgrade M::B.

> It doesn't break them in the sense that they were already broken for some users.  But maybe it would be better to pick an arbitrary default?

I don't think there is a reasonable default. I think the only way around 
the issue is to create new methods and deprecate the older ones or not 
require defaults. It's not reasonable to have Build scripts failing just 
because a user upgrades to a new version of Module::Build.

This needs to be resolved before 0.28. Any other ideas for solutions?

Regards,
Randy.

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Mar 6, 2006, at 17:51, Randy W. Sims wrote:
>> Maybe we can change them to accept a new value, and then document  
>> them. that would be a simple and effective interim solution:
>>
>>   $self->install_base_relpath();  # deprecated; returns reference  to 
>> internal data
>>   $self->install_base_relpath($elem); # returns path for $elem
>>   $self->install_base_relpath($elem => $new_val); # sets path for  $elem
> 
> Sure.

I know we're trying to push 0.28 out, but the whole issue of supporting 
custom install types is nagging at me. I've documented and beefed up the 
interface for install_base_relpaths(), prefix_relpaths(), and 
install_path(). And improved the install_types() method to recognize 
elements added from the afore mentioned methods. Example below.

David, could you let me know if this provides a solid interim solution 
to the issues you've brought up. The repository has now moved to a 
subversion repository at <https://svn.perl.org/modules/Module-Build/> if 
you want to check it out.

Thanks,
Randy.

use Module::Build;
my $build_class = Module::Build->subclass(code => <<'---');

   sub new {
     my $package = shift;
     my $self = $package->SUPER::new(@_);
     $self->add_build_element('config');
     $self->install_base_relpaths(config => 'etc');
     $self->prefix_relpaths($self->installdirs, config => 'etc');
     return $self;
   }

   sub find_config_files {
     my $self = shift;
     return { 'etc/sample.conf' => 'config/Foo.conf' };
   }

   sub _warn_if_no_config {
     my $self = shift;
     $self->log_warn( "Config files will not be installed.\n" )
       unless $self->install_base()
           || $self->prefix()
           || $self->install_path('config');
   }

   sub ACTION_install {
     my $self = shift;
     $self->_warn_if_no_config();
     $self->SUPER::ACTION_install(@_);
   }

   sub ACTION_fakeinstall {
     my $self = shift;
     $self->_warn_if_no_config();
     $self->SUPER::ACTION_fakeinstall(@_);
   }

---

my $builder = $build_class->new(
     module_name => 'Foo',
     license     => 'perl',
);

$builder->create_build_script();

[Module::Build] Preserving files' executable bits, once more

[Julian M. <ju...@me...>]

Hi M::B developers,

in October 2004, I reported a bug that M::B wasn't preserving the=20
executable bits of files when creating a dist tarball (i.e. with the=20
"dist" action).[1]  The issue was resolved in M::B 0.27_01 by an addition=20
of chmodding code to the Module::Build::Base::ACTION_distdir() method.[2]

Now I'm experiencing a similar problem in a slightly different situation. =
=20
I have essentially the following in Build.PL:

| my $build =3D $class->new(
|     ...
|     install_path    =3D> {
|         ...
|         'etc-global'    =3D> '/etc'
|     },
|     misc_files      =3D> {
|         'misc/foo-bar'  =3D> 'etc-global/foo/bar'
|     },
|     ...
| );
|=20
| $build->add_build_element('misc');

The intent is to install misc/foo-bar to /etc/foo/bar (with /etc/foo/=20
belonging to another package and bar being a hook script), which basically=
=20
works ok.  misc/foo-bar has the executable bit set, however when the file=20
is copied to blib/etc-global/foo/bar, the x bit gets lost.

Is that by design?  If not, I hope this can be fixed before the release of=
=20
0.28.

Julian.

References:
 1. http://rt.cpan.org/Ticket/Display.html?id=3D8190
 2. http://sourceforge.net/mailarchive/message.php?msg_id=3D11494869

[Module::Build] Link to cons

[Nadim K. <na...@kh...>]

Hi, 

This is,somehow, little spammy. My apologies if this is an inconveniance.

Since you have a link to 'cons', an old, unmaintained sytem that is, IMVHO, 
not that good and that doesn't allow you to use 'strictness', maybe you could 
put a link to:

http://search.cpan.org/~nkh/PerlBuildSystem-0.35/

a new, maintained, quite good, easy and "forcing" you to stricness module.

PBS is more like make than cons/scons; it uses rules.

Version 0.40 of PBS is comming out very soon and it _is_ better but 0.35 will 
have to do the comming weeks. PBS welcomes new developers. Anyone wanting to 
build a gmake interface (bits are done in makepp)? Work on super 
parallelization of builds for extremely big systems (in the 100 miilions 
lines code)? Any help, comments, welcome.

Cheers, Nadim.

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

[Steve H. <ste...@uk...>]

UmFuZHkgVy4gU2ltcyB3cm90ZToKPiBPaywgSSBmaW5hbGx5IGdvdCBhcm91bmQgdG8gbG9va2lu
Zy4gVGhlIHByb2JsZW0gaXMgd2hlcmUgSSBzdXNwZWN0ZWQ6IAo+IEl0J3MgdGhlIHF1b3Rpbmcg
b2YgdGhlIG1hY3JvcyBWRVJTSU9OICYgWFNfVkVSU0lPTi4gT24gdGhlIGNvbW1hbmQgbGluZSAK
PiB5b3UgY2FuIHR5cGU6Cj4gCj4gIGJjYzMyIC1EVkVSU0lPTj1cIjEuMDFcIiB0ZXN0LmMKPiAK
PiBCdXQgd2UgdXNlIHJlc3BvbnNlIGZpbGVzIGZvciBhbGwgY29tcGlsZXJzIG9uIFdpbmRvd3Mg
KEdDQywgQkNDLCAmIAo+IE1TVkMpLCBhbmQgdGhlIHJlc3BvbnNlIGZpbGVzIHNlZW0gdG8gcmVx
dWlyZSBhIGRpZmZlcmVudCBxdW90aW5nIHN5bnRheCAKPiB0aGF0IEkgaGF2ZW4ndCBmaWd1cmVk
IG91dCB5ZXQuIEkndmUgdHJpZWQKPiAKPiAtRFZFUlNJT049XCIxLjAxXCIKPiBFcnJvciBFMjIw
NiB0ZXN0LmMgNzogSWxsZWdhbCBjaGFyYWN0ZXIgJ1wnICgweDVjKSBpbiBmdW5jdGlvbiBtYWlu
Cj4gRXJyb3IgRTIyMDYgdGVzdC5jIDc6IElsbGVnYWwgY2hhcmFjdGVyICdcJyAoMHg1YykgaW4g
ZnVuY3Rpb24gbWFpbgo+IEVycm9yIEUyMDYwIHRlc3QuYyA3OiBJbGxlZ2FsIHVzZSBvZiBmbG9h
dGluZyBwb2ludCBpbiBmdW5jdGlvbiBtYWluCj4gKioqIDMgZXJyb3JzIGluIENvbXBpbGUgKioq
Cj4gCj4gLURWRVJTSU9OPSIxLjAxIgo+IEVycm9yIEUyMDYwIHRlc3QuYyA3OiBJbGxlZ2FsIHVz
ZSBvZiBmbG9hdGluZyBwb2ludCBpbiBmdW5jdGlvbiBtYWluCj4gKioqIDEgZXJyb3JzIGluIENv
bXBpbGUgKioqCj4gCj4gQW5kIHNldmVyYWwgb3RoZXIgdmFyaWF0aW9ucyB0aGF0IGFsd2F5cyBy
ZXN1bHRzIGluIG9uZSBvZiB0aGUgZXJyb3JzIAo+IGFib3ZlLgo+IAo+IEkndmUgcG9zdGVkIG9u
IG9uZSBvZiB0aGUgYm9ybGFuZCBuZXdzZ3JvdXBzIHNlZSBpZiBhbnlvbmUgY2FuIGhlbHAgCj4g
dGhlcmUuIElmIEkgY2FuJ3QgZmluZCBhIHF1b3Rpbmcgc29sdXRpb24sIEkgZ3Vlc3MgSSBjYW4g
bW92ZSBtYWNyb3Mgb2YgCj4gdGhlIGtleT12YWx1ZSBmb3JtIGJhY2sgb250byB0aGUgY29tbWFu
ZGxpbmUsIGZvciBiY2MuCgpJIGdldCB0aGUgc2FtZSBwcm9ibGVtcyBoZXJlLiAgSSBmb3VuZCB0
aGF0IHlvdSBjYW4gdXNlICJjb25maWd1cmF0aW9uIApmaWxlcyIgKGxpa2UgInJlc3BvbnNlIGZp
bGVzIiwgYnV0IHRoZXkgb25seSBjb250YWluIGNvbXBpbGVyIG9wdGlvbnMsIApub3QgZmlsZW5h
bWVzIHRvbykgYW5kIHRoYXQgdGhlc2Ugd29yaywgYnV0IHlvdSBjYW4gb25seSBzZWVtIHRvIGhh
dmUgCm9uZSBvZiB0aGVtLgoKUnVubmluZyAiYmNjMzIgK3Rlc3QuY2ZnIHRlc3QuYyIgd2hlcmUg
dGVzdC5jZmcgY29udGFpbnMKCi1JIkM6XEJvcmxhbmRcQkNDNTVcSW5jbHVkZSIKLUwiQzpcQm9y
bGFuZFxCQ0M1NVxMaWIiCi1EVkVSU0lPTj1cIjEuMDFcIgoKd29ya3MsIGJ1dCBpZiB5b3Ugb21p
dCB0aGUgLUkgYW5kIC1MIGxpbmVzIHRoZW4gaXQgY2FuJ3QgZmluZCBzdGRpby5oIApldGMsIGku
ZS4gaXQgc2VlbXMgdG8gdXNlIHRoZSAuY2ZnIGZpbGUgc3BlY2lmaWVkIG9uIHRoZSBjb21tYW5k
LWxpbmUgCmluc3RlYWQgb2YgdGhlIGRlZmF1bHQgb25lIChyYXRoZXIgdGhhbiBpbiBhZGRpdGlv
biB0byBpdCksIHdoaWNoIApkb2Vzbid0IG1ha2UgaXQgdmVyeSB1c2VmdWwgOi0oCgpUaGF0IGp1
c3QgbWFrZXMgaXQgYWxsIHRoZSBtb3JlIGlycml0YXRpbmcgdGhhdCB0aGUgc2FtZSBxdW90aW5n
IGRvZXNuJ3QgCndvcmsgaW4gcmVzcG9uc2UgZmlsZXMuCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSYWRhbiBDb21wdXRhdGlvbmFsIEx0ZC4NCg0K
VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0
cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUg
YWRkcmVzc2VlKHMpIG9ubHkuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBl
cnJvciBvciB0aGVyZSBhcmUgYW55IHByb2JsZW1zLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg
aW1tZWRpYXRlbHkuIFRoZSB1bmF1dGhvcml6ZWQgdXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9y
IGFsdGVyYXRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IGZvcmJpZGRlbi4gTm90ZSB0
aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBlbWFpbCBhcmUgc29s
ZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQg
dGhvc2Ugb2YgUmFkYW4gQ29tcHV0YXRpb25hbCBMdGQuIFRoZSByZWNpcGllbnQocykgb2YgdGhp
cyBtZXNzYWdlIHNob3VsZCBjaGVjayBpdCBhbmQgYW55IGF0dGFjaGVkIGZpbGVzIGZvciB2aXJ1
c2VzOiBSYWRhbiBDb21wdXRhdGlvbmFsIHdpbGwgYWNjZXB0IG5vIGxpYWJpbGl0eSBmb3IgYW55
IGRhbWFnZSBjYXVzZWQgYnkgYW55IHZpcnVzIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwuCg==

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

[Randy W. S. <ml...@th...>]

Randy W. Sims wrote:
> Steve Hay wrote:
>> Builds fine for me @ 27707.  I would guess it's maybe a Borland setup 
>> problem.  Did you create the *.cfg files in its Bin/ directory?
> 
> Yeah, my bad. I remember needing to do that before, now that you've 
> mentioned it. I skimmed through the help doc that came with the 
> compiler, but I must of missed a readme somewhere. (It's not in perl's 
> README.win32 either.)
> 
> I'll try again sometime today, hopefully.
> 
> Good news is I think I know what the problem is from the verbose output 
> you posted.

Ok, I finally got around to looking. The problem is where I suspected: 
It's the quoting of the macros VERSION & XS_VERSION. On the command line 
you can type:

  bcc32 -DVERSION=\"1.01\" test.c

But we use response files for all compilers on Windows (GCC, BCC, & 
MSVC), and the response files seem to require a different quoting syntax 
that I haven't figured out yet. I've tried

-DVERSION=\"1.01\"
Error E2206 test.c 7: Illegal character '\' (0x5c) in function main
Error E2206 test.c 7: Illegal character '\' (0x5c) in function main
Error E2060 test.c 7: Illegal use of floating point in function main
*** 3 errors in Compile ***

-DVERSION="1.01"
Error E2060 test.c 7: Illegal use of floating point in function main
*** 1 errors in Compile ***

And several other variations that always results in one of the errors above.

I've posted on one of the borland newsgroups see if anyone can help 
there. If I can't find a quoting solution, I guess I can move macros of 
the key=value form back onto the commandline, for bcc.

Randy.

The test snippets I used are of the form:

test.c:
----------8<----------
#include <stdio.h>

int main()
{
   char *v;
   v = VERSION;
   printf("%s\n", v);
   return 0;
}
----------8<----------

test.rsp:
----------8<----------
-DVERSION=\"1.01\"
----------8<----------

With the command:

   bcc32 @test.rsp test.c

[Module::Build] Re: Smoke [5.9.4] 27706 FAIL(Xc) openbsd 3.8 (i386/1 cpu)

[Randy W. S. <ml...@th...>]

st...@mc... wrote:
> Automated smoke report for 5.9.4 patch 27706
> mccoy.peters.homeunix.org: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) (548 MHz) (i386/1 cpu)
>     on        openbsd - 3.8
>     using     cc version 3.3.5 (propolice)
>     smoketime 5 hours 32 minutes (average 1 hour 23 minutes)
> 
> Summary: FAIL(Xc)
> 
> O = OK  F = Failure(s), extended report at the bottom
> X = Failure(s) under TEST but not under harness
> ? = still running or test results not (yet) available
> Build failures during:       - = unknown or N/A
> c = Configure, m = make, M = make (after miniperl), t = make test-prep
> 
>    27706     Configuration (common) none
> ----------- ---------------------------------------------------------
> O X c -     
> c - - -     -Duse64bitint
> | | | +----- PERLIO = perlio -DDEBUGGING
> | | +------- PERLIO = stdio  -DDEBUGGING
> | +--------- PERLIO = perlio
> +----------- PERLIO = stdio
> 
> 
> Failures: (common-args) none
> [perlio] 
> Inconsistent test results (between TEST and harness):
>     ../lib/Module/Build/t/extend.t..........FAILED--expected 53 tests, saw 37
>     ../lib/Module/Build/t/basic.t...........FAILED--expected 55 tests, saw 0
>     ../lib/Module/Build/t/compat.t..........FAILED--expected 60 tests, saw 1

I'm not sure what's happening here. On FreeBSD, I get success on both 
`make test` and `./TEST`. It's also passing on the other BSDs: NetBSD & 
Darwin. And it looks like it passed on a previous build on this smoke 
box, with no changes made to M::B since the PASS.

Is this a real failure?

Randy.

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

[Randy W. S. <ml...@th...>]

Steve Hay wrote:
> Builds fine for me @ 27707.  I would guess it's maybe a Borland setup 
> problem.  Did you create the *.cfg files in its Bin/ directory?

Yeah, my bad. I remember needing to do that before, now that you've 
mentioned it. I skimmed through the help doc that came with the 
compiler, but I must of missed a readme somewhere. (It's not in perl's 
README.win32 either.)

I'll try again sometime today, hopefully.

Good news is I think I know what the problem is from the verbose output 
you posted. Bad news is our cvs repository on sf.net has been down since 
last week hindering our ability to make updates.

Thanks,
Randy.

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

[Steve H. <ste...@uk...>]

UmFuZHkgVy4gU2ltcyB3cm90ZToKPiBZaXR6Y2hhayBTY290dC1UaG9lbm5lcyB3cm90ZToKPj4g
T24gU2F0LCBBcHIgMDEsIDIwMDYgYXQgMDI6MDU6MDBQTSArMDAwMCwgU3RldmUgSGF5IHdyb3Rl
Ogo+Pj4gICAgIC4uL2xpYi9Nb2R1bGUvQnVpbGQvdC9wcG0udC4uLi4uLi4uLi4uLi5GQUlMRUQg
Mi0xMgo+Pj4gICAgIC4uL2xpYi9Nb2R1bGUvQnVpbGQvdC94cy50Li4uLi4uLi4uLi4uLi5GQUlM
RUQgMi02IDEwIDE2LTIyCj4+Cj4+IFZlcmJvc2Ugb3V0cHV0PwoKQXR0YWNoZWQuICBTb3JyeSBJ
J3ZlIGhhZCBubyB0aW1lIHRvIGxvb2sgYXQgdGhpcy4KCgo+IAo+IFRvIGJlIGhvbmVzdCwgaXQn
cyBiZWVuIGEgd2hpbGUgc2luY2UgSSd2ZSB0ZXN0ZWQgdGhlIGJvcmxhbmQgY29tcGlsZXIuIAo+
IEkgdXBncmFkZXMgYm90aCBteSBzeXN0ZW1zIGF0IGhvbWUgYW5kIHdvcmsgZWFybGllciBpbiB0
aGUgeWVhciwgYW5kIEkgCj4gaGF2ZW4ndCBnb3QgYXJvdW5kIHRvIHNldHRpbmcgaXQgdXAuCj4g
Cj4gSSBub3cgaGF2ZSBpdCBpbnN0YWxsZWQgYW5kIEknbSB0cnlpbmcgdG8gYnVpbGQgcGVybCBA
IDI3NzA1LCBidXQgdGhlIAo+IGJ1aWxkIGZhaWxzIGJ1aWxkaW5nIEI6OkMgYmVjYXVzZSBpdCBj
YW4ndCBmaW5kIGFueSBvZiB0aGUgc3RhbmRhcmQgQyAKPiBoZWFkZXJzLgo+IAo+IExvZyBhdHRh
Y2hlZC4KPiAKPiBMb29rcyBsaWtlIGl0J3MgYnVpbGRpbmcgZmluZSBmb3IgU3RldmUuIEknbSB3
b25kZXJpbmcgaWYgbXkgY29uZmlnIGlzIAo+IGdvb2ZlZCBzb21laG93LCBhbHRob3VnaCBpdCBs
b29rcyBtb3JlIGxpa2UgYSBwcm9ibGVtIHdpdGggQm9ybGFuZHMgCj4gZ29vZnkgY29tbWFuZCBs
aW5lIHN5bnRheC4gSSdtIG5vdCByZWFsbHkgYW4gZXhwZXJ0IHdpdGggdGhlIEJvcmxhbmQgCj4g
Y29tcGlsZXIsIHNvIEknZCBiZSBncmF0ZWZ1bCBmb3Igc3VnZ2VzdGlvbnMuCgpCdWlsZHMgZmlu
ZSBmb3IgbWUgQCAyNzcwNy4gIEkgd291bGQgZ3Vlc3MgaXQncyBtYXliZSBhIEJvcmxhbmQgc2V0
dXAgCnByb2JsZW0uICBEaWQgeW91IGNyZWF0ZSB0aGUgKi5jZmcgZmlsZXMgaW4gaXRzIEJpbi8g
ZGlyZWN0b3J5PyAgSSBoYXZlIApCb3JsYW5kIGluc3RhbGxlZCBpbiBDOlxCb3JsYW5kXEJDQzU1
XHtCaW4sRXhhbXBsZXMsSGVscCxJbmNsdWRlLExpYn0gCmFuZCBJIGhhZCB0byBjcmVhdGUgdGhl
IGZvbGxvd2luZyB0d28gZmlsZXM6CgpDOlxCb3JsYW5kXEJDQzU1XEJpblxiY2MzMi5jZmcKLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi1JIkM6XEJvcmxhbmRcQkNDNTVcSW5jbHVkZSIK
LUwiQzpcQm9ybGFuZFxCQ0M1NVxMaWIiCgpDOlxCb3JsYW5kXEJDQzU1XEJpblxpbGluazMyLmNm
ZwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotTCJDOlxCb3JsYW5kXEJDQzU1XExp
YiIKCk90aGVyIHRoYW4gdGhhdCwgYWxsIEkgZGlkIHdhcyB0byBwdXQgQzpcQm9ybGFuZFxCQ0M1
NVxCaW4gaW4gbXkgUEFUSCAKYW5kIGl0IGp1c3Qgd29ya3Mgb3V0IG9mIHRoZSBib3guCgoKLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSYWRhbiBDb21w
dXRhdGlvbmFsIEx0ZC4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh
Z2UgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5k
IGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIElmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgbWVzc2FnZSBpbiBlcnJvciBvciB0aGVyZSBhcmUgYW55IHByb2JsZW1zLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuIFRoZSB1bmF1dGhvcml6ZWQgdXNlLCBkaXNj
bG9zdXJlLCBjb3B5aW5nIG9yIGFsdGVyYXRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5
IGZvcmJpZGRlbi4gTm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4g
dGhpcyBlbWFpbCBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNl
c3NhcmlseSByZXByZXNlbnQgdGhvc2Ugb2YgUmFkYW4gQ29tcHV0YXRpb25hbCBMdGQuIFRoZSBy
ZWNpcGllbnQocykgb2YgdGhpcyBtZXNzYWdlIHNob3VsZCBjaGVjayBpdCBhbmQgYW55IGF0dGFj
aGVkIGZpbGVzIGZvciB2aXJ1c2VzOiBSYWRhbiBDb21wdXRhdGlvbmFsIHdpbGwgYWNjZXB0IG5v
IGxpYWJpbGl0eSBmb3IgYW55IGRhbWFnZSBjYXVzZWQgYnkgYW55IHZpcnVzIHRyYW5zbWl0dGVk
IGJ5IHRoaXMgZW1haWwuCg==

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

[Randy W. S. <ml...@th...>]

Yitzchak Scott-Thoennes wrote:
> On Sat, Apr 01, 2006 at 02:05:00PM +0000, Steve Hay wrote:
>>     ../lib/Module/Build/t/ppm.t.............FAILED 2-12
>>     ../lib/Module/Build/t/xs.t..............FAILED 2-6 10 16-22
> 
> Verbose output?

To be honest, it's been a while since I've tested the borland compiler. 
I upgrades both my systems at home and work earlier in the year, and I 
haven't got around to setting it up.

I now have it installed and I'm trying to build perl @ 27705, but the 
build fails building B::C because it can't find any of the standard C 
headers.

Log attached.

Looks like it's building fine for Steve. I'm wondering if my config is 
goofed somehow, although it looks more like a problem with Borlands 
goofy command line syntax. I'm not really an expert with the Borland 
compiler, so I'd be grateful for suggestions.

Randy.

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

[Yitzchak Scott-T. <sth...@ef...>]

On Sat, Apr 01, 2006 at 02:05:00PM +0000, Steve Hay wrote:
>     ../lib/Module/Build/t/ppm.t.............FAILED 2-12
>     ../lib/Module/Build/t/xs.t..............FAILED 2-6 10 16-22

Verbose output?

Re: [Module::Build] Fwd: Module::Build integration with revision control and other goodies I need

[John P. <jpe...@ro...>]

Nadim Khemir wrote:
> I use SVK (though it has seriously upset me lately) and here are the things 
> I'd like to do (no particular order):
> 
> -when I do a 'dist', I want a CHANGES to be generated automatically

See most any of my modules on CPAN for code like this:

use Module::Build;

my $class = Module::Build->subclass
(
    class => 'Your::Module::Name::Builder',
    code => q{
    sub ACTION_dist{
        my $self = shift;
        $self->do_system('svk log -x | gnuify-changelog.pl > Changes');
        $self->SUPER::ACTION_dist();
        };
    },
);

my $m = $class->new
    ( module_name     => 'Your::Module::Name',
      license         => 'perl',
      requires        => {
          'Module::Build' => 0.2611,
      },
...blah...blah...blah...
     );

$m->create_build_script;

> - I want the version to be major.minor.revision and I want that to be 
> automatic of course

Not currently easy, either with SVK or SVN; I'm hoping to get some time to work
on inherited properties, which will make this much easier.  The problem is two-fold:

A) Need a way to determine, automatically, which sub-version to increment based
on some sort of external criteria;

B) Need to populate all of the correct files with the new $VERSION; it is
sometimes impossible to have all sub-modules share the same $VERSION as the
master module (because during testing, the submodule may inherit the wrong
$VERSION, e.g. the installed master module rather than the testing).

This is something I intend to add to Module::Release at some point (see below).
 I have a preliminary cut at version::Math which will make generating the
appropriate $VERSION much easier.  I forsee something like

	$ release --minor

which would bump the minor and set the revision to 0.  'release' should be smart
enough that if you don't pass any parameter, and the associated $VERSION tag
already exists to bump the revision instead.  This behavior should probably be
set in .releaserc.

> - The MANIFEST could also be automatically extracted from what I check in.

You can use Module::Release (and the commandline 'release' script) to automate
this (or at the very least to see which files didn't get added).  'Build
distclean' will also warn about which files exist but aren't in MANIFEST.  I
don't personally want MANIFEST built automatically from checkins, because in
more than one occasion, I have files in the repository that are used to automate
certain testing setup, but should not be distributed with the public release.

> - The dependencies  my modules have shouldn't have to be explicitely written 
> but extracted

See Module::Info for a way to extract this information; creating dependencies
automatically is left as an exercise for the programmer. ;-)

> - commit shouldn't (must not?) be allowed if testing fails.

'release' will not upload the module to CPAN or SourceForge unless both 'test'
and 'disttest' pass.

As far as I am concerned, none of this functionality belongs in Module::Build,
which works in a very different problem space.  I see SVK and Module::Build
being tangential to each other, and would rather see Module::Release improved to
automate these tasks.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

[Module::Build] Re: New Module::Build released

[Yitzchak Scott-T. <sth...@ef...>]

On Thu, Mar 30, 2006 at 10:33:04AM +0200, Rafael Garcia-Suarez wrote:
> Randy W. Sims wrote:
> > 
> > If there is, I was never able to find it. I started to write one, but 
> > it's not simple to write a generic one. For ex. MB has to be built first 
> > and the generated M::B::ConfigData copied. I don't know if other 
> > dual-life modules have similar generated files or exceptions. I guess 
> > with the limited number of modules in core a few exceptions would be ok.
> 
> I don't think that's the case for other CPAN modules.
> Currently M::B is in lib/, which means it has no Makefile.PL like
> modules in ext/. However the config_data script is extracted from
> utils/config_data.PL at the end of the build process.
> How is ConfigData.pm generated actually ?

Background: any Module::Build-built module can have a Foo::ConfigData
containing user configuration options, later modifiable via the
config_data script.  Some modules may set information in it at
Build.PL run-time so it's created on the user's system, not the module
author's system, but for Module::Build itself, this isn't necessary.

See Module::Build::Base::ACTION_config_data and
Module::Build::Notes::write_config_data.

> > I put together diffs and tested them last night when I saw the version 
> > bump, so I'll go ahead and post them.
> > 
> > eucb.diff upgrades ExtUtils::CBuilder to 0.18
> > mb.diff upgrades Module::Build to 0.27_10
> 
> Both applied as #27631, thanks.

Re: [Module::Build] Fwd: Module::Build integration with revision control and other goodies I need

[Nadim K. <na...@kh...>]

On Sunday 02 April 2006 07.27, Dr Bean wrote:
> On Sat, 01 Apr 2006, Nadim Khemir wrote:
> > - integrating M::B with one's version control tool (version number,
> > CHANGES, ...)
>
> I have often wanted to ask that question here. Originally, they
> were separate in my mind. I was developing using version control
> and then bringing in M::B to publish it.
>
> Then I thought about how they should be integrated, and now I am
> mostly using module-starter --mb, before doing any development at
> all and throwing the whole lot into a repository, even though
> that means working 3 or 4 directories deep in lib.
>
> My latest project, however, I am using 'sudo ./Build install'
> with every hack, because the development is spread out over my
> home directory, and being lax about committing. I haven't been
> doing any committing at all.
 May I ask why you aren't committing anything?

A first thing would be to list what we use for version control and what we 
want to achieve. I'll tell my story and hope other will add their.

I use SVK (though it has seriously upset me lately) and here are the things 
I'd like to do (no particular order):

-when I do a 'dist', I want a CHANGES to be generated automatically

- I want the version to be major.minor.revision and I want that to be 
automatic of course

- The MANIFEST couls also be automatically extracted from what I check in.

- The dependencies  my modules have shouldn't have to be explicitely written 
but extracted

- commit shouldn't (must not?) be allowed if testing fails.

this is what I can think about for the revision control/M::B interaction but 
there might be other goodies to find.

Nadim.

Re: [Module::Build] Fwd: Module::Build integration with revision control and other goodies I need

[Dr B. <gr...@mo...>]

On Sat, 01 Apr 2006, Nadim Khemir wrote:

> - integrating M::B with one's version control tool (version number, 
> CHANGES, ...)

I have often wanted to ask that question here. Originally, they
were separate in my mind. I was developing using version control
and then bringing in M::B to publish it.

Then I thought about how they should be integrated, and now I am
mostly using module-starter --mb, before doing any development at
all and throwing the whole lot into a repository, even though
that means working 3 or 4 directories deep in lib.

My latest project, however, I am using 'sudo ./Build install'
with every hack, because the development is spread out over my
home directory, and being lax about committing. I haven't been
doing any committing at all.

Which is the opposite of the way I started out.

I would like some guidance too.

-- 
Dr Bean                   Some are born autonomous. Some achieve autonomy.
                          And some have autonomy thrust upon them.
                          --Dr Bean

Re: [Module::Build] Fwd: Module::Build integration with revision control and other goodies I need

[Nadim K. <na...@kh...>]

So, It has been a few days since this the original mail was send. I'm very 
surprised that no one is interrested in:

- integrating M::B with one's version control tool (version number, 
CHANGES, ...)

- making sure one's project installs properly with 'cpan'

- make the 'install' target work without M::B involvment

- thnking about how to make M::B do more things

Of course if you have all these questions sorted out, a simple URL to where I 
can find these answers would be very welcome.

Cheers, Nadim.

Re: [Module::Build] Build requirements

[Ken W. <ke...@ma...>]

Certainly.  We already have a distinction between 'requires' and  
'build_requires', so a meta-level tool like CPAN or CPANPLUS can  
choose where to make the 'build_requires' modules available.

  -Ken


On Mar 31, 2006, at 6:42 AM, Johan Vromans wrote:

> Hi,
>
> Modules can have dependencies (required for their everyday use) and
> build requirements (required for building and testing the module
> before installing it).
>
> Would it be possible to have these build-required modules installed in
> an alternative location so they do not clobber the production
> environment?

[Module::Build] Build requirements

[Johan V. <jvr...@sq...>]

Hi,

Modules can have dependencies (required for their everyday use) and
build requirements (required for building and testing the module
before installing it).

Would it be possible to have these build-required modules installed in
an alternative location so they do not clobber the production
environment?

-- Johan

[Module::Build] Re: Module::Build and installing in non-standard locations

[Matisse E. <ma...@ma...>]

On Thu, 30 Mar 2006, Randy W. Sims wrote:
> Note that the entries in install_path must have the same name as 
> supplied to add_build_element() (not with the '_files' appendage).

OK - thanks again, that is my problem... the naming of the entries...

I was too dense to appreciate your note about the first element of the
blib subdirectory having to match the new build element type.

I actually found this by going through the Module::Build::Base source code 
and found that   install_map()   was looking

I've re-written your example, using   some_new_type  to
possibly make this more clear to slow folks like myself.


##############################################################
use strict;
use warnings;

my $installation_dir = '/some/special/path';

use Module::Build;
my $builder = Module::Build->new(
     module_name  => 'Foo',
     license      => 'perl',
     some_new_type_files => {
         'dir/in/distro/httpd.conf' => 'some_new_type/httpd.conf',
         # ^^^^^^^^^^^^^^^^^^^^^^^      ^^^^^^^^^^^^^^^^^^^^^^^^
         # location in distriibution    location in blib
     },

     install_path => {
         'some_new_type' => $installation_dir,
     },
);

$builder->add_build_element( 'some_new_type' );

$builder->create_build_script();

[Module::Build] Re: Module::Build and installing in non-standard locations

[Randy W. S. <ml...@th...>]

Matisse Enzer wrote:
> On Tue, 28 Mar 2006, Randy W. Sims wrote:
> 
>> There are a number of ways to do this. The most simple is:
>>
>> use strict;
>> use warnings;
>>
>> use File::HomeDir;
>> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );
>>
>> use Module::Build;
>> my $builder = Module::Build->new(
>>      module_name  => 'Foo',
>>      license      => 'perl',
>>
>>      conf_files => {
>>          'etc/httpd.conf' => 'conf/httpd.conf',
>>      },
>>
>>      install_path => {
>>          'conf' => $conf_dir,
>>      },
>> );
>>
>> $builder->add_build_element( 'conf' );
>>
>> $builder->create_build_script();
>>
>> __END__
> 
> I haven't been able to get this approach to work.
> 
> The file(s) from the new build_element *do* get copied into blib, so in 
> the above example   httpd.conf   gets copied to  blib/conf/httpd.conf
> but, when i do     Build install    it does not get installed.
> 
> I looked in   _build/build_params   and the   install_path  hash
> does contain an entry for my new build element(s), but nothing gets 
> installed there when I run  ./Build install  (and  ./Build fakesinstall  
> doesn't show the files either.)

Did you try the script as above? I tested it on M::B 0.2612 & 0.27x from 
cvs. Can you post your Build.PL script?

Note that the entries in install_path must have the same name as 
supplied to add_build_element() (not with the '_files' appendage).

Regards,
Randy.

(Who hasn't been able to access sf.net cvs repository for +15 hrs now.)