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

Re: [Module-build-general] More version info in META.yml

[<and...@an...>]

>>>>> On Sun, 30 Mar 2003 15:20:03 -0600, Ken Williams <ke...@ma...> said:

  > I think MakeMaker is doing an easier and smaller task - just figuring
  > out the version of the "chief" module in the distribution.  So it only
  > looks for the first line in the chief .pm file that looks like it
  > contains a $VERSION.

Right, it finds only one VERSION per file, but does so for any .pm
file you're interested in.

  > By contrast, to create the index of all modules & versions in the
  > distribution, we have to find all 'package' declarations (which
  > Module::Info does a nice job at), and all $VERSIONs within those
  > packages (which it doesn't do yet).  Correct me if I'm wrong in my
  > understanding, of course.

Indeed I correct you: PAUSE took the middle way and in all the years
only about 3 people complained: find N package statements in all *.pm
files but only one VERSION statement per file. You get an M:N matrix
of package name and version numbers, take the max of available version
numbers per package. Very trivial and effective.

Note that this was defined to be the correct way, even if thinge like

  package Foo::Bar;
  $VERSION=42;
  package Foo::Bar::Baz;
  $VERSION=123;

could surprise somebody who had the weird idea to write such a version
hell. We ruled out quite a lot of weird ideas that way.

So if you replace PAUSE's heavy weaponry in
PAUSE::pmfile::parse_version with plain MakeMaker->parse_version,
you're done.

-- 
andreas

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Sunday, March 30, 2003, at 05:49  PM, Richard Clamp wrote:

> On Sun, Mar 30, 2003 at 09:44:59AM -0600, Ken Williams wrote:
>> If ExtUtils::ParseXS doesn't work on 5.005, then you probably 
>> shouldn't
>> have installed it in a location shared with 5.005.  But I'm sort of
>> glad you did, because probably other people will too, and we shouldn't
>> be loading a module that doesn't work.
>>
>> How about this patch instead of yours:
>
> Forgive me for coming late to the game, but surely the simplest fix
> goes a bit like:
>
>   package ExtUtils::ParseXS;
> + use 5.006; # /??{}/ won't mean the right thing unless we're this new
>
> And then up the value of the suggestion on EU::PXS in Module::Build's
> Build.PL to a version that incorporates that change.

That's just crazy enough to work!

It's about the same as my previous fix, except that it places the 
burden of upgrading in ExtUtils::ParseXS instead of Module::Build, 
which is good.  Thanks for the suggestion.

  -Ken

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

[Richard C. <ric...@un...>]

On Sun, Mar 30, 2003 at 09:44:59AM -0600, Ken Williams wrote:
> If ExtUtils::ParseXS doesn't work on 5.005, then you probably shouldn't 
> have installed it in a location shared with 5.005.  But I'm sort of 
> glad you did, because probably other people will too, and we shouldn't 
> be loading a module that doesn't work.
> 
> How about this patch instead of yours:

Forgive me for coming late to the game, but surely the simplest fix
goes a bit like:
 
  package ExtUtils::ParseXS;
+ use 5.006; # /??{}/ won't mean the right thing unless we're this new

And then up the value of the suggestion on EU::PXS in Module::Build's
Build.PL to a version that incorporates that change.

-- 
Richard Clamp <ric...@un...>

Re: [Module-build-general] PATCH - package_versions() for Module::Info

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

On Sunday, March 30, 2003, at 05:20  PM, Ken Williams wrote:
>
> Here's a patch, attached, that adds a package_version() method to 
> Module::Info.  It has the following documentation:
>
> =item B<package_versions>
>
>   my $versions = $module->package_versions;
>   my %versions = $module->package_versions;

After a little conversing with Schwern, I think we agreed it would 
probably be better to just have the list version, not scalar and list, 
since the rest of the interface uses lists everywhere.

  -Ken

[Module-build-general] PATCH - package_versions() for Module::Info

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

Hi Mattia,

Here's a patch, attached, that adds a package_version() method to 
Module::Info.  It has the following documentation:

=item B<package_versions>

   my $versions = $module->package_versions;
   my %versions = $module->package_versions;

Returns a hash (or a reference to a hash in scalar context) whose keys
are the packages contained in the module (these are the same as what's
returned by C<packages_inside()>), and whose values are the versions
of those packages.

=cut

I'd like to use this functionality for Module::Build, where we want to 
generate a listing of all the packages and versions contained in all 
.pm files in the distribution.  This patch could probably be 
implemented in some more efficient way, but it does seem to work.

Let me know if you have any questions, or if/when you incorporate it.  
Thanks.

  -Ken

Re: [Module-build-general] More version info in META.yml

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

On Sunday, March 30, 2003, at 03:03  PM, Andreas J. Koenig wrote:
>> Since this is a pretty hard and dangerous task,
>
> See, it's not dangerous per se, it's only dangerous on PAUSE. The
> META.yml file will only be generated on the developer's own box, so
> there's no need to protect from that sort of malicious code.

Very good point.

>> maybe we ought to really get it right and have it in a module.
>> Could we try to use Module::Info for this? Even if Module::Info
>> doesn't work correctly, maybe the best thing to do would be to fix
>> Module::Info.
>
> I believe that MakeMaker's parse_version does a pretty good job and
> Module::Info claims to follow MakeMaker's lead.

I think MakeMaker is doing an easier and smaller task - just figuring 
out the version of the "chief" module in the distribution.  So it only 
looks for the first line in the chief .pm file that looks like it 
contains a $VERSION.

By contrast, to create the index of all modules & versions in the 
distribution, we have to find all 'package' declarations (which 
Module::Info does a nice job at), and all $VERSIONs within those 
packages (which it doesn't do yet).  Correct me if I'm wrong in my 
understanding, of course.

I'm going to look at Module::Info and try to add a package_version() 
method or something to it if it's not too terribly hard.

  -Ken

[Module-build-general] [PATCH] Getting Module::Build working on VMS

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

The attached patch gets Module::Build working on VMS.  Its dead simple and
resolves three issues:

- You can't safely put switches after $Config{startperl}
- The comfortable VMS equivalent to ./Build is @Build which means Build.PL
  should generate Build.com
- VMS likes to drop cases unless specially quoted.  "@Build test" will
  pass "TEST" rather than "test".  So we make argv->action translation
  case-insensitive as opposed to requiring special command line quoting.

And that's it.  All tests pass.  One fix, two overrides.  After a hard week 
of fighting with MakeMaker its always a pleasure to glide through 
Module::Build.

I encourage vmsperl module authors to RUN, do not walk, to their editors 
and convert their modules from MakeMaker to Module::Build.


-- 
And if you don't know Which To Do
Of all the things in front of you,
Then what you'll have when you are through
Is just a mess without a clue.
Of all the best that can come true
If you know What and Which and Who.

Re: [Module-build-general] More version info in META.yml

[<and...@an...>]

>>>>> On Sat, 29 Mar 2003 23:44:52 -0600, Ken Williams <ke...@ma...> said:

  > Am I right that something like the following is what we're aiming for?

  > provides:
  >    Foo::Bar:
  >      file: Bar.pm
  >      version: 0.12
  >    Foo::Bar::Baz:
  >      file: lib/Foo/Bar/Baz.pm
  >      version: ~

Yes, I think so.

 >> 
 >> Problem is, it is not a tiny program but 2000+ lines long and probably
 >> not easy to follow and dissect. What do you suggest?

  > So, I started hacking my way through that code, slurping the relevant
  > bits into Module::Build::Base.  It was going pretty well.  But then I
  > got to the part where we try to figure out the version of each
  > package, and I nearly fainted.

:)

  > Since this is a pretty hard and dangerous task,

See, it's not dangerous per se, it's only dangerous on PAUSE. The
META.yml file will only be generated on the developer's own box, so
there's no need to protect from that sort of malicious code.

  > maybe we ought to really get it right and have it in a module.
  > Could we try to use Module::Info for this? Even if Module::Info
  > doesn't work correctly, maybe the best thing to do would be to fix
  > Module::Info.

I believe that MakeMaker's parse_version does a pretty good job and
Module::Info claims to follow MakeMaker's lead.

  > I'd just hate to spend a lot of time on this and have the code buried
  > in Module::Build, when this is exactly the kind of thing Module::Info
  > aims to do correctly.

I'm agnostic on this question.


-- 
andreas

Re: [Module-build-general] [OT] Re: Richard Cramp

[Uri G. <ur...@st...>]

>>>>> "DR" == Dave Rolsky <au...@ur...> writes:

  DR> On Sun, 30 Mar 2003, Ken Williams wrote:
  >> Oops - sorry!  Richard Cramp is actually the father of someone I knew
  >> in high school.

  DR> Ugh, what an awful name, when the first name nickname is used!

and with that change is clamp any better? 

<me ducks and runs fast>

apologies to the poster with that name

:)

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Sun, 30 Mar 2003, Ken Williams wrote:

