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

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

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

On Wednesday, November 27, 2002, at 10:49  AM, Uri Guttman wrote:
> make a pipe, fork, dup stdout to the pipe (in child), then in child
> multi arg exec.
>
> this is all that backticks or open "foo|" does.

Will this work on systems that don't have good fork() support?  
The perl prerequisite for Module::Build is 5.6.0, is that enough 
to guarantee fork()?

I just keep thinking that all we're doing is reading a file and 
writing a file, and I shouldn't have to fork a process for 
that.  Maybe creating an ExtUtils::ParseXS is the way to go.


  -Ken

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

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

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.


> 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`

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.

> 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;
     }

Normally you could get away with just "select(*TIED)" but xsubpp 
has hard
coded "print STDOUT" it and it too plays with "select(*STDOUT)".

Tying STDOUT is sometimes a little twitchy.


>  3) Write some function to convert multi-arg system() calls to
> safely-quoted single-arg system() calls, in a cross-platform way, with
> cross-platform support for output redirection.

See ExtUtils::MM_Any->oneliner in the snapshots.  But you should be safe
without all that work.


>  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.


>  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.


> 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 ...`.


--

Michael G. Schwern   <sc...@po...>    
http://www.pobox.com/~schwern/
Perl Quality Assurance      <pe...@pe...>         Kwalitee 
Is Job One
michael schwern is

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

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

On Tuesday, November 26, 2002, at 05:48  PM, Ken Williams wrote:

> Additional complication when I tried these kinds of solutions: xsubpp 
> does an exit() when it's finished.  So I either have to temporarily 
> override *CORE::GLOBAL::exit, or I have to run it in a subprocess one 
> way or another.

Hrm, maybe in a fork?

> By the way, it's simpler to just open() STDOUT to a file than to tie() 
> it.

Yeah, but you'd mentioned that already. ;-)

David

-- 
David Wheeler                                     AIM: dwTheory
da...@wh...                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Th...@ja...

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

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

On Wednesday, November 27, 2002, at 11:29  AM, David Wheeler wrote:

> On Tuesday, November 26, 2002, at 05:13  AM, Ken Williams wrote:
>
>> 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.
>
> Can you tie STDOUT to a file to capture the output of xsubpp?

Additional complication when I tried these kinds of solutions: 
xsubpp does an exit() when it's finished.  So I either have to 
temporarily override *CORE::GLOBAL::exit, or I have to run it in 
a subprocess one way or another.

By the way, it's simpler to just open() STDOUT to a file than to 
tie() it.

  -Ken

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

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

On Tuesday, November 26, 2002, at 05:13  AM, Ken Williams wrote:

> 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.

Can you tie STDOUT to a file to capture the output of xsubpp?

David

-- 
David Wheeler                                     AIM: dwTheory
da...@wh...                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Th...@ja...

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

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

Hey,

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.

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()).

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.

  3) Write some function to convert multi-arg system() calls to 
safely-quoted single-arg system() calls, in a cross-platform way, with 
cross-platform support for output redirection.

  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.

  6) Borg all the xsubpp code into Module::Build where I can control it.


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.

Any thoughts before I act?

  -Ken

[Module-build-general] Re: build -n?

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

On Sunday, November 24, 2002, at 05:29  PM, Uri Guttman wrote:

>
> ken,
>
> is there a way to get build to behave like make -n? i would like to see
> what would get executed by build without running those commands.

Thing is, most of what's done isn't done with "commands".  It's usually 
just perl code to carry out the task.  Only things like compiling C code 
typically require external commands to be performed.

That means there's no unified way to see what the command would have 
been.

For 'install', you can use the 'fakeinstall' action instead, to see what 
would have happened.

> i have been rtfming and can't find anything like that. i see verbose=1
> but it seems to only affect the test code. i don't see any way to affect
> build itself other than the key=value stuff which seems to be mostly
> target specific. but i don't know it well enough to know for sure about
> that.

It's true, most of it is target-specific.

  -Ken

[Module-build-general] Re: Module-Build CVS on Cygwin98

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

On Thursday, November 21, 2002, at 11:55  AM, Michael G Schwern wrote:
>
> Why do you even keep $self->{cleanup_fh} around and open?  Its 
> only used
> immediately after its set in add_to_cleanup().  It seems the 
> only use is to
> determine if you've already appended to the cleanup file, so 
> maybe it can be
> replaced with a boolean?

add_to_cleanup() may be called multiple times, and it seemed 
wasteful to do a bunch of opening & closing.  I suppose I could 
open & close it every time add_to_cleanup() is called, but I'm 
not sure there's a very compelling reason to do that.

  -Ken

[Module-build-general] Re: Module-Build CVS on Cygwin98

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

On Wednesday, November 20, 2002, at 09:33  PM, Michael G Schwern wrote:

> Attached is the results from running ./Build test against Module::Build
> from CVS on Cygwin98 4.10 with their default 5.6.1.
>
> The failure to cleanup _build is probably due to the mandatory 
> locking on
> Windows.  You must have a file open inside that directory when 
> realclean is
> done.  $self->{cleanup_fh} looks like the problem.  If I 
> manually close that
> in ACTION_realclean() just before $self->delete_filetree() is called
> everything's ok.
>
> Given that it looks like $self->{cleanup_fh} is only used inside
> add_to_cleanup() you can probably eliminate it.

Thanks for tracking this down - it would have taken me a while 
to figure that out.  I'll patch like this:

@@ -707,6 +706,12 @@
  sub ACTION_realclean {
    my ($self) = @_;
    $self->depends_on('clean');
+  if ($self->{cleanup_fh}) {
+    # On Windows, you can't delete a directory with files open inside,
+    # so we close the cleanup file.
+    close $self->{cleanup_fh};
+    delete $self->{cleanup_fh};
+  }
    $self->delete_filetree($self->{properties}{config_dir}, 
$self->{properties}{build_script});
  }





>
>
> As for the linker errors, I don't even understand linking on Linux.
>

Eek - either someone will have to reach in with the hand of God 
to show what the problem is, or I'll have to get access to a 
machine with Cygwin.  I could probably figure it out then.  
Unfortunately, it look like SF doesn't have it in their compile 
farm.


