Randy W. Sims | 1 Jul 13:31 2005

Re: [Module::Build] [Fwd: [cpan #13464] AutoReply: 'provides' field in META.yml is not smart about reopened packages]

Randy W. Sims wrote:
> The 'provides' field in META.yml does not allow for cases where a 
> package appears in more than one file,  simply displaying the last file 
> encountered in its scan. Refer to thread "provides field plugged into 
> PAUSE" 
> <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/2149>.

Just checked in an initial attempt at fixing this. Any package name that 
corresponds to the file name is considered the primary (or $prime) 
package. Others are alternate packages. If a package is declared more 
than once, either only one $VERSION can be provided or all $VERSIONs 
must agree.

More tests, testing, and general cleaning up to come.

Randy.

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
David Golden | 5 Jul 01:02 2005
Picon

[Module::Build] Patch: non-case-sensitive directory checks in Build on win32

I discovered an interesting bug on Windows -- depending on where you run 
"perl Build.PL" from, you can wind up with different case in the 
shortened (8.3) path that is stored and later checked on subsequent runs 
from Build, even when the runs are from the same current directory.  
(Very annoying when I run "perl Build.PL" from a shell window, and then 
later try "Build test" from vim and it carps at me.)  This short patch 
uppercases all the short directories for this kind of check on the 
windows platform .  The patch is against 0.27_01, but should generalize, 
I believe.

Regards,
David Golden

Index: lib/Module/Build/Base.pm
===================================================================
--- lib/Module/Build/Base.pm    (revision 175)
+++ lib/Module/Build/Base.pm    (working copy)
 <at>  <at>  -942,7 +942,7  <at>  <at> 
   my $build_package = $self->build_class;

   my %q = map {$_, $self->$_()} qw(config_dir base_dir);
-  $q{base_dir} = Win32::GetShortPathName($q{base_dir}) if $^O eq 'MSWin32';
+  $q{base_dir} = uc Win32::GetShortPathName($q{base_dir}) if $^O eq 'MSWin32';

   my  <at> myINC = $self->_added_to_INC;
   for ( <at> myINC, values %q) {
 <at>  <at>  -963,7 +963,7  <at>  <at> 
 BEGIN {
(Continue reading)

Petya Kohts | 6 Jul 23:44 2005
Picon

[Module::Build] Module::Build with some old Test::Harness

Hello, all.

Recently I was trying to install Module::Build 0.2611.

During "make test" phase I was getting an error
in t/compat.t, test 55, the one at the line 132:
  ok $output, qr/# test\.+ok\s+# All/, 'Should be non-verbose';

I've managed to find out that for some reason the output
on the line 129 was producing "Ok" messages WITH TIMINGS:
$output = stdout_of( sub { $ran_ok = $build->do_system( <at> make, 'test', 'TEST_VERBOSE=0') } );

Those timings confused the regexp on the line 132,
which doesn't expect anything except space or \n after "ok".

While experimenting I've tried to change TEST_VERBOSE=0 to TEST_VERBOSE=1,
which, surpise, produced the output WITHOUT timings, regexp worked
and test at the line 132 was successful.

That is: TEST_VERBOSE behavior was inverted.

Next I've installed the latest Test::Harness 2.52 module from CPAN
and the error was gone. So I suppose the root of the problem was
some old version of Test::Harness.

Unfortunately I can't tell the version of Test::Harness I was using
before 2.52 because I was not able to find the old version after
installing 2.52. I'm not quite used to perl yet.

Anyway, I hope this helps somehow.
(Continue reading)

Ken Williams | 7 Jul 02:04 2005

Re: [Module::Build] Module::Build with some old Test::Harness

Hi Petya,

Thanks for the report.  This was actually already fixed in CVS, but not 
released yet.  It'll be part of the next release.

  -Ken

On Jul 6, 2005, at 4:44 PM, Petya Kohts wrote:

> Hello, all.
>
> Recently I was trying to install Module::Build 0.2611.
>
> During "make test" phase I was getting an error
> in t/compat.t, test 55, the one at the line 132:
>   ok $output, qr/# test\.+ok\s+# All/, 'Should be non-verbose';
>
> I've managed to find out that for some reason the output
> on the line 129 was producing "Ok" messages WITH TIMINGS:
> $output = stdout_of( sub { $ran_ok = $build->do_system( <at> make, 'test', 
> 'TEST_VERBOSE=0') } );
>
> Those timings confused the regexp on the line 132,
> which doesn't expect anything except space or \n after "ok".
>
> While experimenting I've tried to change TEST_VERBOSE=0 to 
> TEST_VERBOSE=1,
> which, surpise, produced the output WITHOUT timings, regexp worked
> and test at the line 132 was successful.
>
(Continue reading)

Randy W. Sims | 7 Jul 02:15 2005

Re: [Module::Build] Module::Build with some old Test::Harness

Petya Kohts wrote:
> Hello, all.
> 
> Recently I was trying to install Module::Build 0.2611.
> 
> During "make test" phase I was getting an error
> in t/compat.t, test 55, the one at the line 132:
>   ok $output, qr/# test\.+ok\s+# All/, 'Should be non-verbose';
> 
> I've managed to find out that for some reason the output
> on the line 129 was producing "Ok" messages WITH TIMINGS:
> $output = stdout_of( sub { $ran_ok = $build->do_system( <at> make, 'test', 'TEST_VERBOSE=0') } );
> 
> Those timings confused the regexp on the line 132,
> which doesn't expect anything except space or \n after "ok".
> 
> While experimenting I've tried to change TEST_VERBOSE=0 to TEST_VERBOSE=1,
> which, surpise, produced the output WITHOUT timings, regexp worked
> and test at the line 132 was successful.
> 
> That is: TEST_VERBOSE behavior was inverted.
> 
> 
> Next I've installed the latest Test::Harness 2.52 module from CPAN
> and the error was gone. So I suppose the root of the problem was
> some old version of Test::Harness.
> 
> Unfortunately I can't tell the version of Test::Harness I was using
> before 2.52 because I was not able to find the old version after
> installing 2.52. I'm not quite used to perl yet.
(Continue reading)

Ken Williams | 7 Jul 03:16 2005

Re: [Module::Build] Re: CPANPLUS fail reports using M::B

Me again.  I can't resolve this issue properly.  I still believe the 
proper fix lies in CPANPLUS itself, see below for why.

On Jun 18, 2005, at 12:13 PM, Jos I. Boumans wrote:

>
> On Jun 18, 2005, at 6:02 PM, Ken Williams wrote:
>
>> I explained why I thought your patch wasn't correct, and explained 
>> why I thought the proper fix should be in CPANPLUS, not M::B or 
>> Test::Harness.
>
> Actually, you explained *that* you thought it should be in CPANPLUS, 
> not why:
>
> 	I'm not sure it's a great idea to have $ <at>  contain the entire failure 
> output.  In
> 	general we try to
> 	have $ <at>  contain just the text of an "exception" message.  Other 
> "informational"
> 	messages go to STDOUT or STDERR.

The next paragraph was the "why".

> To be clear; *any* way of getting this output from the M::B API is 
> acceptable. Wether's it's as $mb->last_error,
> M::B->error_as_string, or in $ <at>  -- dont care, as long as i can get to 
> it.

I was about ready to take a stab at this, but: using any of the 
(Continue reading)

John Peacock | 7 Jul 12:27 2005

[Module::Build] Module::Info and version.pm

Attached, please find a small patch to enable Module::Info to return a version 
object instead of a numeric version.  I didn't update the POD yet; I want to get 
some feedback from folks.  It may be time to revisit the discussion of using 
Module::Info within Module::Build to spelunk in files looking for stuff.

There are some reasons why this is going to suddenly be important to support. 
Damian's "Perl Best Practices" from O'Reilly is expected out this month and one 
of the things he is advocating is the use of structured version objects, i.e. 
the version.pm module.  He already released Module::Starter::PBP (back in May) 
which generates a module with a line like this:

     use version; $VERSION = qv('0.0.1');

I've already been in contact with Andreas about what needs to happen to PAUSE to 
support that mode.  I'm also working towards releasing a 
Module::Starter::XSimple module (produce XS skeleton files for new module 
development) which will itself use a version string like the above (available on 
request to anyone intersted; I'm not ready to release to CPAN).

Thoughts???

John

--

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
(Continue reading)

Ron Savage | 7 Jul 13:05 2005
Picon

Re: [Module::Build] Module::Info and version.pm

On Thu, 07 Jul 2005 06:27:40 -0400, John Peacock wrote:

Hi John

> use version; $VERSION = qv('0.0.1');

What will module /users/ have to install before they are ready to install 
modules created by authors who are using such objects?

In other words, what do module authors have to wait for before it is reasonable 
and practical for us to ship modules using such objects?
--

-- 
Cheers
Ron Savage, ron <at> savage.net.au on 7/07/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
John Peacock | 7 Jul 13:16 2005

Re: [Module::Build] Module::Info and version.pm

Ron Savage wrote:
> What will module /users/ have to install before they are ready to install 
> modules created by authors who are using such objects?

Just the version.pm distro, which will happen automatically using CPAN or 
CPANPLUS (see below).

> 
> In other words, what do module authors have to wait for before it is reasonable 
> and practical for us to ship modules using such objects?

The only thing that is required of the module author is to add a dependency for 
version.pm itself.  Module::Build works now (mostly) with $VERSION declarations 
like that; once M::B is using Module::Info and able to use version objects 
directly, there are a number of things that M::B can do better.

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

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
(Continue reading)

Mattia Barbon | 7 Jul 22:41 2005
Picon

Re: [Module::Build] Module::Info and version.pm

On Thu, 07 Jul 2005 06:27:40 -0400 John Peacock <jpeacock <at> rowman.com> wrote:

  Hello,

> Attached, please find a small patch to enable Module::Info to return a version 
> object instead of a numeric version.  I didn't update the POD yet; I want to get 
> some feedback from folks.

  Thanks!

  I looked at the patch: looks good, except that version.pm supports Perl 5.005,
while Module::Info goes back to 5.004. I will look into using version.pm only
if available.

> It may be time to revisit the discussion of using 
> Module::Info within Module::Build to spelunk in files looking for stuff.

  I will help as much as I can if the list chooses to go this way.

Regards
Mattia

> === lib/Module/Info.pm
> ==================================================================
> --- lib/Module/Info.pm  (revision 3)
> +++ lib/Module/Info.pm  (local)
>  <at>  <at>  -4,10 +4,11  <at>  <at> 
>  use Carp;
>  use File::Spec;
>  use Config;
(Continue reading)


Gmane