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

RE: [Module::Build] Use of manifest action produces ExtUtils::Manifest warnings

[<kev...@ub...>]

Ken / Michael

KR> If my package contains a MANIFEST.SKIP file, then the build action
KR> (which has to be run before the manifest action)

KW> The 'build' action doesn't need to be run before the 'manifest' =
action=20
KW> - I guess you mean the "perl Build.PL" step.

Yes, sorry.

MS> You shouldn't get a warning about not having a MANIFEST from =
Build.PL.
MS> Why?  Consider how you generate a MANIFEST...
MS>    ./Build manifest
MS>What do you have to do before you can run ./Build?  *Bonk*  =
Enlightenment. :)

Exactly :-)

Cheers
Kevin

+ANYTHING+BELOW+WAS+ADDED+AFTER+I+HIT+SEND+

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

RE: [Module::Build] MANIFEST messages sent to stderr

[<kev...@ub...>]

Michael

>> When I run ./Build manifest, messages of the form:
>> Added to MANIFEST: foo
>> are written to stderr.  Could these messages be written to stdout =
instead?

> Unfortunately, ExtUtils::Manifest is documented to send all =
diagnostics
> to STDERR.  I can't change that without breaking backwards compat. :(
> Your best bet is to just ignore /^(Removed from|Added to) MANIFEST: /

Ok, thanks for the info.  That is the the workaround I am using already =
-
not a big problem.

Cheers
Kevin

+ANYTHING+BELOW+WAS+ADDED+AFTER+I+HIT+SEND+#

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: [Module::Build] [PATCH] make test failure report (Cygwin)

[Randy W. S. <Ra...@Th...>]

On 10/14/2003 11:04 PM, Randy W. Sims wrote:

> PS. I've attached output of the error I'm getting from t/runthrough.t on 
> Win2k for the archives.
> 
> not ok 23# Test 23 got: '<SOFTPKG NAME="Sample" VERSION="0,01,0,0">
> 
>     <TITLE>Sample</TITLE>
> </ABSTRACT>CT>Foo foo sample foo
>     <AUTHOR>Sample Man &lt;sa...@ex...&gt;</AUTHOR>
>     <IMPLEMENTATION>
>         <DEPENDENCY NAME="File-Spec" VERSION="0,0,0,0" />
>         <CODEBASE HREF="/path/to/codebase" />
>     </IMPLEMENTATION>
> </SOFTPKG>
> ' (t/runthrough.t at line 130)
> #    Expected: '<SOFTPKG NAME="Sample" VERSION="0,01,0,0">
>     <TITLE>Sample</TITLE>
>     <ABSTRACT>Foo foo sample foo</ABSTRACT>
>     <AUTHOR>Sample Man &lt;sa...@ex...&gt;</AUTHOR>
>     <IMPLEMENTATION>
>         <DEPENDENCY NAME="File-Spec" VERSION="0,0,0,0" />
>         <CODEBASE HREF="/path/to/codebase" />
>     </IMPLEMENTATION>
> </SOFTPKG>
> '
> Deleting Sample.ppd
> Deleting save_out
> Deleting Sample-0.01.tar.gz
> Deleting lib/Sample/Script
> Deleting blib
> Deleting _build
> Deleting Build

And here is the patch to fix it; It seems the line ending in the 
abstract was causing trouble. BTW, wouldn't it be better to use 
Pod::Parser in the dist_* routines for more acurate results?

This gets Cygwin Win2k working. Now I got figure out what is happening 
on Win9x.

Randy.

Re: [Module::Build] make test failure report (Cygwin)

[Randy W. S. <Ra...@Th...>]

On 10/11/2003 1:57 PM, Ken Williams wrote:

  > sub link_c {
>   my $self = shift;
>   my ($cf, $p) = ($self->{config}, $self->{properties}); # For convenience
>   my $flags = $p->{extra_linker_flags};
>   local $p->{extra_linker_flags} =
>     ['-L'.File::Spec->catdir($cf->{archlibexp}, 'CORE'),
>      '-lperl',
>      ref $flags ? @$flags : $self->split_like_shell($flags)];
>   return $self->SUPER::link_c(@_);
> }
> 
>  -Ken

This works very nicely. I see no reason not to go ahead and tack it onto 
cygwin.pm at this point.

-- 
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
                 - Alexander Pope