>
>
> t/basic.............1..11
> ok 1
> Checking whether your kit is complete...
> Looks good
> ok 2
> Checking whether your kit is complete...
> Looks good
> ok 3
> ok 4
> Checking whether your kit is complete...
> Looks good
> ok 5
> ok 6
> ok 7
> ok 8
> ok 9
> Checking whether your kit is complete...
> Looks good
> ok 10
> ok 11
> Deleting blib
> Deleting _build
> Can't remove directory _build: Directory not empty at 
> /cygdrive/c/temp/Module-Build/blib/lib/Module/Build/Base.pm 
> line 863
> Couldn't remove '_build':
> dubious
> 	Test returned status 255 (wstat 65280, 0xff00)
> 	after all the subtests completed successfully
> t/runthrough........1..10
> ok 1
> Checking whether your kit is complete...
> Looks good
> ok 2
> Removing previous file 'Build'
> Creating new 'Build' script for 'Sample' version '0.01'
> ok 3
> lib/Sample.pm -> blib/lib/Sample.pm
> test.p..............ok
> All tests successful.
> Files=1, Tests=1,  1 wallclock secs ( 0.00 cusr +  0.00 csys =  
> 0.00 CPU)
> ok 4
> /usr/bin/perl Build.PL
> Checking whether your kit is complete...
> Looks good
> Creating new 'Build' script for 'Sample' version '0.01'
> ../Build
> lib/Sample.pm -> blib/lib/Sample.pm
> ../Build test
> No tests defined.
> ok 5
> ok 6
> Deleting Sample-0.01
> ok 7
> ok 8
> ok 9
> Deleting blib
> Deleting _build
> Can't remove directory _build: Directory not empty at 
> /cygdrive/c/temp/Module-Build/blib/lib/Module/Build/Base.pm 
> line 863
> not ok 10
> # Test 10 got: 'Couldn't remove '_build':
> ' (t/runthrough.t at line 50)
> #    Expected: ''
> FAILED test 10
> 	Failed 1/10 tests, 90.00% okay
> t/xs................1..7
> ok 1
> Checking whether your kit is complete...
> Looks good
> ok 2
> ok 3
> lib/XSTest.pm -> blib/lib/XSTest.pm
> /usr/bin/perl -I/usr/lib/perl5/5.6.1/cygwin-multi 
> -I/usr/lib/perl5/5.6.1 /usr/lib/perl5/5.6.1/cygwin-
> multi/ExtUtils/xsubpp -noprototypes -typemap 
> '/usr/lib/perl5/5.6.1/cygwin-multi/ExtUtils/typemap' 
> lib/XSTest.xs > lib/XSTest.c
> gcc  -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing 
> -I/usr/local/include -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE 
> -o lib/XSTest.o lib/XSTest.c
> ExtUtils::Mkbootstrap::Mkbootstrap('lib/XSTest')
> lib/XSTest.bs -> blib/arch/auto/XSTest/XSTest.bs
> env LD_RUN_PATH=/usr/lib/perl5/5.6.1/cygwin-multi/CORE gcc  -s 
> -L/usr/local/lib -o blib/arch/auto/XSTest/XSTest.dll 
> lib/XSTest.o
> lib/XSTest.o(.text+0x2d):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x37):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x48):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x52):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x60):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x6a):XSTest.c: undefined reference to 
> `_Perl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x87):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x91):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0xbb):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xcd):XSTest.c: undefined reference to `_Perl_croak'
> lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xe3):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x10c):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x116):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x13d):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x14b):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x155):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x174):XSTest.c: undefined reference to 
> `_Perl_sv_2iv'
> lib/XSTest.o(.text+0x189):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x193):XSTest.c: undefined reference to 
> `_Perl_Top_ptr'
> lib/XSTest.o(.text+0x1ab):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to 
> `_Perl_Tcurpad_ptr'
> lib/XSTest.o(.text+0x1c3):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1cd):XSTest.c: undefined reference to 
> `_Perl_Top_ptr'
> lib/XSTest.o(.text+0x1ef):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1f9):XSTest.c: undefined reference to 
> `_Perl_sv_newmortal'
> lib/XSTest.o(.text+0x21f):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x229):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x260):XSTest.c: undefined reference to 
> `_Perl_sv_setiv'
> lib/XSTest.o(.text+0x27b):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x28c):XSTest.c: undefined reference to 
> `_Perl_mg_set'
> lib/XSTest.o(.text+0x2a4):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2ae):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x2bc):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2c6):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x306):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x310):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x31e):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x328):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x336):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x340):XSTest.c: undefined reference to 
> `_Perl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x35d):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x367):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x391):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3b2):XSTest.c: undefined reference to 
> `_Perl_newXS'
> lib/XSTest.o(.text+0x3be):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3c8):XSTest.c: undefined reference to 
> `_Perl_Isv_yes_ptr'
> lib/XSTest.o(.text+0x3d6):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3e0):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x3fd):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x407):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x415):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x41f):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> /usr/lib/gcc-lib/i686-pc-
> cygwin/3.2/../../../libcygwin.a(libcmain.o)(.text+0x7c): 
> undefined reference to `_WinMain@16'
> collect2: ld returned 1 exit status
> not ok 4
> # Test 4 got: 'error building lib/XSTest.o from 
> 'lib/XSTest.dll' at /cygdrive/c/temp/Module-
> Build/blib/lib/Module/Build/Base.pm line 930.
> ' (t/xs.t at line 28)
> #   Expected: ''
> lib/XSTest.bs -> blib/arch/auto/XSTest/XSTest.bs
> env LD_RUN_PATH=/usr/lib/perl5/5.6.1/cygwin-multi/CORE gcc  -s 
> -L/usr/local/lib -o blib/arch/auto/XSTest/XSTest.dll 
> lib/XSTest.o
> lib/XSTest.o(.text+0x2d):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x37):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x48):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x52):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x60):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x6a):XSTest.c: undefined reference to 
> `_Perl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x87):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x91):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0xbb):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xcd):XSTest.c: undefined reference to `_Perl_croak'
> lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xe3):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x10c):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x116):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x13d):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x14b):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x155):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x174):XSTest.c: undefined reference to 
> `_Perl_sv_2iv'
> lib/XSTest.o(.text+0x189):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x193):XSTest.c: undefined reference to 
> `_Perl_Top_ptr'
> lib/XSTest.o(.text+0x1ab):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to 
> `_Perl_Tcurpad_ptr'
> lib/XSTest.o(.text+0x1c3):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1cd):XSTest.c: undefined reference to 
> `_Perl_Top_ptr'
> lib/XSTest.o(.text+0x1ef):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1f9):XSTest.c: undefined reference to 
> `_Perl_sv_newmortal'
> lib/XSTest.o(.text+0x21f):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x229):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x260):XSTest.c: undefined reference to 
> `_Perl_sv_setiv'
> lib/XSTest.o(.text+0x27b):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x28c):XSTest.c: undefined reference to 
> `_Perl_mg_set'
> lib/XSTest.o(.text+0x2a4):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2ae):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x2bc):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2c6):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x306):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x310):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x31e):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x328):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x336):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x340):XSTest.c: undefined reference to 
> `_Perl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x35d):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x367):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x391):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3b2):XSTest.c: undefined reference to 
> `_Perl_newXS'
> lib/XSTest.o(.text+0x3be):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3c8):XSTest.c: undefined reference to 
> `_Perl_Isv_yes_ptr'
> lib/XSTest.o(.text+0x3d6):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3e0):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x3fd):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x407):XSTest.c: undefined reference to 
> `_Perl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x415):XSTest.c: undefined reference to 
> `_Perl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x41f):XSTest.c: undefined reference to 
> `_Perl_Tstack_base_ptr'
> /usr/lib/gcc-lib/i686-pc-
> cygwin/3.2/../../../libcygwin.a(libcmain.o)(.text+0x7c): 
> undefined reference to `_WinMain@16'
> collect2: ld returned 1 exit status
> not ok 5
> # Test 5 got: 'error building lib/XSTest.o from 
> 'lib/XSTest.dll' at /cygdrive/c/temp/Module-
> Build/blib/lib/Module/Build/Base.pm line 930.
> ' (t/xs.t at line 32)
> #   Expected: ''
> Deleting lib/XSTest.o
> Deleting lib/XSTest.bs
> Deleting blib
> Deleting lib/XSTest.c
> ok 6
> ok 7
> FAILED tests 4-5
> 	Failed 2/7 tests, 71.43% okay
> Failed Test    Status Wstat Total Fail  Failed  List of Failed
> --------------------------------------------------------------------------------
> t/basic.t     	 255 65280    11    0   0.00%  ??
> t/runthrough.t	              10    1  10.00%  10
> t/xs.t        	               7    2  28.57%  4-5
> Failed 3/3 test scripts, 0.00% okay. 3/28 subtests failed, 89.29% okay.
>
>
>
> --
>
> Michael G. Schwern   <sc...@po...>    
> http://www.pobox.com/~schwern/
> Perl Quality Assurance      <pe...@pe...>         Kwalitee 
> Is Job One
> The desired effect is what you get when you improve your interplanetary
> funksmanship.
>


  -Ken

[Module-build-general] About the Module::Build project

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

Hi, I'm Module::Build.  You may remember me from such P5P posts as

    "Thoughts From TPC: New Modules In 5.9"
    [ http://makeashorterlink.com/?O28C32182 ]

    "Builds, YAML, etc etc etc"
    [ http://makeashorterlink.com/?I59C21182 ]

    "Re: Proof-of-concept patch for 'make distsign'"
    [ http://makeashorterlink.com/?E3BC21182 ]

    "BEGIN perl-5.9"
    [ http://makeashorterlink.com/?G53D12182 ]

[Ken cans the anthropomorphization act]

The Module::Build project is still rolling along.  Development 
discussion and announcements are taking place at the 
module-build-general list (see the Cc: header), which you can subscribe 
to at

  http://lists.sourceforge.net/mailman/listinfo/module-build-general .

Some of the tasks on the TODO list include:

* Add a 'distsign' action that uses Module::Signature to provide
   cryptographic authentication to module distributions

* Figure out how to cooperate well with real packaging systems
   (chiefly RPM, Debian, and PPM).  May mean creating packages ourselves,
   may mean creating lists of stuff to let package managers chew on, may
   mean something else.

Some things recently done include:

* Better support for C and C++ source in distributions

* Much better support for pass-through Makefile.PLs (for cooperations 
with
   legacy CPAN.pm shells and so on)

* Better cooperation with weird filesystems (like case-insensitivity
   issues, 8.3 naming issues, etc.)

* Better cooperation with various versions of Test::Harness

* More sensible distinction between a "module" and a "distribution"


The purpose of this message, besides just being a state-of-the-module 
address, is to invite people to join the discussion, because I get the 
sense that there are more people with important knowledge germane to 
this project than the seven existing members of the current 
module-build-general list.  If you have interest, please feel free to 
browse the archives and/or subscribe to the list.  Your input is most 
welcome.


  -Ken

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

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

The uploaded file

     Module-Build-0.13.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.13.tar.gz
   size: 37473 bytes
    md5: dbc2192ca19fef323b10d9a35ea9b156

Changes since version 0.12:


   - 'cleanup' file lists are now written immediately, rather than at
     program termination.  This helps avoid "phantom files" that don't
     get handled by the 'realclean' action.  The internal
     write_cleanup() method (which was never documented) is now gone.

   - The 'blib/' directory is now properly cleaned up in more (all?)
     circumstances.  Previously it could become a phantom if
     create_build_script() was never called.

   - Now scan the 'c_source' directory for .cpp (C++) files as well as
     .c files, and compiles them.

   - Use a 'phony' target for 'make manifest' in the pass-through
     Makefile, for the same reason as 'make install' (see version 0.12
     notes below).

   - Module::Build::Compat now accepts any known Config.pm key and
     passes it through to the Build.PL.  Fixes a problem with CPANPLUS,
     which was passing INSTALLMAN1DIR.

   - The file 'META.yaml' has been re-named to 'META.yml' in order to
     cooperate better with systems that can only handle 3 characters
     after the dot.

   - The t/xs.t test should give more informative error messages upon
     failure.



  -Ken

Re: [Module-build-general] Re: build and manifest

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

On Tuesday, November 19, 2002, at 01:59  PM, Brian Ingerson wrote:

> On 19/11/02 10:59 +1100, Ken Williams wrote:
>> Heh - I hope I didn't open a can of worms with this M::B
>> project, though sometimes it seems as if I did. ;-)
>
> I AM YOUR FATHER, KEN.
> JOIN THE DARK SIDE!
>
> -- Darth Ingy

Funny, I just watched Episode 2 for the first time last night.

Better watch out - if our knowledge of The Code is insufficient 
to settle our dispute, we will have to use the rm -rf sabers.

  -Ken

Re: [Module-build-general] Re: build and manifest

[Brian I. <in...@tt...>]

On 19/11/02 10:59 +1100, Ken Williams wrote:
> [cc'd to the module-build list]
> 
> Hi Uri,
> 
> On Tuesday, November 19, 2002, at 06:52  AM, Uri Guttman wrote:
> > hi ken (and dave),
> >
> > dave is forcing me to use your module::build stuff so i have 
> > rtfm'ed and
> > will be playing with it more. i have lots of needs and ideas so i feel
> > you should get an earful right away. :)
> 
> Good, it's always good to have more people trying to do new 
> stuff with it.
> 
> > my first question is about manifest handling. the current method i use
> > in stem is actually to tar up what is in CVS. this is good in 
> > that i can
> > control which files in my dev tree are worth shipping. but it 
> > also means
> > it ships CVS dirs, and cvs is a pain to manage for manifests. but from
> > what i gather with your system, you build MANIFEST from the 
> > lib/ dir and
> > use the manifest.skip file to control it. i would like to have a
> > positive manifest file that i can edit (in addition or whatever). the
> > reason is that i have many temp and work in progress files in my dev
> > directory and i don't want to have to add each one to the skip
> > file. whereas i don't add new source files as frequently so editing a
> > manifest.in would be easier for me. this could take dirs and recurse
> > down them as well. so any answers or thoughts on a postive manifest.in
> > file?
> 
> Module::Build uses the same MANIFEST model as 
> ExtUtils::MakeMaker - it uses a MANIFEST file to determine what 
> should go in the distribution during 'Build dist' (and 'Build 
> disttest', etc.).  You can maintain this MANIFEST file by hand, 
> or it will auto-generate it if you do a 'Build manifest'.
> 
> So your hand-maintained MANIFEST should work just fine if I 
> understand your needs.
> 
> > i do appreciate your conceit that who needs make? one day when i have
> > mucho money to hire some good hackers, i will lead the creation of my
> > super make that will be DB backed, have bidirectional dependency
> > knowledge at all times, and have real knowledge about how to 
> > build stuff
> > instead of annoying templates and macros. i can dream. :)
> 
> Heh - I hope I didn't open a can of worms with this M::B 
> project, though sometimes it seems as if I did. ;-)

I AM YOUR FATHER, KEN.
JOIN THE DARK SIDE!

-- Darth Ingy

[Module-build-general] Re: build and manifest

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

[cc'd to the module-build list]

Hi Uri,

On Tuesday, November 19, 2002, at 06:52  AM, Uri Guttman wrote:
> hi ken (and dave),
>
> dave is forcing me to use your module::build stuff so i have 
> rtfm'ed and
> will be playing with it more. i have lots of needs and ideas so i feel
> you should get an earful right away. :)

Good, it's always good to have more people trying to do new 
stuff with it.

> my first question is about manifest handling. the current method i use
> in stem is actually to tar up what is in CVS. this is good in 
> that i can
> control which files in my dev tree are worth shipping. but it 
> also means
> it ships CVS dirs, and cvs is a pain to manage for manifests. but from
> what i gather with your system, you build MANIFEST from the 
> lib/ dir and
> use the manifest.skip file to control it. i would like to have a
> positive manifest file that i can edit (in addition or whatever). the
> reason is that i have many temp and work in progress files in my dev
> directory and i don't want to have to add each one to the skip
> file. whereas i don't add new source files as frequently so editing a
> manifest.in would be easier for me. this could take dirs and recurse
> down them as well. so any answers or thoughts on a postive manifest.in
> file?

Module::Build uses the same MANIFEST model as 
ExtUtils::MakeMaker - it uses a MANIFEST file to determine what 
should go in the distribution during 'Build dist' (and 'Build 
disttest', etc.).  You can maintain this MANIFEST file by hand, 
or it will auto-generate it if you do a 'Build manifest'.

So your hand-maintained MANIFEST should work just fine if I 
understand your needs.

> i do appreciate your conceit that who needs make? one day when i have
> mucho money to hire some good hackers, i will lead the creation of my
> super make that will be DB backed, have bidirectional dependency
> knowledge at all times, and have real knowledge about how to 
> build stuff
> instead of annoying templates and macros. i can dream. :)

Heh - I hope I didn't open a can of worms with this M::B 
project, though sometimes it seems as if I did. ;-)

  -Ken

[Module-build-general] Re: build and manifest

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

[ reply sent to m-b list ... ]

On Mon, 18 Nov 2002, Uri Guttman wrote:

> my first question is about manifest handling. the current method i use
> in stem is actually to tar up what is in CVS. this is good in that i can
> control which files in my dev tree are worth shipping. but it also means
> it ships CVS dirs, and cvs is a pain to manage for manifests. but from
> what i gather with your system, you build MANIFEST from the lib/ dir and
> use the manifest.skip file to control it. i would like to have a
> positive manifest file that i can edit (in addition or whatever). the
> reason is that i have many temp and work in progress files in my dev
> directory and i don't want to have to add each one to the skip
> file. whereas i don't add new source files as frequently so editing a
> manifest.in would be easier for me. this could take dirs and recurse
> down them as well. so any answers or thoughts on a postive manifest.in
> file?

I'll answer this.  BTW, Uri, there's a module-build users list at

For a MANIFEST file, M::B works like EU::MM.  You can provide it a file or
ask it make one for you with "./Build manifest".  Both EU::MM and M::B use
ExtUtils::Manifest under the hood, so the results are pretty much the
same.

The easiest thing to do is let M::B build an initial MANIFEST file, edit
it, and then check it in to CVS.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

[Module-build-general] META.yaml -> META.yml

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

Hi,

In a small sign that the Module::Build interface is still 
alpha-ish, I've just changed the name of the 'metafile' it 
creates from META.yaml to META.yml.  Schwern pointed out that 
this will play better on filesystems with 8.3 naming conventions.

If any external tools (CPAN, CPANPLUS, etc.) are reading this 
file, they'll have to start looking for the newly-named one.

  -Ken

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

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

The uploaded file

     Module-Build-0.12.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.12.tar.gz
   size: 37104 bytes
    md5: 44004c489c8ebb6155332cbd7750e54d

Changes since 0.11:

   - The META.yaml file was erroneously looking for 'build_depends'
     instead of 'build_requires'. [spotted by Iain Truskett]

   - Add prompt() and y_n() methods for use in Build.PLs

   - Do more to work with all versions of Test::Harness when setting
     the TEST_VERBOSE flag and running under the debugger [patch by
     Dave Rolsky]

   - Include a test for verbosity handling

   - Make sure the blib/ directory is always cleaned up with the
     'clean' or 'realclean' action.

   - In a pass-through Makefile.PL, inform 'make' that 'install' is a
     "fake target", so that it works properly on case-insensitive
     filesystems like HFS+ with distributions that contain an INSTALL
     file. [patch by Brian Ingerson]

   - In Module::Build::Compat, show an example Makefile.PL that can
     install Module::Build and re-invoke itself in one fell swoop [Dave
     Rolsky and Autrijus Tang]

   - Improve the formatting of the Module::Build and
     Module::Build::Compat documentation.


  -Ken

[Module-build-general] Re: BIG PICTURE Q on Module::Build

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

Hi Soren,

[CC-ing to the Module::Build list]

Yes, I saw your post about this on the MakeMaker list too.  The 
answer is that Module::Build doesn't currently support this, but 
it definitely could, and I don't think it would be too 
difficult.  It would require having separate parameters that 
indicate where the source is and where to build things before 
testing & installation.

I'll be happy to consider patches to Module::Build if you're 
willing to write them and accept feedback.

  -Ken

On Tuesday, November 5, 2002, at 03:34  PM, Soren Andersen wrote:

> Hello Ken,
>
> You've been on the edges (sorry) of my radar screen for a while, and it
> finally seems inevitable that i attempt to contact you about something.
>
> Because your project Module::Build seems like the most high-profile
> attempt to do away with MakeMaker (maybe the only attempt) i 
> now think i
> should ask you about the following.
>
> I'm one of those people who has invested so much time into studying
> ExtUtils::MakeMaker that I have been reluctant to even allocate
> synapse-share to thinking about another build system. I gather, 
> however,
> that the unhappiness with E:MM is widespread and shared even by many
> persons who subscribe to the E:MM List (to which i have recently posted
> about my project, asking for help, and noticing that it appears that
> Schwern and everyone else has pretty much been kidnapped by aliens or
> something...).
>
> I wish to ask you the following: will your module build support system
> allow building-outside-the-location-of-the-source-distribution (I
> hyphenate that phrase to hilight just how unwieldy -- in urgent need of
> Acronym-ization or abbrieviation -- it is). What i call (for 
> much greater
> brevity): 'exobuilding'. I am far less concerned, myself, with making
> CPAN
> automation the highest priority (as wrongheaded as that may be, it's
> where I am at), than with making it possible to treat Perl distribution
> files just like C or C++ or Java (or almost any other source code to a
> modern programming language) files: let the sources for Perl modules be
> buildable in a separate disk location from where they are 
> stored. This is
> a GNU standard. I believe in it.
>
> Argumentation about the merits aside, does Module::Build 
> already support
> this or plan to support this, in any way? If not, would you be 
> willing to
> consider addition of this optional functionality to future 
> development of
> your system?
>
>   Thanks,
>     Soren Andersen
>
> --
> http://fastmail.fm - Faster than the air-speed velocity of an
> 		      unladen european swallow

Re: [Module-build-general] patch to Compat.pm in CVS

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

On Monday, November 4, 2002, at 04:56  PM, Dave Rolsky wrote:

> --- Module-Build-clean/lib/Module/Build/Compat.pm	2002-11-03
> 23:56:45.000000000 -0600
> +++ Module-Build/lib/Module/Build/Compat.pm	2002-11-03
> 23:56:56.000000000 -0600
> @@ -142,9 +142,7 @@
>  corresponding Module::Build actions.  That's what this module lets you
>  do.
>
> -A typical Makefile.PL is shown above in L<SYNOPSIS>.  See also
> -L<FALLBACK> for some code that can help if the user doesn't have
> -Module::Build installed yet.
> +A typical Makefile.PL is shown above in L<SYNOPSIS>.
>
>  So, some common scenarios are:
>

Thanks, applied.

  -Ken

[Module-build-general] patch to Compat.pm in CVS

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

--- Module-Build-clean/lib/Module/Build/Compat.pm	2002-11-03
23:56:45.000000000 -0600
+++ Module-Build/lib/Module/Build/Compat.pm	2002-11-03
23:56:56.000000000 -0600
@@ -142,9 +142,7 @@
 corresponding Module::Build actions.  That's what this module lets you
 do.

-A typical Makefile.PL is shown above in L<SYNOPSIS>.  See also
-L<FALLBACK> for some code that can help if the user doesn't have
-Module::Build installed yet.
+A typical Makefile.PL is shown above in L<SYNOPSIS>.

 So, some common scenarios are:

Re: [Module-build-general] A better passthrough Makefile.PL

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

On Thursday, October 31, 2002, at 09:33  PM, Ken Williams wrote:
> Actually, I just had an idea - would the following small change work 
> (note the 'touch' line, "open $0")?
>
>   unless (eval "use Module::Build::Compat 0.02; 1" ) {
>     # Workaround with old CPAN.pm and CPANPLUS.pm
>     require ExtUtils::MakeMaker;
>     ExtUtils::MakeMaker::WriteMakefile(
>       PREREQ_PM => { 'Module::Build::Compat' => 0.02 }
>     );
>     warn "Warning: prerequisite Module::Build::Compat is not found.\n";
>     sleep 2;  # Wait a couple seconds after writing Makefile
>     open my($fh), ">> $0"  # Change modification date
>       or warn "You may have to run 'perl Makefile.PL' again.";
>     exit(0);
>   }
>   Module::Build::Compat->run_build_pl(args => \@ARGV);
>   Module::Build::Compat->write_makefile();
>
> The idea is that it changes the modification time for Makefile.PL to be 
> after the Makefile's, so that Makefile.PL gets re-run.

I got this working, but only sort of.  I had to change the open() stuff 
to utime() (duh) to get an effective touch.  But the problem is that 
even though the Makefile is rebuilt, CPAN.pm doesn't notice.  See below.


> This is kind of tough to test out - Dave, how did you test this before?

I figured out a really kludgey way to test it.

To get CPAN to build from local tarballs, I did this:

  1) Disconnect from the network so CPAN can't reload its metafiles.
  2) Replace the Makefile.PL for Params::Validate with a pass-through 
Makefile.PL like the one above, and create a Build.PL for it.
  3) Make a tarball of Params::Validate and put it in 
~/.cpan/sources/authors/id/D/DR/DROLSKY/.
  4) Uninstall Module::Build and Module::Build::Compat from my system.
  5) Make a tarball of Module::Build and put it in 
~/.cpan/sources/authors/id/K/KW/KWILLIAMS/.
  6) Delete the checksums for Module::Build and Params::Validate from the 
CHECKSUMS files in ~/.cpan/sources/authors/id/... since they're no 
longer valid.

Then in the cpan shell I did 'install Params::Validate' to see what 
would happen.  CPAN successfully notices that Module::Build is a 
prerequisite and installs it.  Then when it goes back to install 
Params::Validate, 'make' notices that the Makefile is out of date and 
rebuilds it, returning an error status.  But then for some reason CPAN 
extracts the tarball *again*, and rebuilds the blib/ or something, and 
everything goes to hell (where it can stay, as far as I'm concerned).

This means that in order to install Params::Validate, I had to do 
'install Params::Validate', 'clean Params::Validate', 'install 
Params::Validate'.  Ish.

I think it also didn't get the prerequisites right - CPAN probably only 
registered a prereq of Module::Build, and not Attribute::Handlers.

So I think we'll indeed have to invoke CPAN->install if we want it to be 
all in one step.  I'll try that next.

  -Ken

Re: [Module-build-general] A better passthrough Makefile.PL

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

On Friday, November 1, 2002, at 04:44  PM, Ken Williams wrote:
>
> So I think we'll indeed have to invoke CPAN->install if we want it to 
> be all in one step.  I'll try that next.

Okay, there's a patch for this in Module::Build::Compat.

  -Ken

Re: [Module-build-general] A better passthrough Makefile.PL

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

On Fri, 1 Nov 2002, Ken Williams wrote:

> >  'Foo::Bar >= 2, <= 3.5 | Foo::Baz == 2.1'
>
> I wonder too.   Hmmmm.  I'm not too thrilled with that particular
> syntax, I've seen something somewhat better in Fink (which I guess is
> probably taken from debian's stuff).

That was a _very_ off-the-top-of-my-head syntax.  I'm just thinking that
we may want to offer a mini-language option in addition to a simple hash
based option.  I suspect Fink is using the mini-language used by Debian,
which would certainly be a good thing to take a look at.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: [Module-build-general] A better passthrough Makefile.PL

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

On Friday, November 1, 2002, at 01:22  AM, Dave Rolsky wrote:

> On Thu, 31 Oct 2002, Ken Williams wrote:
>
>> I've been ruminating on this, and I think what I want to do is put 
>> hooks
>> into M::B that will use EU::AI if it's installed (and if the user wants
>> auto-installation), but that EU::AI should remain the way to
>> automatically install modules.  M::B should use EU::AI, not Borg its
>> code.  Obviously this is better from a separation-of-labor & modularity
>> point of view, and I think it feels better from a policy point of view
>> too.
>>
>> EU::AI can be a recommended dependency for M::B then.
>
> But some of what EU::AI just makes sense for M::B.  M::B already breaks 
> up
> dependencies in a more fine-grained way the EU::MM, so why not go a step
> further and do what EU::AI does, and offer a break not only by
> build/test/run but also by feature.  This is just generically useful.

Oh, maybe I don't understand what EU::AI is for.  I'll download and 
investigate.

> I also like the idea of being able to specify that _specific tests_
> have a dependency, so M::B can just skip them if that dependency is not
> satisfied.

Specific tests can already be skipped by various criteria, but that 
happens inside the test by emitting specific Test::Harness stuff rather 
than being controlled by the builder.

> In other words, I think have a very full-featured dependency handling
> feature is an important goal for M::B.  Auto-installing of modules is 
> not
> what I was aiming at.  M::B should cooperate with CPAN and CPANPLUS in
> this regard (or use EU::AI, etc.)

Agreed on the last part - I'll read more about EU::AI.

>> A very related problem is the idea of alternative dependencies - for
>> instance, Crypt::SKey needs either Digest::MD4 or Digest::MD5, but
>> there's no great way to indicate that with M::B's dependency
>> specification right now.
>
> Good thing to add.  I wonder if the current way of doing this as a hash 
> of
> "module name => version spec" is too inflexible?
>
> I almost wonder if supporting a mini-language might be best.  We already
> have the beginning with the version spec, so maybe something like:
>
>  'Foo::Bar >= 2, <= 3.5 | Foo::Baz == 2.1'

I wonder too.   Hmmmm.  I'm not too thrilled with that particular 
syntax, I've seen something somewhat better in Fink (which I guess is 
probably taken from debian's stuff).

  -Ken

Re: [Module-build-general] A better passthrough Makefile.PL

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

On Thu, 31 Oct 2002, Ken Williams wrote:

> I've been ruminating on this, and I think what I want to do is put hooks
> into M::B that will use EU::AI if it's installed (and if the user wants
> auto-installation), but that EU::AI should remain the way to
> automatically install modules.  M::B should use EU::AI, not Borg its
> code.  Obviously this is better from a separation-of-labor & modularity
> point of view, and I think it feels better from a policy point of view
> too.
>
> EU::AI can be a recommended dependency for M::B then.

But some of what EU::AI just makes sense for M::B.  M::B already breaks up
dependencies in a more fine-grained way the EU::MM, so why not go a step
further and do what EU::AI does, and offer a break not only by
build/test/run but also by feature.  This is just generically useful.

I also like the idea of being able to specify that _specific tests_
have a dependency, so M::B can just skip them if that dependency is not
satisfied.

In other words, I think have a very full-featured dependency handling
feature is an important goal for M::B.  Auto-installing of modules is not
what I was aiming at.  M::B should cooperate with CPAN and CPANPLUS in
this regard (or use EU::AI, etc.)

> A very related problem is the idea of alternative dependencies - for
> instance, Crypt::SKey needs either Digest::MD4 or Digest::MD5, but
> there's no great way to indicate that with M::B's dependency
> specification right now.

Good thing to add.  I wonder if the current way of doing this as a hash of
"module name => version spec" is too inflexible?

I almost wonder if supporting a mini-language might be best.  We already
have the beginning with the version spec, so maybe something like:

 'Foo::Bar >= 2, <= 3.5 | Foo::Baz == 2.1'

??


-dave

/*==================
www.urth.org
we await the New Sun
==================*/