> Since when are we in the practice of skipping a test when we discover
> it doesn't work! =)  It needs to be fixed, not skipped.  If it remains
> broken, then M::B is broken on that platform for compiling XS modules.

I think I was just confused about the M::B internals.

> If ExtUtils::ParseXS doesn't work on 5.005, then you probably shouldn't
> have installed it in a location shared with 5.005.  But I'm sort of
> glad you did, because probably other people will too, and we shouldn't
> be loading a module that doesn't work.

Exactly.  Someone might install it into a shared location with 5.6.1, and
then try it with 5.00503 and kaboom!

> How about this patch instead of yours:

Looks good to me.


-dave

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

[Module-build-general] [OT] Re: Richard Cramp

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

On Sun, 30 Mar 2003, Ken Williams wrote:

> Oops - sorry!  Richard Cramp is actually the father of someone I knew
> in high school.

Ugh, what an awful name, when the first name nickname is used!


-dave

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

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Sunday, March 30, 2003, at 12:03  AM, Dave Rolsky wrote:

> On Sat, 29 Mar 2003, Ken Williams wrote:
>
>> That test should pass (not be skipped) even if EU::ParseXS isn't
>> around.  You're seeing it fail?  This is t/xs.t in Module::Build, 
>> right?
>
> I was a little confused.  If EU::ParseXS _is_ installed and you try to
> load it with Perl 5.00503, it does actually load (I thought it was
> dying), but it doesn't work right.  So here's a test patch that skips
> the tests unconditionally if you're using a Perl before 5.6.0.