Re: [Module::Build] make test failure report (Cygwin)

[Randy W. S. <Ra...@Th...>]

On 10/14/2003 3:59 AM, Greg Matheson wrote:
> On Sat, 11 Oct 2003, Randy W. Sims wrote:
> 
> 
>>There is one problem left that has me kinda confused because I didn't 
>>see any signs of it in the log posted. If some other Cygwin users would 
>>place the attached file in their 
>><module-build-source>/lib/Module/Build/Platform/ directory, perform the 
>>build incantation, and post the results I would appreciate it as I'm 
>>suspicious that it might have something to do with my configuration.
> 
> 
> I have Gerrit Haase's debugging build of perl-5.8.0 on cygwin-1.3.22 on Win98.
> 
> Here is the output of ./Build test up until gdb takes over and XS code
> starts being tested. On Win98, there is/was a dll rebasing problem with 
> 5.8.0.
> 
> t/basic.........ok
> t/compat........# Failed test 5 in t/compat.t at line 25
> # Failed test 6 in t/compat.t at line 32
> # Test 7 got: 'MAKE TEST
> ' (t/compat.t at line 33)
> #   Expected: qr{(?-xism:DONE\.|SUCCESS)}
> # Failed test 8 in t/compat.t at line 35
> # Failed test 11 in t/compat.t at line 54: Makefile shouldn't exist
> # Failed test 14 in t/compat.t at line 54 fail #2: Makefile shouldn't exist
> # Failed test 18 in t/compat.t at line 25 fail #2
> # Failed test 19 in t/compat.t at line 32 fail #2
> # Test 20 got: 'MAKE TEST
> ' (t/compat.t at line 33 fail #2)
> #    Expected: qr{(?-xism:DONE\.|SUCCESS)}
> # Failed test 21 in t/compat.t at line 35 fail #2
> # Failed test 24 in t/compat.t at line 54 fail #3: Makefile shouldn't exist
> # Failed test 27 in t/compat.t at line 54 fail #4: Makefile shouldn't exist
> # Failed test 31 in t/compat.t at line 25 fail #3
> # Failed test 32 in t/compat.t at line 32 fail #3
> # Test 33 got: 'MAKE TEST
> ' (t/compat.t at line 33 fail #3)
> #    Expected: qr{(?-xism:DONE\.|SUCCESS)}
> # Failed test 34 in t/compat.t at line 35 fail #3
> # Failed test 37 in t/compat.t at line 54 fail #5: Makefile shouldn't exist
> # Failed test 40 in t/compat.t at line 54 fail #6: Makefile shouldn't exist
> FAILED tests 5-8, 11, 14, 18-21, 24, 27, 31-34, 37, 40
> 	Failed 18/41 tests, 56.10% okay
> t/extend........ok
> t/install.......ok
> t/manifypods....ok
> t/notes.........ok
> t/runthrough....ok
> t/signature.....GNU gdb 2003-03-03-cvs (cygwin-special)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)...
> Attaching to program `/usr/bin/PERL.EXE', process -1028635
>     113 [main] perl 412467 sync_with_child: WaitForMultipleObjects timed out
> skipped
>         all skipped: Skipping unless $ENV{TEST_SIGNATURE} is true
> t/versions......ok
> t/xs............Creating library file: libXSTest.dll.a
> Creating library file: libXSTest.dll.a
> C:\CYGWIN\BIN\PERL.EXE: *** couldn't allocate memory 0x10000(4128768) for 'C:\CYGWIN\LIB\PERL5\5.8.0\CYGWIN-MULTI-64INT\AUTO\POSIX\POSIX.DLL' alignment, Win32 error 8
> 
>     533 [main] perl 1029071 sync_with_child: child -1028803(0x114) died before initialization with status code 0x1
>    2147 [main] perl 1029071 sync_with_child: *** child state child loading dlls
> C:\CYGWIN\BIN\PERL.EXE: *** couldn't allocate memory 0x10000(4128768) for 'C:\CYGWIN\LIB\PERL5\5.8.0\CYGWIN-MULTI-64INT\AUTO\POSIX\POSIX.DLL' alignment, Win32 error 8
> 
> You can ignore all the stuff after gdb shows up. It appears that all
> t/runthrough tests pass. It's the t/compat ones which fail.
> 
> --
> Greg Matheson, Taiwan
> 
> 

Ahh, good! I was afraid that the results might be consistent; that would 
have made things much less interesting. ;)

Actually, this might point in the right direction after all. I suspect 
the different results are because of the differences in the IO subsystem 
between Win9x and Win2k (which is what I'm using).

It looks like most of the errors your getting are due to a cascading 
effect, i.e. it looks like only 1 or 2 tests are actually failing. If 
you would (or anyone else with Win9x & Cygwin), could you try running 
the test again with verbose output:
perl Build test test_files=t/compat.t verbose=1

Thanks for the help Greg.

Randy.

PS. I've attached output of the error I'm getting from t/runthrough.t on 
Win2k for the archives.

Re: [Module::Build] Use of manifest action produces ExtUtils::Manifest warnings

[Michael G S. <sc...@po...>]

On Tue, Oct 14, 2003 at 09:03:52PM -0500, Ken Williams wrote:
> They're both aware of MANIFEST.SKIP files, but the only purpose of a 
> MANIFEST.SKIP file is to help auto-generate a MANIFEST file.  If you 
> don't have a MANIFEST file, then that warning (or maybe something a 
> little more friendly) should indeed be emitted.
> 
> However, I just noticed that projects that use MakeMaker *don't* emit 
> any warnings in this situation.  I'm not sure what to make of that.  I 
> sort of think they should, but maybe not.  Schwern?

You shouldn't get a warning about not having a MANIFEST from Build.PL.
Why?  Consider how you generate a MANIFEST...

    ./Build manifest

What do you have to do before you can run ./Build?  *Bonk*  Enlightenment.
:)


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
gigaconway: a hypothetical unit of mind expansion, so disturbing it
  is likely to change the fundemental nature of the universe.  Some
  contend that gigaconway events, while rare, are much cheaper to produce
  than antiprotons, nuclear weapons or even XML specifications, and start
  at US$60,000 each.  If you believe gigaconway events are indeed possible,
  please send your tax deductable contributions to:

    The Conway Fund,
    c/o Yet Another Society
    http://www.yetanother.org/
	-- Ziggy	      

Re: [Module::Build] Use of manifest action produces ExtUtils::Manifest warnings

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

On Tuesday, October 14, 2003, at 11:18  AM, <kev...@ub...> 
wrote:

> Hi
>
> Toolchain:
> Module::Build v0.20
> Perl v5.8.0
>
> If my package contains a MANIFEST.SKIP file, then the build action
> (which has to be run before the manifest action)

The 'build' action doesn't need to be run before the 'manifest' action 
- I guess you mean the "perl Build.PL" step.


>  results in a
> warning of the following form:
>
> Checking whether your kit is complete...
> MANIFEST: No such file or directory at
> .../perl/5.8.0/lib/ExtUtils/Manifest.pm line 182
>
> Currently, I work around this by touching the MANIFEST file in
> a wrapper makefile.  However, I would think that either M::B or
> ExtUtils::Manifest (not sure which) needs to be updated to be
> aware of MANIFEST.SKIP files.

They're both aware of MANIFEST.SKIP files, but the only purpose of a 
MANIFEST.SKIP file is to help auto-generate a MANIFEST file.  If you 
don't have a MANIFEST file, then that warning (or maybe something a 
little more friendly) should indeed be emitted.

However, I just noticed that projects that use MakeMaker *don't* emit 
any warnings in this situation.  I'm not sure what to make of that.  I 
sort of think they should, but maybe not.  Schwern?

  -Ken

Re: [Module::Build] Use of manifest action produces ExtUtils::Manifest warnings

[Michael G S. <sc...@po...>]

On Tue, Oct 14, 2003 at 05:18:06PM +0100, kev...@ub... wrote:
> If my package contains a MANIFEST.SKIP file, then the build action
> (which has to be run before the manifest action) results in a
> warning of the following form:
> 
> Checking whether your kit is complete...
> MANIFEST: No such file or directory at
> .../perl/5.8.0/lib/ExtUtils/Manifest.pm line 182
> 
> Currently, I work around this by touching the MANIFEST file in
> a wrapper makefile.  However, I would think that either M::B or
> ExtUtils::Manifest (not sure which) needs to be updated to be
> aware of MANIFEST.SKIP files.

It looks like Module::Build::base::new() is calling check_manifest()
and then whinging because it doesn't exist.

Module::Build should check for the existence of a MANIFEST before
calling check_manifest() in that instance.

    $self->check_manifest if -r 'MANIFEST';

PS I'm not sure why MakeMaker makes calling check_manifest() conditional
on the Makefile not having been written.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
Playstation?  Of course Perl runs on Playstation.
    -- Jarkko Hietaniemi

Re: [Module::Build] MANIFEST messages sent to stderr

[Michael G S. <sc...@po...>]

On Tue, Oct 14, 2003 at 04:51:05PM +0100, kev...@ub... wrote:
> When I run ./Build manifest, messages of the form:
> 
> Added to MANIFEST: foo
> 
> are written to stderr.  Could these messages be written to stdout instead?
> I do not consider them to be errors.  The reason I care is that our build
> system sends emails if there are any build errors (whose definition includes
> messages sent to stderr).

Unfortunately, ExtUtils::Manifest is documented to send all diagnostics
to STDERR.  I can't change that without breaking backwards compat. :(

Your best bet is to just ignore /^(Removed from|Added to) MANIFEST: /


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
"How would you describe TKB? As a disk exerciser? The first manufacturer
 supplied computer virus?"
        -- Carl Friedberg in
                <047...@ba...>

Re: [Module::Build] MANIFEST messages sent to stderr

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

On Tuesday, October 14, 2003, at 10:51  AM, <kev...@ub...> 
wrote:
> When I run ./Build manifest, messages of the form:
>
> Added to MANIFEST: foo
>
> are written to stderr.  Could these messages be written to stdout 
> instead?
> I do not consider them to be errors.  The reason I care is that our 
> build
> system sends emails if there are any build errors (whose definition 
> includes
> messages sent to stderr).

Hi Kevin,

Those messages are generated by the ExtUtils::Manifest module, in the 
mkmanifest() function.  Your best bet would be to convince its 
maintainer to write those messages to STDOUT in a new version of the 
module, then upgrade to that new version.

  -Ken

[Module::Build] Use of manifest action produces ExtUtils::Manifest warnings

[<kev...@ub...>]

Hi

Toolchain:
Module::Build v0.20
Perl v5.8.0

If my package contains a MANIFEST.SKIP file, then the build action
(which has to be run before the manifest action) results in a
warning of the following form:

Checking whether your kit is complete...
MANIFEST: No such file or directory at
.../perl/5.8.0/lib/ExtUtils/Manifest.pm line 182

Currently, I work around this by touching the MANIFEST file in
a wrapper makefile.  However, I would think that either M::B or
ExtUtils::Manifest (not sure which) needs to be updated to be
aware of MANIFEST.SKIP files.

Regards
Kevin

+ANYTHING+BELOW+WAS+ADDED+AFTER+I+HIT+SEND+

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

[Module::Build] MANIFEST messages sent to stderr

[<kev...@ub...>]

Hi

Toolchain:
Module::Build v0.20
Perl v5.8.0

When I run ./Build manifest, messages of the form:

Added to MANIFEST: foo

are written to stderr.  Could these messages be written to stdout =
instead?
I do not consider them to be errors.  The reason I care is that our =
build
system sends emails if there are any build errors (whose definition =
includes
messages sent to stderr).

Regards
Kevin

+ANYTHING+BELOW+WAS+ADDED+AFTER+I+HIT+SEND+

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

[Module::Build] Re: [Module-build-general] Module::Build tests failing on new perl 5.8.1

[Bart P. <ba...@la...>]

On Fri, 10 Oct 2003, Ken Williams wrote:

> On Monday, September 29, 2003, at 02:50  PM, Bart Parliman wrote:
> > I noticed that it's using the literal "$(PERL_INC)/perl.exp" and
> > "$(BASEEXT).exp" strings during the 'ld' rather than
> > interpolating them.
> >
> > At first I thought that I had built perl incorrectly, since these
> > literal values are in the "perl -V" output for lddlflags (see
> > below).  After looking at the vendor's built-in perl on a
> > different machine (5.6.0), it appears that 'lddlflags' has these
> > two values in there as well.
>
> Yeah, I wasn't aware that it was legal to have $(VARIABLE)
> interpolation in these Config.pm strings. =(  Is this typical?  Do
> other platforms do this too?  How do those variables get set?

I have access to Linux and Solaris, but don't see anything
similar there.  I guess this doesn't surprise me for AIX, it has
had a checkered history wrt dynamic loading.

The variables appear to be set in perl's own generated Makefiles.
I'm not sure if it actually makes sense to put them in lddlflags
(i.e. perhaps this is a bug in the way perl builds on AIX).  I
just don't know enough about how these config strings are used.

> Since Module::Build uses the multi-argument form of system(), it
> doesn't run any of the arguments through the shell.  This is much safer
> in terms of security and preventing accidents, so I'm not terribly
> excited about changing it.

I understand your reluctance, though if you can fix this it would
be greatly appreciated.  (Several CPAN modules I need now require
Module::Build.)  If this is a general perl build bug, I'm not
sure who to talk to about it.  If you have ideas, please let me
know.

Thanks,

Bart

Re: [Module::Build] make test failure report (Cygwin)

[Randy W. S. <Ra...@Th...>]

Ken Williams wrote:
> 
> On Saturday, October 11, 2003, at 11:15  AM, Randy W. Sims wrote:
> 
>>     $self->do_system(@shrp, @ld, @lddlflags, '-o', $lib_file,
>>              "$file_base$cf->{obj_ext}", @$objects,
>>                      '-L'.File::Spec->catdir($cf->{archlibexp}, 'CORE'),
>>                      '-lperl', @linker_flags)
> 
> 
> Hi Randy,
> 
> It looks like the -L/foo/perl/CORE and -lperl arguments are the only 
> differences here, right?

Correct. I just copied and pasted the whole function, makeing only the 
changes you pointed out. But this may be a simplification (hack) of what 
needs to be done that just works for the most common case. MakeMaker 
allows for the case of a statically linked perl under cygwin; I don't 
know if anyone actually uses that option. I guess I should probably put 
it in as it's a very minor change to allow for both static and dynamic 
builds.

> I'm curious about something - on my system 
> (darwin), $Config{shrpenv} is defined as 'env 
> LD_RUN_PATH=/sw/lib/perl5/5.6.1/darwin/CORE', and that ends up in the 
> @shrp variable.
> 
> On your cygwin, is $Config{shrpenv} empty, or not having any effect, or 
> what?

It's the same as yours, but for some reason it is not being used. Like I 
said earlier, I'm a little uncertain of the differences in the build 
process under Cygwin as compared to either Windows or *nix. I intend to 
investigate further--maybe I can learn something on the Cygwin mailing 
list...

> I think in general this is a case of Config.pm being a micro-manager.  
> It's not describing what it wants done, it's describing how to do it.  
> That's making our job of interface-writing sort of hard to do.
> 
>  -Ken
> 

Randy.

Re: [Module::Build] make test failure report (Cygwin)

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

On Saturday, October 11, 2003, at 11:15  AM, Randy W. Sims wrote:

> Ok. It took a loooooonnnnnnnnngggggggg time--*TWICE*, but I finally 
> got a working Cygwin & Perl. And Cygwin is very slow on my system, as 
> in it took nearly an hour to run './Build test', so please have 
> patience.
>
> I've hacked the attached file which gets nearly everything working.

Hi Randy, me again.

Here's a simpler version of the subroutine which should also work:

sub link_c {
   my $self = shift;
   my ($cf, $p) = ($self->{config}, $self->{properties}); # For 
convenience
   my $flags = $p->{extra_linker_flags};
   local $p->{extra_linker_flags} =
     ['-L'.File::Spec->catdir($cf->{archlibexp}, 'CORE'),
      '-lperl',
      ref $flags ? @$flags : $self->split_like_shell($flags)];
   return $self->SUPER::link_c(@_);
}

  -Ken

Re: [Module::Build] make test failure report (Cygwin)

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

On Saturday, October 11, 2003, at 11:15  AM, Randy W. Sims wrote:
>     $self->do_system(@shrp, @ld, @lddlflags, '-o', $lib_file,
> 		     "$file_base$cf->{obj_ext}", @$objects,
>                      '-L'.File::Spec->catdir($cf->{archlibexp}, 
> 'CORE'),
>                      '-lperl', @linker_flags)

Hi Randy,

It looks like the -L/foo/perl/CORE and -lperl arguments are the only 
differences here, right?  I'm curious about something - on my system 
(darwin), $Config{shrpenv} is defined as 'env 
LD_RUN_PATH=/sw/lib/perl5/5.6.1/darwin/CORE', and that ends up in the 
@shrp variable.

On your cygwin, is $Config{shrpenv} empty, or not having any effect, or 
what?

I think in general this is a case of Config.pm being a micro-manager.  
It's not describing what it wants done, it's describing how to do it.  
That's making our job of interface-writing sort of hard to do.

  -Ken

Re: [Module::Build] make test failure report (Cygwin)

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

On Saturday, October 11, 2003, at 11:15  AM, Randy W. Sims wrote:

> On 10/10/2003 1:00 AM, Randy W. Sims wrote:
>> On 10/10/2003 12:50 AM, Terrence Brannon wrote:
>>  > ahh, I am using 5.8.0... but you speak on M::B::Platform::Windows 
>> when
>>> an earlier msg indicated that Cygwin used M::B::Platform::Unix, most 
>>> of which defaults to M::B::Base
>> Cygwin is a little of Unix and a little of Windows.
>> I have downloaded Cygwin and am now installing. The download was 
>> quick. The installation is taking a loooooonnnnnnnnngggggggg time.
>> Randy.
>
> Ok. It took a loooooonnnnnnnnngggggggg time--*TWICE*, but I finally 
> got a working Cygwin & Perl. And Cygwin is very slow on my system, as 
> in it took nearly an hour to run './Build test', so please have 
> patience.

Hi Randy,

Thanks doubly much for looking into this, then!  I'll await a final 
patch once you get things worked out with the other cygwin folks.

Incidentally, you can remove that new() subroutine, as it's redundant.

  -Ken

Re: [Module::Build] make test failure report (Cygwin)

[Randy W. S. <Ra...@Th...>]

On 10/10/2003 1:00 AM, Randy W. Sims wrote:
> On 10/10/2003 12:50 AM, Terrence Brannon wrote:
>  > ahh, I am using 5.8.0... but you speak on M::B::Platform::Windows when
> 
>> an earlier msg indicated that Cygwin used M::B::Platform::Unix, most 
>> of which defaults to M::B::Base
> 
> 
> Cygwin is a little of Unix and a little of Windows.
> 
> I have downloaded Cygwin and am now installing. The download was quick. 
> The installation is taking a loooooonnnnnnnnngggggggg time.
> 
> Randy.
> 

Ok. It took a loooooonnnnnnnnngggggggg time--*TWICE*, but I finally got 
a working Cygwin & Perl. And Cygwin is very slow on my system, as in it 
took nearly an hour to run './Build test', so please have patience.

I've hacked the attached file which gets nearly everything working.

NOTE: This is a hack module, the final patch I submit will not be 
anything like this; It is just easier to break it out into a separate 
file to see what changes need to be made.

There is one problem left that has me kinda confused because I didn't 
see any signs of it in the log posted. If some other Cygwin users would 
place the attached file in their 
<module-build-source>/lib/Module/Build/Platform/ directory, perform the 
build incantation, and post the results I would appreciate it as I'm 
suspicious that it might have something to do with my configuration.

The tests that are failing are runthrough.t #22 and xs.t #8. Both are 
tests of PPMMaker. Please let me know if you get a different result.

Thanks,
Randy.

Re: [Module::Build] Extending M::B::Platform::* and issues with "provides"

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

Hi Chris,

On Tuesday, October 7, 2003, at 12:58  PM, Chris Dolan wrote:

> I'm working on a subclass of Module::Build that is intended to package 
> non-Perl material.  I've found M::B to be modular enough that this is 
> feasible without hacking *too* deeply (bravo to Ken and others!).  One 
> aspect of this project includes adding platform-dependent compilation 
> routines.  I accomplished this by simply saying something like:
>
> -------- lib/Module/Build/Foo.pm -----------
> package Module::Build::Foo;
> our @ISA=qw(Module::Build);
> ...
> sub ACTION_foo {
>   my $self = shift;
>   $self->compile_foo($_) for (@{ $self->find_foo_files })
> }
> ...
> package Module::Build::Base;
> sub compile_foo {
>   print "Compiling foo is not supported on this platform\n';
> }
> package Module::Build::Platform::darwin;
> sub compile_foo {
>   my ($self, $file) = @_;
>   $self->do_system("compileFoo", $file);
> }
> 1;
> ---------------------------------------------
>
> This seems to work great with one exception:  META.yml now contains 
> the following lines
>
> ---------------------------------------
> provides:
>   Module::Build::Base:
>     file: lib/Module/Build/Foo.pm
>     version: 0.10
>   Module::Build::Foo:
>     file: lib/Module/Build/Foo.pm
>     version: 0.10
>   Module::Build::Platform::darwin:
>     file: lib/Module/Build/Foo.pm
>     version: 0.10
> ---------------------------------------
>
> I think this is bad thing, yes?  I'm not providing those packages; I'm 
> just hacking them for my particular environment.  Questions:
>
> 1) Is there a better way to add platform-specific extensions to M::B 
> subclasses without hacking ::Base and ::Platform::*?

At this point, unfortunately not.  One project for the future will be 
to move the compilation stuff out to a new standalone package (probably 
called Module::CBuilder or something), and make that package extensible.


> 2) Would explicitly declaring
>    sub Module::Build::Base::compile_foo { ... }
> be better?

For perl it's wouldn't make any difference, but for Module::Build it 
would be better because those subroutines wouldn't show up in your 
'provides' hash anymore, so yeah, I guess that's a good idea.


>
> 3) Is there a good way to tell ACTION_distmeta not to include those 
> hacked packages in the provides hash?

Currently not.  We may end up adding a 'provides_skip' key or something 
where you could tell M::B not to include certain packages or entire 
namespaces in the 'provides' listing.

> P.S. In M::B v0.20, ACTION_distmeta has an out-of-date warning message 
> about Module::Info.  I happened to notice that in my research for the 
> above questions.  I didn't check CVS to see if it's already been > fixed.

Aha, thanks.  I've removed it.

  -Ken

Re: [Module::Build] latest cygwin installation issue

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

On Friday, October 10, 2003, at 10:14  PM, Terrence Brannon wrote:

> Ken Williams wrote:
>
>> Hi Terrence,
>>
>> So, this bug is that it doesn't respect PREFIX, or that it uses '::' 
>> strings in the manpage names?  The latter has been fixed for the next 
>> release.  The former may not be fixed anytime soon, and perhaps 
>> deserves at least a warning (possibly a die()) when encountered.
>>
> just the latter Ken...


Great, thanks.

  -Ken

Re: [Module::Build] Early notes() disappear

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

On Friday, October 10, 2003, at 09:41  PM, Ken Williams wrote:

> On Friday, October 10, 2003, at 06:04  PM, Dave Rolsky wrote:
>
>> If you call notes() before calling create_build_script(), the notes 
>> aren't
>> saved, and you get no errors.  It'd be nice to either save them 
>> somehow,
>> or at least die with an error that this doesn't work, so module 
>> authors
>> know to move the notes() call later.
>
> Oh yeah, they should get written to _build/ during 
> create_build_script().  Will do.

Okay, this is fixed now, with a test.

A workaround is to set additional notes after calling 
create_build_script(), then all of them will be preserved.

  -Ken

Re: [Module::Build] latest cygwin installation issue

[Terrence B. <met...@ur...>]

Ken Williams wrote:

> Hi Terrence,
>
> So, this bug is that it doesn't respect PREFIX, or that it uses '::' 
> strings in the manpage names?  The latter has been fixed for the next 
> release.  The former may not be fixed anytime soon, and perhaps 
> deserves at least a warning (possibly a die()) when encountered.
>
just the latter Ken...

>  -Ken
>
> On Wednesday, October 8, 2003, at 10:29  AM, Terrence Brannon wrote:
>
>> This first issue is trivial, but here it is using Perl-5.8.0.
>>
>>        ~/.cpan/build/Module-Build-0.20 $ ls
>> Build     Changes      MANIFEST  Makefile     README  lib
>> Build.PL  INSTALL.txt  META.yml  Makefile.PL  _build  t
>>        ~/.cpan/build/Module-Build-0.20 $ less README
>>        ~/.cpan/build/Module-Build-0.20 $ perl Makefile.PL PREFIX=$PREFIX
>> perl Build.PL config=prefix=/home/metaperl/install
>> Checking whether your kit is complete...
>> Looks good
>> Deleting Build
>> Removed previous script 'Build'
>> Creating new 'Build' script for 'Module-Build' version '0.20'
>>        ~/.cpan/build/Module-Build-0.20 $ ./Build 2> Build.err > 
>> Build.out
>>        ~/.cpan/build/Module-Build-0.20 $
>>
>> --------------------------------
>>
>> Build.err:
>>
>> Can't open blib/libdoc/Module::Build::Platform::Unix.3pm for writing: 
>> No such file or directory
>> at 
>> /home/metaperl/.cpan/build/Module-Build-0.20/lib/Module/Build/Base.pm 
>> line 1286
>>
>> ----------------------------------
>>
>> Build.out:
>>
>> lib/Module/Build/Platform/darwin.pm -> 
>> blib/lib/Module/Build/Platform/darwin.pm
>> lib/Module/Build/Platform/MacOS.pm -> 
>> blib/lib/Module/Build/Platform/MacOS.pm
>> lib/Module/Build/Compat.pm -> blib/lib/Module/Build/Compat.pm
>> lib/Module/Build/Platform/RiscOS.pm -> 
>> blib/lib/Module/Build/Platform/RiscOS.pm
>> lib/Module/Build/Platform/VOS.pm -> 
>> blib/lib/Module/Build/Platform/VOS.pm
>> lib/Module/Build/Platform/Windows.pm -> 
>> blib/lib/Module/Build/Platform/Windows.pm
>> lib/Module/Build/Platform/Unix.pm -> 
>> blib/lib/Module/Build/Platform/Unix.pm
>> lib/Module/Build/Platform/Amiga.pm -> 
>> blib/lib/Module/Build/Platform/Amiga.pm
>> lib/Module/Build/Base.pm -> blib/lib/Module/Build/Base.pm
>> lib/Module/Build/Platform/EBCDIC.pm -> 
>> blib/lib/Module/Build/Platform/EBCDIC.pm
>> lib/Module/Build/Platform/MPEiX.pm -> 
>> blib/lib/Module/Build/Platform/MPEiX.pm
>> lib/Module/Build/Platform/VMS.pm -> 
>> blib/lib/Module/Build/Platform/VMS.pm
>> lib/Module/Build.pm -> blib/lib/Module/Build.pm
>> lib/Module/Build/PPMMaker.pm -> blib/lib/Module/Build/PPMMaker.pm
>> lib/Module/Build/Cookbook.pm -> blib/lib/Module/Build/Cookbook.pm
>> lib/Module/Build/Platform/Default.pm -> 
>> blib/lib/Module/Build/Platform/Default.pm
>> Manifying blib/lib/Module/Build/Platform/Unix.pm -> 
>> blib/libdoc/Module::Build::Platform::Unix.3pm
>>
>>
>>
>>
>>
>>
>

Re: [Module::Build] Early notes() disappear

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

On Friday, October 10, 2003, at 06:04  PM, Dave Rolsky wrote:

> If you call notes() before calling create_build_script(), the notes 
> aren't
> saved, and you get no errors.  It'd be nice to either save them 
> somehow,
> or at least die with an error that this doesn't work, so module authors
> know to move the notes() call later.

Oh yeah, they should get written to _build/ during 
create_build_script().  Will do.

  -Ken

Re: [Module::Build] [PATCH] 5.00503 back-compat

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

Thanks, applied.

  -Ken

On Friday, October 10, 2003, at 05:53  PM, Dave Rolsky wrote:

> See below sig.
>
>
> -dave
>
> /*=======================
> House Absolute Consulting
> www.houseabsolute.com
> =======================*/
>
> --- manifypods.t.~1.5.~	2003-08-19 08:33:06.000000000 -0500
> +++ manifypods.t	2003-10-10 17:52:27.000000000 -0500
> @@ -1,7 +1,6 @@
> -#!/usr/bin/perl
> +#!/usr/bin/perl -w
>
>  use strict;
> -use warnings;
>
>  use File::Spec;
>  use File::Path qw( rmtree );
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

[Module::Build] Early notes() disappear

[Dave R. <au...@ur...>]

If you call notes() before calling create_build_script(), the notes aren't
saved, and you get no errors.  It'd be nice to either save them somehow,
or at least die with an error that this doesn't work, so module authors
know to move the notes() call later.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/