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

[Module-build-general] archives

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

There's no archives for this list.  Ken, can you turn on the SF archive
feature?  Of course, the SF archives suck, so it'd be nice to be added to
nntp.x.perl and archive.develooper.com (the reason I'm cc'ing Ask ;)


-dave

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

[Module-build-general] conflicts and test_requires

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

There probably needs to be a command line flag to ignore conflicts, or
else a module that specifies conflicts could be entirely uninstallable.

Also, was there discussion about a "test_requires" option, so that tests
could be skipped if certain modules weren't installed?  Seems like a
useful option.


-dave

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

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

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

The uploaded file

     Module-Build-0.15.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.15.tar.gz
   size: 42232 bytes
    md5: abed2de09011e78aa5f5051ba3f9f869

Changes since 0.14:

  - In link_c(), extra object files were mistakenly being treated as
    output files, not input files, in the up-to-date check.  Fixed.

  - In up_to_date(), don't make an unnecessary copy of the file lists
    when they're specified as array references.

  - Split off the C compilation phase into its own method,
    compile_support_files(), for easier subclassing.

  - Start a stub of a 'manifypods' action.

  - Compiler optimizations weren't being included in C compilation
    statements.  Fixed.

  - The 'extra_linker_flags' parameter wasn't being honored.  Fixed.

  - The 'ccflags' Config.pm entry wasn't being properly split into
    separate arguments.  Fixed.


  -Ken

[Module-build-general] Re: [Cpanplus-devel] CPANPLUS support for Module::Build

[Autrijus T. <aut...@au...>]

On Sat, Jan 04, 2003 at 06:04:17PM -0600, Dave Rolsky wrote:
> What CPANPLUS should do is _load_ Module::Build and then do something like
> this:
>=20
>   my $build =3D resume Module::Build (
>     properties =3D> {
>       config_dir =3D> '_build',
>       build_script =3D> 'Build',
>     },
>   );
>   my $failures =3D $build->prereq_failures;

This is good.  Will be applied in -devel soon.

> Another problem is that CPANPLUS might end up passing MakeMaker flags to
> Module::Build (like TEST_VERBOSE=3D1 instead of verbose=3D1).  Ken, I'd
> suggest just having Module::Build look for at least a commonly used
> superset of the MM flags.

We toyed with the idea of modulebuildflags, but decided that it's
too much of trouble for a user to set things up twice.  Your suggestion
is most prudent.

Thanks,
/Autrijus/

[Module-build-general] CPANPLUS support for Module::Build

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

I was happy to see this in the latest release, but out of curiosity I
started digging into the implementation code, and I found some problems.

In CPANPLUS::Internals::Make::_find_prereq_module_build, the code looks at
the _build/prereqs and then _parses_ the file.  This is not a good idea
for several reasons.  One, the file is perfectly good Perl code, and can
be eval'd.

But even more importantly, Module::Build supports a more complex version
number specification system.  For example:

  requires => {Foo::Module => '2.4',
               Bar::Module => 0,
               Ken::Module => '>= 1.2, != 1.5, < 2.0',
               perl => '5.6.0'},

Notice the third line, which says the version must be greater than or
equal to 1.2, not 1.5, and less than 2.0.

What CPANPLUS should do is _load_ Module::Build and then do something like
this:

  my $build = resume Module::Build (
    properties => {
      config_dir => '_build',
      build_script => 'Build',
    },
  );

  my $failures = $build->prereq_failures;

$failures will contain a hashref that details exactly what failed (or
it'll be empty if everything passed).

This A) lets there be just one piece of code to check prereqs, and B) lets
CPANPLUS take advantage of Module::Build's more sophisticated version
specs (plus the ability to list conflicts, etc.)


Another problem is that CPANPLUS might end up passing MakeMaker flags to
Module::Build (like TEST_VERBOSE=1 instead of verbose=1).  Ken, I'd
suggest just having Module::Build look for at least a commonly used
superset of the MM flags.


-dave

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

[Module-build-general] [PATCH] Use ExtUtils::AutoInstall for check_prereq if possible

[Autrijus T. <aut...@au...>]

The following patch delegates check_prereq to EU::AI 0.50 (a
not-yet-released version that should handle -conflict modules),
and let EU::AI to handle the (de)installation automatically
before ./Build is run.  Comments welcome.

Thanks,
/Autrijus/

--- Base.pm.orig	Wed Dec 25 20:19:49 2002
+++ Base.pm	Wed Dec 25 20:29:04 2002
@@ -336,6 +336,9 @@
 sub check_prereq {
   my $self =3D shift;
=20
+  return $self->_check_prereq_with_autoinstall
+    if eval { require ExtUtils::AutoInstall; ExtUtils::AutoInstall->VERSIO=
N >=3D 0.50 };
+
   my $failures =3D $self->prereq_failures;
   return 1 unless $failures;
  =20
@@ -346,10 +349,33 @@
       warn "$prefix: $module: $status->{message}\n";
     }
   }
- =20
+
   warn "ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install t=
he versions ".
        "of the modules indicated above before proceeding with this install=
ation.\n";
   return 0;