Since when are we in the practice of skipping a test when we discover 
it doesn't work! =)  It needs to be fixed, not skipped.  If it remains 
broken, then M::B is broken on that platform for compiling XS modules.

If ExtUtils::ParseXS doesn't work on 5.005, then you probably shouldn't 
have installed it in a location shared with 5.005.  But I'm sort of 
glad you did, because probably other people will too, and we shouldn't 
be loading a module that doesn't work.

How about this patch instead of yours:

  -Ken

Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.80
diff -u -r1.80 Base.pm
--- lib/Module/Build/Base.pm	30 Mar 2003 06:06:16 -0000	1.80
+++ lib/Module/Build/Base.pm	30 Mar 2003 15:42:16 -0000
@@ -1184,7 +1184,8 @@

    print "$file -> $file_base.c\n";

-  if (eval {require ExtUtils::ParseXS; 1}) {
+  # ExtUtils::ParseXS requires 5.6, but it's in @INC sometimes anyway.
+  if ($] >= 5.006 and eval {require ExtUtils::ParseXS; 1}) {

      ExtUtils::ParseXS::process_file(
  				    filename => $file,

===================================================================

Re: [Module-build-general] ANNOUNCE: Module::Build 0.17 -> CPAN

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

On Sunday, March 30, 2003, at 05:05  AM, Richard Clamp wrote:

> On Sat, Mar 29, 2003 at 06:15:26PM -0600, Ken Williams wrote:
>>  - Now works under perl 5.005_03.  [Richard Cramp]
>
> --- Changes     30 Mar 2003 04:29:53 -0000      1.62
> +++ Changes     30 Mar 2003 11:04:44 -0000
> @@ -11,7 +11,7 @@ Revision history for Perl extension Modu
>
>  0.17  Sat Mar 29 18:06:01 CST 2003
>
> - - Now works under perl 5.005_03.  [Richard Cramp]
> + - Now works under perl 5.005_03.  [Richard Clamp]
>

Oops - sorry!  Richard Cramp is actually the father of someone I knew 
in high school.

  -Ken

Re: [Module-build-general] ANNOUNCE: Module::Build 0.17 -> CPAN

[Richard C. <ric...@un...>]

On Sat, Mar 29, 2003 at 06:15:26PM -0600, Ken Williams wrote:
>  - Now works under perl 5.005_03.  [Richard Cramp]

--- Changes     30 Mar 2003 04:29:53 -0000      1.62
+++ Changes     30 Mar 2003 11:04:44 -0000
@@ -11,7 +11,7 @@ Revision history for Perl extension Modu

 0.17  Sat Mar 29 18:06:01 CST 2003

- - Now works under perl 5.005_03.  [Richard Cramp]
+ - Now works under perl 5.005_03.  [Richard Clamp]

  - When building blib/ , .PL files are now processed before doing
    anything else.  This means .PL files can be used in any of the


-- 
Richard Clamp <ric...@un...>

[Module-build-general] Testing

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

Testing.  SourceForge and my MTA are fighting again.

-- 
You see, in this world there's two kinds of people.  Those with loaded
guns, and those who dig.  Dig.
                -- Blondie, "The Good, The Bad And The Ugly"

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Sat, 29 Mar 2003, Ken Williams wrote:

> That test should pass (not be skipped) even if EU::ParseXS isn't
> around.  You're seeing it fail?  This is t/xs.t in Module::Build, right?

I was a little confused.  If EU::ParseXS _is_ installed and you try to
load it with Perl 5.00503, it does actually load (I thought it was
dying), but it doesn't work right.  So here's a test patch that skips
the tests unconditionally if you're using a Perl before 5.6.0.


Index: xs.t
===================================================================
RCS file: /cvsroot/module-build/Module-Build/t/xs.t,v
retrieving revision 1.5
diff -u -r1.5 xs.t
--- xs.t        24 Feb 2003 18:23:20 -0000      1.5
+++ xs.t        30 Mar 2003 06:02:16 -0000
@@ -3,6 +3,8 @@
 use strict;
 use Test;

+print("1..0 # Skipped: cannot use ExtUtils::ParseXS with Perl $]\n"), exit(0)
+  if $] < 5.006;
 print("1..0 # Skipped: no compiler found\n"), exit(0) unless have_compiler();
 plan tests => 7;

Re: [Module-build-general] More version info in META.yml

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

On Monday, March 10, 2003, at 12:11  PM, Andreas J. Koenig wrote:

>>>>>> On Sat, 8 Mar 2003 13:53:25 -0800, sc...@po... (Michael G. 
>>>>>> Schwern) said:
>
>> On Sat, Mar 08, 2003 at 01:43:37PM -0600, Ken Williams wrote:
>>>>>   2) What about .pm files that contain multiple packages?  Should
>>>>> those
>>>>> packages be included too, like the PAUSE namespace indexer does?
>>>>
>>>> Is the PAUSE indexer that smart?  I don't think it is.
>>>
>>> Yup, it is:
>
>> Maybe we should borrow the code then?
>
> In case you don't know, PAUSE code is available in a subversion
> repository and in daily snapshots. Daily dumps of the subversion repo
> are also there. The dumps and snapshots are at
>
>     ftp://pause.perl.org/pub/PAUSE/PAUSE-code/
>
> The repository itself is
>
>     http://pause.perl.org:5459/svn/pause/trunk
> or
>     https://pause.perl.org:5460/svn/pause/trunk
>
> The http adresses can also be browsed.
>
> The indexer is in cron/mldistwatch.

Thanks.

Am I right that something like the following is what we're aiming for?

provides:
   Foo::Bar:
     file: Bar.pm
     version: 0.12
   Foo::Bar::Baz:
     file: lib/Foo/Bar/Baz.pm
     version: ~

(the '~' is YAML for undef)

>
> Problem is, it is not a tiny program but 2000+ lines long and probably
> not easy to follow and dissect. What do you suggest?


So, I started hacking my way through that code, slurping the relevant 
bits into Module::Build::Base.  It was going pretty well.  But then I 
got to the part where we try to figure out the version of each package, 
and I nearly fainted.

Since this is a pretty hard and dangerous task, maybe we ought to 
really get it right and have it in a module.  Could we try to use 
Module::Info for this?  Even if Module::Info doesn't work correctly, 
maybe the best thing to do would be to fix Module::Info.

I'd just hate to spend a lot of time on this and have the code buried 
in Module::Build, when this is exactly the kind of thing Module::Info 
aims to do correctly.

  -Ken

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Saturday, March 29, 2003, at 11:13  PM, Dave Rolsky wrote:

> On Sat, 29 Mar 2003, Ken Williams wrote:
>
>> It would be great, of course - but a simpler solution might be to just
>> fix the warning buzzers so that optional modules don't look like
>> required modules to the user.  M::B should work fine without
>> EU::ParseXS, using whatever xsubpp is on the machine.
>>
>> In the future we might want to really depend on EU::ParseXS, but so 
>> far
>> it'll do fine with either.
>
> In that case, how about tweaking the EU::ParseXS test to make sure that
> the module actually loads, and skipping tests if it doesn't.  If people
> are sharing pure Perl modules between multiple Perl installations, they
> might be put off from installing Module::Build with 5.00503 if there 
> are
> test failures.
>