+}
+
+sub _check_prereq_with_autoinstall {
+  my $self =3D shift;
+  my $req =3D { map %$_, @{$self->{properties}}{qw/build_requires requires=
/} };
+  my $rec =3D $self->{properties}{recommends};
+  my $con =3D $self->{properties}{conflicts};
+
+  ExtUtils::AutoInstall->import(
+    -version	=3D> 0.50,
+    %$req ? ( -core	=3D> [
+      map { $_ =3D> $req->{$_} } sort grep !/^perl$/, keys %$req
+    ] ) : (),
+    %$rec ? ( 'Recommended Modules' =3D> [
+	map { $_ =3D> $rec->{$_} } sort grep !/^perl$/, keys %$rec
+    ] ) : (),
+    %$con ? ( 'Conflicting Modules' =3D> [
+	-conflict =3D> 1,
+	map { $_ =3D> $con->{$_} } sort grep !/^perl$/, keys %$rec
+    ] ) : (),
+  );
+
+  return ExtUtils::AutoInstall->do_install;
 }
=20
 sub perl_version_to_float {

[Module-build-general] Some improvement to the pass-thru compat Makefile.PL

[Autrijus T. <aut...@au...>]

I just tweaked the pass-through Makefile.PL mentioned in
Module::Build::Compat to:

    - Check if the user has enough privilege to install M::B
    - Check if the user is under the non-reentrant CPAN.pm
    - Prefer CPANPLUS.pm over CPAN.pm, if present
    - Generate Makefile hints for CPAN.pm and CPANPLUS.pm

It is included below; as it's a bit long I'm not sure if
it can (or should) replace the one in Module::Build::Compat,
but FYI anyway. :-)

Thanks,
/Autrijus/

#!/usr/bin/perl -w
# This Makefile.PL creates a pass-through Makefile that simply calls
# the equivalent Module::Build methods for each make target.  See the
# documentation for Module::Build::Compat for more information.

unless (eval "use Module::Build::Compat 0.02; 1" ) {
    require Cwd;
    require File::Spec;
    require ExtUtils::MakeMaker;

    my $yn = '';
    # Check if we're likely to have permission to install Module::Build
    if (-w $INC{'ExtUtils/MakeMaker.pm'}) {
        # Check if we're under the non-reentrant CPAN.pm
        require CPAN;
        CPAN::Config->load;

        my $cwd  = File::Spec->canonpath(Cwd::cwd());
        my $cpan = File::Spec->canonpath($CPAN::Config->{cpan_home});
        if (index($cwd, $cpan) == -1) {
            print "This module requires Module::Build to install itself.\n";

            $yn = ExtUtils::MakeMaker::prompt(
                '  Install Module::Build from CPAN?', 'y'
            );
        }
    }

    if ($yn =~ /^y/i) {
        # Save this 'cause CPAN will chdir all over the place.
        my $cwd = Cwd::cwd();
        my $makefile = File::Spec->rel2abs($0);

        if (eval { require CPANPLUS::Backend; 1 }) {
            CPANPLUS::Backend->new->install(
                modules => [ 'Module::Build' ]
            );
        }
        else {
            require CPAN;
            CPAN::Shell->install('Module::Build::Compat');
        }

        chdir $cwd or die "Cannot chdir() back to $cwd: $!";
        exec $^X, $makefile, @ARGV;  # Redo now that we have Module::Build
    } else {
        warn << '.';
This module requires Module::Build to install itself.
Please re-run Makefile.PL with root privilege to install it
automatically from CPAN, or manually download it from:

    http://search.cpan.org/author/KWILLIAMS/Module-Build/

.
        # Leave hints for CPAN.pm and CPANPLUS.pm
        ExtUtils::MakeMaker::WriteMakefile(
            PREREQ_PM   => { 'Module::Build' => 0.11 }
        );

        exit(0);
    }
}

Module::Build::Compat->run_build_pl(args => \@ARGV);
Module::Build::Compat->write_makefile();

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

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

The uploaded file

     Module-Build-0.14.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.14.tar.gz
   size: 41925 bytes
    md5: 3228c4324100af1cf4a7763e0bbc4324

0.14  Fri Dec 13 14:06:29 AEST 2002

   - Added support for MacPerl (Mac OS version 9 and below), which (as
     far as I know) was never natively supported by MakeMaker.  Still
     lacks support for the 'test' action (because Test::Harness
     requires forking, which MacPerl won't do) and compiling XS/C files
     (because I don't know how to invoke a compiler on MacOS, and one
     may not even be available).  This change is brought to you by
     Michael Schwern and the letter '('.

   - Improved processing of .xs files.  Now we use the new
     ExtUtils::ParseXS module if it's available, otherwise we use
     backticks and write the result to a .c file ourselves.  This
     avoids the need to do cross-platform shell redirection.

   - Make sure all parts of 'Build test' use the not-yet-installed
     version of Module::Build.  This only affects the tests for this
     module, not any of the module code itself.  [Spotted by Schwern]

   - Oopsie - use $Config{ld} instead of $Config{cc} for linking.

   - Added a 'diff' action, which is useful for comparing the details
     of what you're about to install with what is already installed on
     your system.  This uses File::Compare, which is in the core.

   - Fixed a problem on Windows in which the _build/ directory wasn't
     getting deleted during the 'realclean' action, because we had a
     file open in that directory. [Spotted by Michael Schwern]

   - delete_filetree() now always uses File::Path::rmtree(), regardless
     of whether the thing being deleted is a file or a directory.  This
     helps remove things on obscure platforms with strange locking
     rules (or even not so obscure ones like MacOS).  It also now
     reports the number of files or directories deleted (without
     recursing directory contents).

   - rm_previous_build_script() is gone, replaced by calls to
     delete_filetree().

   - 'Build' now chdir()s in a BEGIN block, so the 'use Module::Build'
     statement will work correctly.  Solves a problem on MacOS, where
     the 'Build' script may often be invoked from the wrong working
     directory.  [Fix by Michael Schwern]

   - Internally we now use the multi-argument form of system() to run
     external commands (such as 'diff' or 'cc') whenever possible (and
     whenever we can't avoid system() altogether).  Note that this
     means we have to handle splitting some strings (such as
     $Config{ccflags}) into argument lists like the shell would, which
     is a drag.  However, the alternative would be to handle shell
     quoting of all arguments to commands ourselves, which is an even
     bigger drag across platforms and involves arbitrary filenames and
     so on.

   - To handle the argument splitting mentioned above, a method
     split_like_shell() has been created.  So far it's just doing naive
     processing.  In practice, I've yet to actually see a %Config entry
     that uses quotes & spaces, so the splitting task is usually not
     very error-prone.

   - The 'test' action now takes a 'test_files' parameter, similar to
     the (undocumented) ExtUtils::MakeMaker TEST_FILES argument.  Handy
     during development when fixing bugs.

   - Internally, the rscan_dir() method can now accept a predicate
     function that decides whether a file/directory should be matched.

   - We now issue a warning message when the author hasn't specified a
     license type.



  -Ken

Re: [Module-build-general] [PATCH t/runthrough.t] distdir needs to see M::B

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

I thought about this one some more, and I wrote another confused message 
about it, and then I realized that you were quite right in your original 
patch (modulo the disttest/distdir thingy).  I also have to set @INC 
with an absolute path (instead of Test::Harness's "blib/lib") so that 
the 'test' action sees the right M::B.

I'll apply it when I'm back online.

  -Ken


On Tuesday, December 10, 2002, at 11:42 AM, Ken Williams wrote:
> Good spot.  It's disttest though, not distdir, and this doesn't 
> actually seem to fix the problem.  The BEGIN block in the generated 
> Build script doesn't contain the directory it needs to.
>
> This is kind of a tough one to make a test for.
>
>
> On Monday, December 9, 2002, at 07:51 PM, Michael G Schwern wrote:
>
>> When t/runthrough.t runs a distdir perl Build.PL is run.  It can't see 
>> the
>> uninstalled Module::Build, the child process doesn't inherit its 
>> parent's
>> @INC.  Simplest way around this is to set PERL5LIB.
>>
>> This patch fixes:
>>
>> --- t/runthrough.t	27 Nov 2002 02:15:18 -0000	1.4
>> +++ t/runthrough.t	9 Dec 2002 08:46:40 -0000
>> @@ -1,15 +1,17 @@
>> -######################### We start with some black magic to print on 
>> failure.
>> +#!/usr/bin/perl -w
>>
>>  use Test;
>>  BEGIN { plan tests => 10 }
>>  use Module::Build;
>> +use Cwd;
>>  use File::Spec;
>>  use File::Path;
>>  my $HAVE_YAML = eval {require YAML; 1};
>>
>>  ok(1);
>>
>> -######################### End of black magic.
>> +# So distdir can see the uninstalled Module::Build.
>> +$ENV{PERL5LIB} = File::Spec->rel2abs(File::Spec->catdir('blib', 
>> 'lib'));
>>
>>  my $goto = File::Spec->catdir( Module::Build->cwd, 't', 'Sample' );
>>  chdir $goto or die "can't chdir to $goto: $!";
>>
>>
>>
>> --
>>
>> Michael G. Schwern   <sc...@po...>    
>> http://www.pobox.com/~schwern/
>> Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job 
>> One
>>     And God was pleased.
>>     And Dog was happy and wagged his tail.
>>     And Adam was greatly improved.
>>     And Cat did not care one way or the other.
>> 	-- http://www.catsarefrommars.com/creationist.htm
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Module-build-general mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/module-build-general
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module-build-general] [PATCH t/runthrough.t] distdir needs to see M::B

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

Good spot.  It's disttest though, not distdir, and this doesn't actually 
seem to fix the problem.  The BEGIN block in the generated Build script 
doesn't contain the directory it needs to.

This is kind of a tough one to make a test for.

  -Ken


On Monday, December 9, 2002, at 07:51 PM, Michael G Schwern wrote:

> When t/runthrough.t runs a distdir perl Build.PL is run.  It can't see 
> the
> uninstalled Module::Build, the child process doesn't inherit its 
> parent's
> @INC.  Simplest way around this is to set PERL5LIB.
>
> This patch fixes:
>
> --- t/runthrough.t	27 Nov 2002 02:15:18 -0000	1.4
> +++ t/runthrough.t	9 Dec 2002 08:46:40 -0000
> @@ -1,15 +1,17 @@
> -######################### We start with some black magic to print on 
> failure.
> +#!/usr/bin/perl -w
>
>  use Test;
>  BEGIN { plan tests => 10 }
>  use Module::Build;
> +use Cwd;
>  use File::Spec;
>  use File::Path;
>  my $HAVE_YAML = eval {require YAML; 1};
>
>  ok(1);
>
> -######################### End of black magic.
> +# So distdir can see the uninstalled Module::Build.
> +$ENV{PERL5LIB} = File::Spec->rel2abs(File::Spec->catdir('blib', 
> 'lib'));
>
>  my $goto = File::Spec->catdir( Module::Build->cwd, 't', 'Sample' );
>  chdir $goto or die "can't chdir to $goto: $!";
>
>
>
> --
>
> Michael G. Schwern   <sc...@po...>    
> http://www.pobox.com/~schwern/
> Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job 
> One
>     And God was pleased.
>     And Dog was happy and wagged his tail.
>     And Adam was greatly improved.
>     And Cat did not care one way or the other.
> 	-- http://www.catsarefrommars.com/creationist.htm
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>

[Module-build-general] Compiling better but still unwell on Cygwin

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

Trying the CVS snapshot on Cygwin, we get up to linking and then things go
wrong.  $Config{ld} is ld2 which calls perlld which calls dllwrap which
does the actual linking.  dllwrap is complaining.  Here's part of the xs.t
output.

ok 3
lib/XSTest.pm -> blib/lib/XSTest.pm
gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include -Iusr/lib/perl5/5.6.1/cygwin-multi/CORE -o lib/XSTest.o lib/XSTest.c
lib/XSTest.bs -> blib/arch/auto/XSTest/XSTest.bs
env LD_RUN_PATH=/usr/lib/perl5/5.6.1/cygwin-multi/CORE ld2 -s -L/usr/local/lib -o blib/arch/auto/XSTest.dll lib/XSTest.o
dllwrap --dllname XSTest.dll --driver-name gcc --dlltool ddlltool --export-all-symbols --as as --output-def libXSTest.def --output-lib lbXSTest.a \
-s -L/usr/local/lib lib/XSTest.o
dllwrap: no export definition file provided.
Creating one, but that may not be what you want
lib/XSTest.o(.tet+0x2d):XSTest.c: undefined reference to '_Perl_Gcurinterp_ptr' 
...etc...

Not sure what dllwrap is yelling about.  There's no man page.


-- 

Michael G. Schwern   <sc...@po...>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job One
Let's leave my ass out of this, shall we?

[Module-build-general] [PATCH t/runthrough.t] distdir needs to see M::B

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

When t/runthrough.t runs a distdir perl Build.PL is run.  It can't see the
uninstalled Module::Build, the child process doesn't inherit its parent's
@INC.  Simplest way around this is to set PERL5LIB.

This patch fixes:

--- t/runthrough.t	27 Nov 2002 02:15:18 -0000	1.4
+++ t/runthrough.t	9 Dec 2002 08:46:40 -0000
@@ -1,15 +1,17 @@
-######################### We start with some black magic to print on failure.
+#!/usr/bin/perl -w
 
 use Test;
 BEGIN { plan tests => 10 }
 use Module::Build;
+use Cwd;
 use File::Spec;
 use File::Path;
 my $HAVE_YAML = eval {require YAML; 1};
 
 ok(1);
 
-######################### End of black magic.
+# So distdir can see the uninstalled Module::Build.
+$ENV{PERL5LIB} = File::Spec->rel2abs(File::Spec->catdir('blib', 'lib'));
 
 my $goto = File::Spec->catdir( Module::Build->cwd, 't', 'Sample' );
 chdir $goto or die "can't chdir to $goto: $!";



-- 

Michael G. Schwern   <sc...@po...>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job One
    And God was pleased.
    And Dog was happy and wagged his tail.
    And Adam was greatly improved.
    And Cat did not care one way or the other.
	-- http://www.catsarefrommars.com/creationist.htm

[Module-build-general] Fixed the linking code, I think?

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

I just noticed that the link_c() method was using $Config{cc}, 
not $Config{ld}, to do the linking.  They're the same on my 
platform, but not on Win32, apparently.  Maybe someone on Win32 
could try the current CVS code and tell me whether it works?  
Last I heard from Schwern, the linking was broken, so this may 
be why.

I'd like to release a 0.14 version soon, there are zillions of 
changes in the Changes file.

  -Ken

[Module-build-general] ExtUtils::ParseXS -> CPAN

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

The uploaded file

     ExtUtils-ParseXS-1.98_01.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/ExtUtils-ParseXS-1.98_01.tar.gz
   size: 20294 bytes
    md5: 7f5e33fe81c051ecba769f6f532b2206

This wraps the functionality of xsubpp into a module interface.  
I'm using it for Module::Build, falling back to running xsubpp 
if ParseXS isn't installed.


  -Ken

Re: [Module-build-general] Testing again

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

On Mon, Dec 02, 2002 at 07:14:26PM -0800, Michael G Schwern wrote:
> SF hates my MTA.  They might have made up, just testing that.
> 
> Sorry for the test post.

Hey, it WORKED!  Ken doesn't have to channel my thoughts anymore.


-- 

Michael G. Schwern   <sc...@po...>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job One
We don't know.  But if we did, we wouldn't tell you.

[Module-build-general] Testing

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

Sorry about this test post, but SF hates my MTA.  Seeing if they've made up.

-- 

Michael G. Schwern   <sc...@po...>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job One
Playstation?  Of course Perl runs on Playstation.
    -- Jarkko Hietaniemi

[Module-build-general] Testing

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

Sorry for the silly test post, I'm just checking to see if SF still hates my
MTA.

-- 

Michael G. Schwern   <sc...@po...>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job One
It's Flypaper Licking time!

[Module-build-general] Testing again

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

SF hates my MTA.  They might have made up, just testing that.

Sorry for the test post.


-- 

Michael G. Schwern   <sc...@po...>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee Is Job One
Is there an airport nearby or is that just my tae-kwon-do taking off?

[Module-build-general] Re: MB MacOS fixes

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

On Thursday, November 28, 2002, at 01:14  PM, Michael G Schwern wrote:

> On Thu, Nov 28, 2002 at 12:39:16PM +1100, Ken Williams wrote:
>>> - 'use blib' normally looks for blib/lib and blib/arch but on
>>> MacPerl, for
>>>  some reason, it looks for blib/lib and blib/MacPerl.  Probably some
>>>  MakeMaker wackiness.  As M::B follows a more sane naming scheme the
>>>  exception in blib.pm screws things up.  So we just use the
>>> much simpler
>>>  and much quieter "use lib blib/lib blib/arch"
>>
>> The problem isn't that it's looking for blib/MacPerl (at least,
>> not on my box, 5.6.1r1), it's that it's blindly applying Unix
>> naming conventions.  When I fixed those, 'use blib;' worked fine.
>
> I'm using the 5.8 MacPerl alpha.  5.8.0 changed blib to do the Mac 
> specific
> arch directory.

ok.


>> But you're right, we don't really need it to search up & down
>> the file tree, we can just add these libs directly (though with
>> File::Spec - I suspect it was finding your previously installed
>> copy?).
>
> I think @INC will accept Unix style filenames.  Or maybe this was only 
> fixed
> in 5.8.

It doesn't work in 5.6.1, unfortunately.  I'm not sure whether it was 
just the lib.pm changes or changes in how @INC is used by require() and 
use() and friends, though.

In any case, a slash in a filename under MacOS is ambiguous, since 
files & directories can contain actual slash characters.  There's a 
comment in pp_ctl.c about this.  So it looks like it's preferred to have 
locally native paths in @INC.  Correct me if I'm wrong on this.

>
> My previously installed copy of what?  Module::Build?  Hadn't installed 
> it.

Hm, must have been the 5.6 vs. 5.8 difference then.

Unfortunately, the 'use lib qw(lib);' thingy generates other problems on 
MacPerl 5.6.1 in conjunction with Mac::MoreFiles (which is used by 
File::Copy, which is used by Module::Build), which I'll detail in a 
separate message to ma...@pe....


>>> build, help, distcheck, distclean, clean and realclean were
>>> confirmed to
>>> work.  test should work with ToolServer, Test::Harness is the problem.
>>> fakeinstall and install work with a repaired ExtUtils::Install.
>
> I was thinking about this, and I think I have a solution to the
> ExtUtils::Install problem.  It goes something like this:
>
> use ExtUtils::Install;
>
> {
>     no warnings 'redefine';
>     sub ExtUtils::Install::find {
>         my($code, @dirs) = @_;
>
>         @dirs = map { $_ eq '.' ? File::Spec->curdir : $_ } @dirs;
>
>         return File::Find::find($code, @dirs);
>     }
> }
>
> ie. MacOS.pm can load ExtUtils::Install and replace its directly import
> File::Find::find() with a wrapper find() which fixes the hard coded '.'
> problem. That way MacPerl/Module::Build users won't have to upgrade
> MakeMaker.

Looks good.  I'm adding it like this, in Platform/MacOS.pm:


--------------------------------------------------
# ExtUtils::Install has a hard-coded '.' directory in versions less
# than 1.30.  We use a sneaky trick to turn that into ':'.
#
# Note that we do it here in a cross-platform way, so this code could
# actually go in Module::Build::Base.  But we put it here to be less
# intrusive for other platforms.

unless ( eval {ExtUtils::Install->VERSION('1.30')} ) {
   no warnings 'redefine';
   *ExtUtils::Install::find = sub {
     my ($code, @dirs) = @_;

     @dirs = map { $_ eq '.' ? File::Spec->curdir : $_ } @dirs;

     return File::Find::find($code, @dirs);
   }
}
--------------------------------------------------

  -Ken

[Module-build-general] Re: MB MacOS fixes

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

On Saturday, November 30, 2002, at 10:23  PM, Ken Williams wrote:
> Looks good.  I'm adding it like this, in Platform/MacOS.pm:
>
> --------------------------------------------------
> # ExtUtils::Install has a hard-coded '.' directory in versions less
> # than 1.30.  We use a sneaky trick to turn that into ':'.
> #
> # Note that we do it here in a cross-platform way, so this code could
> # actually go in Module::Build::Base.  But we put it here to be less
> # intrusive for other platforms.
>
> unless ( eval {ExtUtils::Install->VERSION('1.30')} ) {
>   no warnings 'redefine';
>   *ExtUtils::Install::find = sub {
>     my ($code, @dirs) = @_;
>
>     @dirs = map { $_ eq '.' ? File::Spec->curdir : $_ } @dirs;
>
>     return File::Find::find($code, @dirs);
>   }
> }
> --------------------------------------------------

Correction: because of a bug in UNIVERSAL::VERSION() and a misbehaving 
version number in ExtUtils::Install 1.28, the above doesn't work.  
Here's the UNIVERSAL bug (using perl 5.6.1):

   [kw-009:~] ken% perl -le '$Foo::VERSION = "1.28"; print 
Foo->VERSION(1.30)'
   Foo version 1.3 required--this is only version 1.28 at -e line 1.
   [kw-009:~] ken% perl -le '$Foo::VERSION = "1.28 "; print 
Foo->VERSION(1.30)'
   49.046050056032

And here's the misbehaving ExtUtils::Install version number (already 
fixed in 1.29):

   $VERSION = substr q$Revision: 1.28 $, 10;

So here's how I'm putting the patch in:

   sub ACTION_install {
     my $self = shift;

     return $self->SUPER::ACTION_install(@_)
       if ExtUtils::Install->VERSION ge '1.30';

     no warnings 'redefine';
     local *ExtUtils::Install::find = sub {
       my ($code, @dirs) = @_;

       @dirs = map { $_ eq '.' ? File::Spec->curdir : $_ } @dirs;

       return File::Find::find($code, @dirs);
     };

     return $self->SUPER::ACTION_install(@_);
   }


  -Ken

[Module-build-general] Re: Understanding $Config{startperl} in MacPerl

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

On Sunday, December 1, 2002, at 01:25  PM, em...@ap... wrote:

> On Friday, November 29, 2002, at 09:19  PM, Ken Williams wrote:
>
>> I see that in MacPerl (not perl for OS X), $Config{startperl} 
>> is set to
>>
>>     "Perl -Sx \"{0}\" {\"Parameters\"}; Exit {Status}\n#!perl"
>>
>> in Config.pm .  I'm not sure what that extra stuff is before 
>> the  shebang, but when I run a script that contains that 
>> (using MacPerl  5.6.1), I just get a perl syntax error.  When 
>> I remove it, all is > well.
>>
>> Can anyone enlighten about what that first line is for?
>
> That line is a MacPerl compatibility with MPW (Macintosh 
> Programmer's  Workshop), the old Mac development environment.  
> According the MacPerl  book, this line allow scripts to be 
> called directly from MPW without  the need to call the Perl 
> tool directly.  MacPerl knows to ignore this  line, but Mac OS 
> X perl does not.

Hmm, from my testing, MacPerl 5.6.1 didn't know how to ignore 
that line either.  I got syntax errors until I removed it.

> I think it is safe to leave it out (and only include the 
> appropriate  shebang line), as if anyone is still using MPW, 
> they are probably used  to adding that line to Perl scripts.

Okay, thanks, that's what I'll do.

  -Ken

[Module-build-general] Re: Understanding $Config{startperl} in MacPerl

[<em...@ap...>]

On Friday, November 29, 2002, at 09:19  PM, Ken Williams wrote:

> I see that in MacPerl (not perl for OS X), $Config{startperl} is set to
>
>     "Perl -Sx \"{0}\" {\"Parameters\"}; Exit {Status}\n#!perl"
>
> in Config.pm .  I'm not sure what that extra stuff is before the  
> shebang, but when I run a script that contains that (using MacPerl  
> 5.6.1), I just get a perl syntax error.  When I remove it, all is > well.
>
> Can anyone enlighten about what that first line is for?

That line is a MacPerl compatibility with MPW (Macintosh Programmer's  
Workshop), the old Mac development environment.  According the MacPerl  
book, this line allow scripts to be called directly from MPW without  
the need to call the Perl tool directly.  MacPerl knows to ignore this  
line, but Mac OS X perl does not.

I think it is safe to leave it out (and only include the appropriate  
shebang line), as if anyone is still using MPW, they are probably used  
to adding that line to Perl scripts.
------------------------------------------------------------------------ 
--
Edward Moy
Apple Computer, Inc.
em...@ap...

(This message is from me as a reader of this list, and not a statement
from Apple.)

[Module-build-general] Understanding $Config{startperl} in MacPerl

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

Hi,

I see that in MacPerl (not perl for OS X), $Config{startperl} is set to

     "Perl -Sx \"{0}\" {\"Parameters\"}; Exit {Status}\n#!perl"

in Config.pm .  I'm not sure what that extra stuff is before the 
shebang, but when I run a script that contains that (using 
MacPerl 5.6.1), I just get a perl syntax error.  When I remove 
it, all is well.

Can anyone enlighten about what that first line is for?

Schwern and I have been working on getting Module::Build to 
support MacOS natively, because (1) then MacOS won't have to use 
different module-building procedures from the rest of the world, 
and (2) it's a good cross-platform proving ground since it's so 
different from Unix.

  -Ken

[Module-build-general] Re: MB MacOS fixes

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

[cc'd to Module::Build list]

On Wednesday, November 27, 2002, at 10:48  PM, Michael G Schwern wrote:
> Here it is.
>
> - Becuase its easy to run ./Build from the wrong cwd in 
> MacPerl, it has to
>   chdir() to the Module::Build directory in the BEGIN block so the lib/
>   in @INC works to find the uninstalled Module::Build.  Since 
> this is useful
>   in general I put it in M::B::Base

Yup.


> - 'use blib' normally looks for blib/lib and blib/arch but on 
> MacPerl, for
>   some reason, it looks for blib/lib and blib/MacPerl.  Probably some
>   MakeMaker wackiness.  As M::B follows a more sane naming scheme the
>   exception in blib.pm screws things up.  So we just use the 
> much simpler
>   and much quieter "use lib blib/lib blib/arch"

The problem isn't that it's looking for blib/MacPerl (at least, 
not on my box, 5.6.1r1), it's that it's blindly applying Unix 
naming conventions.  When I fixed those, 'use blib;' worked fine.

But you're right, we don't really need it to search up & down 
the file tree, we can just add these libs directly (though with 
File::Spec - I suspect it was finding your previously installed 
copy?).

> - atime and mtime are the same thing on MacOS.  So when stuff is copied
>   from lib to blib they wind up with the same -M.  
> copy_if_modified() was
>   checking if -M blib/foo < -M lib/foo but on MacOS they would be equal
>   after the copy.  So its changed to -M blib/foo <= -M lib/foo to make
>   it work.  This shouldn't hurt other platforms, so its in Base.

I've changed copy_if_modified() to use the up_to_date() method, 
which I think was already doing it correctly.  No use having 
this criterion in two places.

>
> The overrides in M::B::P::MacOS should be documented enough to 
> explain why
> they're there.  If you can't figure them out, I need to write 
> better docs.

Looks good.

> build, help, distcheck, distclean, clean and realclean were 
> confirmed to
> work.  test should work with ToolServer, Test::Harness is the problem.
> fakeinstall and install work with a repaired ExtUtils::Install.

Cool.

  -Ken

>
>
>
> diff -ru Module-Build-0.13.orig/lib/Module/Build/Base.pm Module-
> Build-0.13/lib/Module/Build/Base.pm
> --- Module-Build-0.13.orig/lib/Module/Build/Base.pm	2002-11-20 
> 00:58:46.000000000 -0800
> +++ Module-Build-0.13/lib/Module/Build/Base.pm	2002-11-27 
> 03:14:11.000000000 -0800
> @@ -456,9 +456,11 @@
>    print $fh <<EOF;
>  $self->{config}{startperl} -w
>
> -BEGIN { \@INC = ($quoted_INC) }
> +BEGIN {
> +    \@INC = ($quoted_INC);
> +    chdir('$base_dir') or die 'Cannot chdir to $base_dir: '.\$!;
> +}
>
> -chdir('$base_dir') or die 'Cannot chdir to $base_dir: '.\$!;
>  use $build_package;
>
>  # This should have just enough arguments to be able to 
> bootstrap the rest.
> @@ -612,8 +614,7 @@
>
>    # Make sure we test the module in blib/
>    {
> -    local $SIG{__WARN__} = sub {};  # shut blib.pm up
> -    eval "use blib";
> +    eval "use lib 'blib/lib', 'blib/arch'";
>    }
>    die $@ if $@;
>
> @@ -1003,7 +1004,7 @@
>    } else {
>      $to_path = File::Spec->catfile($to, $file);
>    }
> -  return if -e $to_path and -M $to_path < -M $file;  # Already fresh
> +  return if -e $to_path and -M $to_path <= -M $file;  # Already fresh
>
>    # Create parent directories
>    File::Path::mkpath(File::Basename::dirname($to_path), 0, 0777);
> diff -ru Module-
> Build-0.13.orig/lib/Module/Build/Platform/MacOS.pm Module-
> Build-0.13/lib/Module/Build/Platform/MacOS.pm
> --- Module-Build-0.13.orig/lib/Module/Build/Platform/MacOS.pm	2001-11-11 
> 12:50:32.000000000 -0800
> +++ Module-Build-0.13/lib/Module/Build/Platform/MacOS.pm	2002-11-27 03:37:
> 43.000000000 -0800
> @@ -7,10 +7,6 @@
>  @ISA = qw(Module::Build::Base);
>
>
> -1;
> -__END__
> -
> -
>  =head1 NAME
>
>  Module::Build::Platform::MacOS - Builder class for MacOS platforms
> @@ -20,9 +16,119 @@
>  The sole purpose of this module is to inherit from
>  C<Module::Build::Base>.  Please see the L<Module::Build> for the docs.
>
> +=head2 Overriden Methods
> +
> +=over 4
> +
> +=item new
> +
> +MacPerl doesn't define $Config{sitelib} or $Config{sitearch} for some
> +reason, but $Config{installsitelib} and $Config{installsitearch} are
> +there.  So we copy the install variables to the other location
> +
> +=cut
> +
> +sub new {
> +  my $class = shift;
> +  my $self = $class->SUPER::new(@_);
> +
> +  $self->{config}{sitelib}  ||= $self->{config}{installsitelib};
> +  $self->{config}{sitearch} ||= $self->{config}{installsitearch};
> +
> +  return $self;
> +}
> +
> +=item make_build_script_executable
> +
> +On MacOS we set the file type and creator to MacPerl so it will run
> +with a double-click.
> +
> +=cut
> +
> +sub make_build_script_executable {
> +  my $self = shift;
> +	
> +  # Can't hurt to make it read-only.
> +  $self->SUPER::make_build_script_executable;
> +	
> +  require MacPerl;
> +  MacPerl::SetFileInfo('McPL', 'TEXT', 
> $self->{properties}{build_script});
> +}
> +
> +=item rm_previous_build_script
> +
> +MacOS maps chmod -w to locking the file.  This mean we have to unlock
> +it before removing it.
> +
> +=cut
> +
> +sub rm_previous_build_script {
> +  my $self = shift;
> +
> +  if( $self->{properties}{build_script} ) {
> +    chmod 666, $self->{properties}{build_script};
> +  }
> +  $self->SUPER::rm_previous_build_script;
> +}
> +
> +=item dispatch
> +
> +Because there's no easy way to say "./Build test" on MacOS, if
> +dispatch is called with no arguments and no @ARGV a dialog box will
> +pop up asking what action to take and any extra arguments.
> +
> +Default action is "test".
> +
> +=cut
> +
> +sub dispatch {
> +  my $self = shift;
> +
> +  if( !@_ and !@ARGV ) {
> +    require MacPerl;
> +
> +    # What comes first in the action list.
> +    my @action_list = qw(test install build);
> +    my %actions;
> +    {
> +      no strict 'refs';
> +
> +      foreach my $class ($self->super_classes) {
> +        foreach ( keys %{ $class . '::' } ) {
> +          $actions{$1}++ if /ACTION_(\w+)/;
> +        }
> +      }
> +    }
> +
> +    delete @actions{@action_list};
> +    push @action_list, sort { $a cmp $b } keys %actions;
> +    $ARGV[0] = MacPerl::Pick('What build command?', @action_list);
> +    push @ARGV, split /\s+/,
> +                  MacPerl::Ask('Any extra arguments?  (ie. 
> verbose=1)', '');
> +  }
> +
> +  $self->SUPER::dispatch(@_);
> +}
> +
> +
> +=item ACTION_realclean
> +
> +Need to unlock the Build program before deleting.
> +
> +=cut
> +
> +sub ACTION_realclean {
> +  my $self = shift;
> +  chmod 666, $self->{properties}{build_script};
> +  $self->SUPER::ACTION_realclean;
> +}
> +
> +
> +=back
> +
>  =head1 AUTHOR
>
> -Ken Williams, ke...@fo...
> +Michael G Schwern <sc...@po...>
>
>  =head1 SEE ALSO

Re: [Module-build-general] Re: redirecting system() to a file, or ways to avoid it

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

On Wednesday, November 27, 2002, at 11:33  AM, Michael G Schwern wrote:

> SF.net hates me, so I'll just post straight to you.
>
>
> On Wed, Nov 27, 2002 at 12:13:23AM +1100, Ken Williams wrote:
>> In Module::Build, very little is done by the external system, but some
>> things still are.  One little thorn in its side is ExtUtils::xsubpp -
>> which, despite living in @INC and having two colons in its name, is a
>> script, not a module.  In order to parse .xs files, this 
>> script needs to
>> be called and its output redirected to a file.
>
> I hereby disavow all responsiblity for xsubpp, Amen.
>
> You might want to look at the ExtUtils::MM_Unix->tool_xsubpp 
> method to see
> how MakeMaker locates xsubpp and the typemap file.

Will do.  I'm already finding that stuff, but maybe I need to be 
more complicated.


>
>
>> That's not usually a very hard task, but I've decided to use the
>> multi-arg form of system() whenever possible, so that I don't have to
>> handle argument quoting issues on all the platforms of the world.  But
>> the multi-arg form of system() doesn't let me do output 
>> redirects (which
>> probably weren't portable across platforms anyway with single-arg
>> system()).
>
> In general `someprogram some args > some_file` is plenty 
> portable, even on
> VMS.  And that should be all you need.
> `$^X path/to/xsubpp -some -args foo.xs > some_tmp_file`

Hm, I guess I'll do that if none of the other easy solutions 
work.  As I mentioned, for every system() call or fork() I can 
get rid of, Texas Instruments will donate $50,000 to the 
Make-A-Wish Foundation.  Who am I to deny all those wishes?


> What isn't portable is any piping or redirecting STDERR.
>
> If you look at the new code in ExtUtils::MM_Unix->find_perl() 
> you'll see we
> supress STDERR by temporarily closing it.
> http://makemaker.org/src/ExtUtils-MakeMaker-
> snap/lib/ExtUtils/MM_Unix.pm
>
>     # To avoid using the unportable 2>&1 to supress STDERR,
>     # we close it before running the command.
>     close STDERR if $stderr_duped;
>     $val = `"$abs" -e "require $ver; print qq{VER_OK\n}"`;
>     open STDERR, '>&STDERR_COPY' if $stderr_duped;
>
> Closing STDERR outright seems portable.  Tying STDERR and/or 
> STDOUT to a
> file may be unreliable in certain versions of Perl.

Okay, thanks for the tip.  In this case I'll probably just want 
STDERR to go to the terminal, but for future cases I may need to 
suppress it.


>
>> So I'm trying to think of the best alternative.  Choices include:
>>
>>  1) Wrap all of the xsubpp code into a subroutine, set @ARGV, open
>> STDOUT to a file, and call the subroutine.
>>
>>  2) Same as 1), but just do() the xsubpp file instead of making it a
>> subroutine.
>
> #1 would work.  Something like:
>
>     sub xsubpp {
>         my($self, $file) = @_;
> 	local @ARGV = ($file);
> 	
> 	open(SAVE_STDOUT, '>&STDOUT');
> 	tie *STDOUT, to memory;
> 	
> 	do ExtUtils::xsubpp;
> 	
> 	open(STDOUT, '>&SAVE_STDOUT');
> 	
> 	return $whatever_you_captured;
>     }