That test should pass (not be skipped) even if EU::ParseXS isn't 
around.  You're seeing it fail?  This is t/xs.t in Module::Build, right?

  -Ken

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Sat, 29 Mar 2003, Ken Williams wrote:

> It would be great, of course - but a simpler solution might be to just
> fix the warning buzzers so that optional modules don't look like
> required modules to the user.  M::B should work fine without
> EU::ParseXS, using whatever xsubpp is on the machine.
>
> In the future we might want to really depend on EU::ParseXS, but so far
> it'll do fine with either.

In that case, how about tweaking the EU::ParseXS test to make sure that
the module actually loads, and skipping tests if it doesn't.  If people
are sharing pure Perl modules between multiple Perl installations, they
might be put off from installing Module::Build with 5.00503 if there are
test failures.


-dave

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

Re: [Module-build-general] ExtUtils::ParseXS & 5.00503

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

On Saturday, March 29, 2003, at 03:35  PM, Dave Rolsky wrote:

> Module::Build passes most of its tests with 5.00503 now, but
> ExtUtils::ParseXS does not.  There are two things in EU::ParseXS that 
> need
> fixing.  One if the "open my $fh" idiom, which is simple enough to fix.
>
> But it also uses the "(??{$foo})" regex feature, which is not present 
> in
> 5.00503.  I don't think replacing this would be simple, to say the 
> least
> ;)  I think the easiest way to do this would be to use Text::Balanced, 
> but
> this introduces another dependency, and would require a fair bit of 
> code
> surgery.  I could take a shot if you want, Ken.

It would be great, of course - but a simpler solution might be to just 
fix the warning buzzers so that optional modules don't look like 
required modules to the user.  M::B should work fine without 
EU::ParseXS, using whatever xsubpp is on the machine.

In the future we might want to really depend on EU::ParseXS, but so far 
it'll do fine with either.

  -Ken

[Module-build-general] ANNOUNCE: Module::Build 0.17 -> CPAN

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

The uploaded file

     Module-Build-0.17.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.17.tar.gz
   size: 58502 bytes
    md5: dcf6c4f700217388f15280e912ebf6b7

There are still a lot of things in the queue to do, but I wanted to get 
a release out since there's been a lot of progress too.

Note that I'm trying to start using http://rt.cpan.org/ for bug & 
feature tracking.

Changes since 0.16:

0.17  Sat Mar 29 18:06:01 CST 2003

  - Now works under perl 5.005_03.  [Richard Cramp]

  - When building blib/ , .PL files are now processed before doing
    anything else.  This means .PL files can be used in any of the
    other contexts.

  - The locating and processing of .pm, .pod, .xs, .PL files and script
    files are now isolated into their own methods.  This is aimed
    toward providing a stable interface for this stuff, so they can be
    overridden, parameterized, etc.  They're not quite stable yet,
    though.

  - The internal lib_to_blib() method has gone away, because processing
    is now done by smaller specialized methods.  This method had some
    duplicate assumptions about filenames that it's nice to get rid of.

  - .PL files are no longer automatically processed in the c_source
    directory, they must be specified manually in a 'PL_files'
    parameter.

  - Mention in the docs that it's useful to do "PL_FILES => {}" in a
    Makefile.PL if you're using both a Makefile.PL and a
    Build.PL. [Dom]

  - Add several options to the 'license' field, so that we're in better
    sync with PAUSE and CPAN options. [Andreas Koenig]

  - Created a find_perl_interpreter() method that tries to locate the
    currently executing perl interpreter.  Following a suggestion from
    Nicholas Clark <ni...@cc...> for Inline, we prefer an absolute
    path in $^X, then an existent path in $Config{perlpath}, then
    whatever's in $^X.

  - Use the aforementioned perl to run scripts in run_perl_script().
    This fixes the spurious warning "WARNING: Configuration was
    initially created with 'foo', but we are now using 'bar'" that
    appeared a lot in version 0.16.

  -Ken

[Module-build-general] ExtUtils::ParseXS & 5.00503

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

Module::Build passes most of its tests with 5.00503 now, but
ExtUtils::ParseXS does not.  There are two things in EU::ParseXS that need
fixing.  One if the "open my $fh" idiom, which is simple enough to fix.

But it also uses the "(??{$foo})" regex feature, which is not present in
5.00503.  I don't think replacing this would be simple, to say the least
;)  I think the easiest way to do this would be to use Text::Balanced, but
this introduces another dependency, and would require a fair bit of code
surgery.  I could take a shot if you want, Ken.


-dave

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

Re: [Module-build-general] [patch] backport to 5.005_03

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

On Saturday, March 29, 2003, at 06:55  AM, Richard Clamp wrote:

> This was shockingly painfree, and really just amounts to:
>
>  s/open my $fh, .../my $fh = IO::File->new(...)/g
>
> I hope it's useful

Yeah, looks great.  I don't have a 5.005 to test it against myself 
(though I probably should make one one of these days), but other people 
have wanted this too.  Thanks for the patch.

>
> ps. When are we likely to see a new release?  The EXE_FILES shebang
> rewrite fix you did the other week is very close to my heart.

Yeah, and that spurious warning about mismatched perl executables is 
pretty annoying too.  I should do this soon, though there are plenty of 
tasks that won't make it into the next release if I do it right away.

Either way, I think I can do a release this weekend, either an 
ambitious one or a lazy one.

  -Ken

[Module-build-general] only::install::install

[Greg M. <cid...@ma...>]

Is line 797 in Module/Build/Base.pm's ACTION_versioninstall
subroutine OK? I get this error message:

greg@7106 ~/.cpan/build/PerlBean-0.7
$ ./Build versioninstall
WARNING: './Build' script was created with perl, but
we are now using /usr/bin/perl
Too late to run INIT block at /usr/lib/perl5/site_perl/5.8.0/only.pm line 110.
Undefined subroutine &only::install::install called at /usr/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm line 797, <IN> line 19.

Accroding to perlmod, qualifying is for variables and filehandles. When I add

use only::install at teh top of the file, it works (under some circumstances).

-- 
Greg Matheson
Taiwan

[Module-build-general] [patch] backport to 5.005_03

[Richard C. <ric...@un...>]

This was shockingly painfree, and really just amounts to:

 s/open my $fh, .../my $fh = IO::File->new(...)/g

I hope it's useful

ps. When are we likely to see a new release?  The EXE_FILES shebang
rewrite fix you did the other week is very close to my heart.

-- 
Richard Clamp <ric...@un...>