Unfortunately, ExtUtils::xsubpp does an exit(), so I'd also have 
to override *CORE::GLOBAL::exit.  And I'm getting some errors 
like "ValidProtoString() called too early to check prototype", 
which I think means that this code doesn't like being called 
embeddedly.  Or maybe I can just prototype those subroutines in 
advance.


>>  4) Go back in time and re-implement ExtUtils::xsubpp as a bare-bones
>> wrapper around an ExtUtils::ParseXS module.  Module::Build can 
>> just call
>> functions in ExtUtils::ParseXS, then.
>>
>>  5) Don't go back in time, but create an ExtUtils::ParseXS module
>> nonetheless, which *future* versions of xsubpp could use as guts.
>> Create a Module::Build dependency on ExtUtils::ParseXS and don't call
>> xsubpp.
>
> I'd like that.

It's looking more likely.


>>  6) Borg all the xsubpp code into Module::Build where I can 
>> control it.
>
> The stuff in xsubpp is supposed to be very version specific, 
> that's why we
> don't ship it with the CPAN version of ExtUtils::MakeMaker.

Oof, so an ExtUtils::ParseXS module would have to take version 
info into account?  Sounds hairy.  Maybe a 'diff' of it from 
perl version to perl version would enlighten.  Is it also 
*platform* specific?


>> Even though 1) and 2) are pretty ugly, I'm leaning toward doing one of
>> them, if they'd work.  3) looks non-fun, and the further away 
>> I can get
>> Module::Build and system() from each other, the better.  4) 
>> and 5) would
>> be a lot of work, but probably the best from an architectural point of
>> view.  4) would be really cool, actually.  Note that 5) would 
>> create the
>> first non-5.6-core dependency in Module::Build, though.  And 6) seems
>> like a bad idea.
>>
>> There's also:
>>
>>  7) Just write it as a single-arg, ad hoc system() call, don't worry
>> about cross-platform issues, make those MacOS bastards live without XS
>> compilation a little while longer, and only fix the quoting 
>> when someone
>> tells me it's broken on VMS and Amiga, and Win95.
>
> I think it'll work on MacPerl since any XS compiling requires 
> the MPW shell.
> MacPerl might also just emulate `perl ...`.

hmmm...

  -Ken