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

Re: [Module::Build] Module::Build hangs during test

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

On 11/28/2003 7:36 PM, Jim Cromie wrote:

> 
> hang happens during test of 2 different CPAN modules,
> on 2 different x86 linux boxes (both running 5.8.2), but not with 5.9.0
> 
> It also hangs on 5.6.2, doing a cpan> install Module::Build,
> at make test.  What follows is from a couple
> of days ago, I shelved til I could pursue it further, but its 4th down,
> I need to punt to you all, and play defense.   Ill try some more to make
> this report more conclusive.
> 
> 
> heres 2 runs, 1st with 5.9.0, which behaves well,
> 2nd with 5.8.2, which hangs
> 
> 
> 
> [jimc@harpo Array-Compare-1.09]$ perl5.9.0 Makefile.PL
> /usr/local/bin/perl5.9.0 Build.PL
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Array-Compare' version '1.09'
> 
> [jimc@harpo Array-Compare-1.09]$ make    /usr/local/bin/perl5.9.0 Build
> 
> [jimc@harpo Array-Compare-1.09]$ make test
> /usr/local/bin/perl5.9.0 Build test
> t/pod.....ok                                                                 
> 
> t/test....ok                                                                 
> 
> All tests successful.
> Files=2, Tests=25,  1 wallclock secs ( 1.45 cusr +  0.05 csys =  1.50 CPU)
> 
> 
> 
> [jimc@harpo Array-Compare-1.09]$ perl Makefile.PL
> /usr/local/bin/perl Build.PL
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Array-Compare' version '1.09'
> [jimc@harpo Array-Compare-1.09]$ make
> /usr/local/bin/perl Build
> [jimc@harpo Array-Compare-1.09]$ make test
> /usr/local/bin/perl Build test
> t/pod.....make: *** [test] Interrupt
> 
> 

perl Build test verbose=1
perl -MTest::Harness -e 'print $Test::Harness::VERSION'

Randy.

Re: [Module::Build] MB uses wrong perl

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

On 11/28/2003 7:51 PM, Jim Cromie wrote:

> 
> when I use an older perl (ex: perl5.6.2) to build the Makefile, several 
> things go wrong;
> 
> 1.  Makefile uses /usr/local/bin/perl, not /usr/local/bin/perl5.6.2
> 
> all : force_do_it
>    /usr/local/bin/perl Build
> 
> This patch 'seems' to fix this prob (but does nothing for my separate 
> hanging problem).
> I saw your Change notes about $^X unreliability, so this may not be the 
> thing, but its a start..
> 
> diff -ru Module-Build-0.21/lib/Module/Build/Base.pm 
> Module-Build-0.21-mod/lib/Module/Build/Base.pm
> --- Module-Build-0.21/lib/Module/Build/Base.pm    Wed Oct 15 19:25:18 2003
> +++ Module-Build-0.21-mod/lib/Module/Build/Base.pm    Fri Nov  7 
> 17:10:22 2003
> @@ -166,8 +166,8 @@
> sub find_perl_interpreter {
>   my $perl;
>   File::Spec->file_name_is_absolute($perl = $^X)
> -    or -f ($perl = $Config::Config{perlpath})
> -    or ($perl = $^X);
> +    or ($perl = $^X)
> +    or -f ($perl = $Config::Config{perlpath});
>   return $perl;
> }
> 
> 
> 2.  executable version mismatch.
> 
> 
> [root@harpo Module-Build-0.21]# perl5.6.2 Makefile.PL
> perl5.6.2 Build.PL
> Checking whether your kit is complete...
> Looks good
> WARNING: ExtUtils::ParseXS: Prerequisite ExtUtils::ParseXS isn't installed
> WARNING: YAML: Prerequisite YAML isn't installed
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the 
> versions
> of the modules indicated above before proceeding with this installation.
> 
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Module-Build' version '0.21'
> [root@harpo Module-Build-0.21]# make
> /usr/local/bin/perl Build
> Perl lib version (v5.6.2) doesn't match executable version (v5.8.2) at 
> /usr/local/lib/perl5/5.6.2/i686-linux/Config.pm line 21.
> 
> 
> guidance appreciated,
> reqs for more info welcome,
> 
> jimc
> 

perl -V

WAG. Is @INC pointing to the right places.

Randy.

Re: [Module::Build] have_c_compiler uncovers Windoze bug

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

On 10/30/2003 9:36 PM, Randy W. Sims wrote:
> Hi Ken,
> 
> Version 1.220 of M::B::Base.pm uncovered a bug. On Windows, an 
> executable requires different options to the linker than a dynamic 
> library. Currently link_c() is configured strictly to produce libraries. 
> A quick and perhaps naive fix is to introduce an optional paramater to 
> link_c() to indicate the desired type of the output file. But, I want to 

Here is a tmp patch to fix have_c_compiler(). This is to fullfill what 
the prophet Ken spoke to Yves and all of module-authors saying:

"This is actually an unfortunate bug in version 0.21 on Win32.  Other 
previous versions have worked fine, and I believe this specific issue 
has already been fixed in CVS."

Actually, one major issue was already fixed in CVS. This is a fix for 
the only remaining major issue that I'm aware of (for MSWin32). This fix 
is ugly as sin. I probably should have wrote special overrides of 
have_c_compiler() for each of the compilers on MSWin32 that would 
manually invoke the compiler and linker (i.e. not use compile_c() & 
link_c()), but this solution should work for every platform/toolset for now.

There is, however, a small problem:

C:\devel\perl\bin\perl.exe Build.PL
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'XSTest' version '0.01'
ok 1
ok 2
lib\XSTest.pm -> blib\lib\XSTest.pm
lib\XSTest.xs -> lib\XSTest.c
Generating script 'lib\XSTest.ccs'
cl -c @"lib\XSTest.ccs" -Fo"lib\XSTest.obj" "lib\XSTest.c"
XSTest.c
XSTest.xs(10) : warning C4129: 'X' : unrecognized character escape sequence
XSTest.xs(13) : warning C4129: 'X' : unrecognized character escape sequence
ExtUtils::Mkbootstrap::Mkbootstrap('lib\XSTest')
ExtUtils::Mksymlists::Mksymlists('lib\XSTest')

This is due to a problem in ExtUtils::ParseXS. EU::ParseXS generates 
lines like the following in the 'C' file:

#line 20 "lib\XSTest.c"

The backslash/Win32 dir separator in that string should be translated to 
a forward slash or double backslash. This is not a fatal error; it's 
just an annoying warning.

Randy.

[Module::Build] MB uses wrong perl

[Jim C. <jc...@di...>]

when I use an older perl (ex: perl5.6.2) to build the Makefile, several 
things go wrong;

1.  Makefile uses /usr/local/bin/perl, not /usr/local/bin/perl5.6.2

all : force_do_it
    /usr/local/bin/perl Build

This patch 'seems' to fix this prob (but does nothing for my separate 
hanging problem).
I saw your Change notes about $^X unreliability, so this may not be the 
thing, but its a start..

diff -ru Module-Build-0.21/lib/Module/Build/Base.pm 
Module-Build-0.21-mod/lib/Module/Build/Base.pm
--- Module-Build-0.21/lib/Module/Build/Base.pm    Wed Oct 15 19:25:18 2003
+++ Module-Build-0.21-mod/lib/Module/Build/Base.pm    Fri Nov  7 
17:10:22 2003
@@ -166,8 +166,8 @@
 sub find_perl_interpreter {
   my $perl;
   File::Spec->file_name_is_absolute($perl = $^X)
-    or -f ($perl = $Config::Config{perlpath})
-    or ($perl = $^X);
+    or ($perl = $^X)
+    or -f ($perl = $Config::Config{perlpath});
   return $perl;
 }


2.  executable version mismatch.


[root@harpo Module-Build-0.21]# perl5.6.2 Makefile.PL
perl5.6.2 Build.PL
Checking whether your kit is complete...
Looks good
WARNING: ExtUtils::ParseXS: Prerequisite ExtUtils::ParseXS isn't installed
WARNING: YAML: Prerequisite YAML isn't installed
ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the 
versions
 of the modules indicated above before proceeding with this installation.

Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Module-Build' version '0.21'
[root@harpo Module-Build-0.21]# make
/usr/local/bin/perl Build
Perl lib version (v5.6.2) doesn't match executable version (v5.8.2) at 
/usr/local/lib/perl5/5.6.2/i686-linux/Config.pm line 21.


guidance appreciated,
reqs for more info welcome,

jimc

[Module::Build] Module::Build hangs during test

[Jim C. <jc...@di...>]

hang happens during test of 2 different CPAN modules,
on 2 different x86 linux boxes (both running 5.8.2), but not with 5.9.0

It also hangs on 5.6.2, doing a cpan> install Module::Build,
at make test.  What follows is from a couple
of days ago, I shelved til I could pursue it further, but its 4th down,
I need to punt to you all, and play defense.   Ill try some more to make
this report more conclusive.


heres 2 runs, 1st with 5.9.0, which behaves well,
2nd with 5.8.2, which hangs



[jimc@harpo Array-Compare-1.09]$ perl5.9.0 Makefile.PL
/usr/local/bin/perl5.9.0 Build.PL
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Array-Compare' version '1.09'

[jimc@harpo Array-Compare-1.09]$ make    
/usr/local/bin/perl5.9.0 Build

[jimc@harpo Array-Compare-1.09]$ make test
/usr/local/bin/perl5.9.0 Build test
t/pod.....ok                                                                 

t/test....ok                                                                 

All tests successful.
Files=2, Tests=25,  1 wallclock secs ( 1.45 cusr +  0.05 csys =  1.50 CPU)



[jimc@harpo Array-Compare-1.09]$ perl Makefile.PL
/usr/local/bin/perl Build.PL
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Array-Compare' version '1.09'
[jimc@harpo Array-Compare-1.09]$ make
/usr/local/bin/perl Build
[jimc@harpo Array-Compare-1.09]$ make test
/usr/local/bin/perl Build test
t/pod.....make: *** [test] Interrupt


both perls are using same MB installation, ie both 5.8.1;

[jimc@harpo Array-Compare-1.09]$ perldoc -l Module::Build
/usr/local/lib/perl5/site_perl/5.8.1/Module/Build.pm
[jimc@harpo Array-Compare-1.09]$ perldoc5.9.0 -l Module::Build
/usr/local/lib/perl5/site_perl/5.8.1/Module/Build.pm

both perls are 'cpan> r'  up to date.




heres a -d probe (with edits for clarity).
the breakpoint I set seems to be the last place where I
It doesnt show me a lot, but hopefully its more meaningful to some/one 
of you.

[jimc@harpo Array-Compare-1.09]$ perl -d Build test

  DB<1> b Test::Harness::Straps::_analyze_iterator
  DB<1> c
t/test....Test::Harness::Straps::_analyze_iterator(/usr/local/lib/perl5/5.8.2/Test/Harness/Straps.pm:121):
121:        my($self, $name, $it) = @_;
  DB<1> T
@ = Test::Harness::Straps::_analyze_iterator(ref(Test::Harness::Straps), 
't/test.t', ref(Test::Harness::Iterator::FH)) called from file 
`/usr/local/lib/perl5/5.8.2/Test/Harness/Straps.pm' line 238
@ = Test::Harness::Straps::analyze_fh(ref(Test::Harness::Straps), 
't/test.t', ref(GLOB)) called from file 
`/usr/local/lib/perl5/5.8.2/Test/Harness/Straps.pm' line 274
@ = Test::Harness::Straps::analyze_file(ref(Test::Harness::Straps), 
't/test.t') called from file 
`/usr/local/lib/perl5/5.8.2/Test/Harness.pm' line 471
@ = Test::Harness::_run_all_tests('t/test.t') called from file 
`/usr/local/lib/perl5/5.8.2/Test/Harness.pm' line 351
. = Test::Harness::runtests('t/test.t') called from file 
`/usr/local/lib/perl5/site_perl/5.8.1/Module/Build/Base.pm' line 1030
. = Module::Build::Base::ACTION_test(ref(Module::Build)) called from 
file `/usr/local/lib/perl5/site_perl/5.8.1/Module/Build/Base.pm' line 839
. = Module::Build::Base::_call_action(ref(Module::Build), 'test') called 
from file `/usr/local/lib/perl5/site_perl/5.8.1/Module/Build/Base.pm' 
line 830
. = Module::Build::Base::dispatch(ref(Module::Build)) called from file 
`Build' line 39
  DB<1> L
/usr/local/lib/perl5/5.8.2/Test/Harness/Straps.pm:
 121:        my($self, $name, $it) = @_;
   break if (1)
  DB<1>
  DB<1> Unrecognized character \x03 at  line 8.


The last line indicates some of the problems Im having controlling the 
debugger,
but I have no insight whether this is a cause or effect.

Once I got the prompt back, I was (for 1st time) able to 'n' thru  
run_all_tests(),
but with 'dubious' results.

  DB<1>
t/test....dubious                                                            

    Test returned status 255 (wstat 65280, 0xff00)
Test::Harness::_run_all_tests(/usr/local/lib/perl5/5.8.2/Test/Harness.pm:533):
533:                    $failedtests{$tfile}{name} = $tfile;
  DB<1>

... more 'nexts'....

FAILED--1 test script could be run, alas--no output ever seen


Another  Try

  DB<1> R
main::(Build:27):    if (-e 'Build.PL' and not 
Module::Build->up_to_date("Build.PL", $0)) {
  DB<1> c
t/test....Test::Harness::Straps::_analyze_iterator(/usr/local/lib/perl5/5.8.2/Test/Harness/Straps.pm:121):
121:        my($self, $name, $it) = @_;
  DB<1> c

it 'hangs' here again, I ^C to get out.

Test::Harness::Straps::_analyze_iterator(/usr/local/lib/perl5/5.8.2/Test/Harness/Straps.pm:144):
144:        $totals{skip_all} = $self->{skip_all} if defined 
$self->{skip_all};
  DB<1> c
t/test....dubious                                                            

    Test returned status 0 (wstat 2, 0x2)
FAILED--1 test script could be run, alas--no output ever seen
    Test::Harness::_show_results('HASH(0x8665758)','HASH(0x866571c)') 
called at /usr/local/lib/perl5/5.8.2/Test/Harness.pm line 352
    Test::Harness::runtests('t/test.t') called at 
/usr/local/lib/perl5/site_perl/5.8.1/Module/Build/Base.pm line 1030
    Module::Build::Base::ACTION_test('Module::Build=HASH(0x87abf7c)') 
called at /usr/local/lib/perl5/site_perl/5.8.1/Module/Build/Base.pm line 839
    
Module::Build::Base::_call_action('Module::Build=HASH(0x87abf7c)','test') 
called at /usr/local/lib/perl5/site_perl/5.8.1/Module/Build/Base.pm line 830
    Module::Build::Base::dispatch('Module::Build=HASH(0x87abf7c)') 
called at Build line 39

[Module::Build] [Fwd: Re: [PATCH] MakeMaker, XS and C++]

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

Forwarded from perl5-porters.

-------- Original Message --------
Subject: Re: [PATCH] MakeMaker, XS and C++
Date: Thu, 27 Nov 2003 02:04:56 -0800 (PST)
From: Salvador "Fandiño" <sfa...@ya...>
To: Michael G Schwern <sc...@po...>
CC: per...@pe..., Nick Ing-Simmons 
<nic...@el...>,  mak...@pe...


--- Michael G Schwern <sc...@po...> wrote:
> On Wed, Nov 26, 2003 at 07:40:57PM +0000, Salvador Fandiño wrote:
> > A new version of the "C++ support for MakeMaker" patch is ready.
> 
> The more I think about this the more nervous I get at putting all
> this new functionality into MakeMaker in a part that's not very
> well understood
> (XS module building) while I'm trying to wind down development.
> 
> Sorry to ask this so late in the process, but is there a good
> reason this  couldn't be done with Module::Build instead?
> And "because lots of people use MakeMaker" isn't one of them.

well, Module::Build biggest strength is that it´s a pure Perl module
that doesn't depend on an external tool like make but for C/C++
modules you will need a development environment anyway and using make
is not a problem at all.

Actually, most C/C++ developers should feel more comfortable using
and customizing ExtUtils::MakeMaker/make than Module::Build and not
because EU::MM has been there forever and M::B is new but because
they can look at the generated Makefile and understand it. For
example, I have a SWIG based module that builds with EU::MM and that
has a simple make rule to generate the .c file from a .i SWIG file.
Could I have done the same which M::B easily? I doubt it, I would
have to understand M::B internals, for EU::MM I only need to know how
to add a rule to the generated Makefile.

Bye,

   - Salva.

[Module::Build] Re: ExtUtils::MakeMaker or Module::Build

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

On Thursday, November 20, 2003, at 07:00  AM, Orton, Yves wrote:
> Frankly until Module::Build works seamlessly by default with plain old 
> CPAN
> I would advance the opinion that it will never replace MakeMaker, and
> potentially in the long run leave the community divided, with those of 
> us
> who can using Module::Build and those of us who cant or need to ensure
> backwards compatibility not.  I personally dont think that the 
> balkanization
> of CPAN is a fair price for the changes that Module::Build brings.


Well, consider that Module::Build has become backward-compatible into 
areas that MakeMaker has never been able to penetrate at all.  MacPerl 
on Mac OS (not OS X), for example.

And because it doesn't have to know obscure facts about operating 
systems that its authors don't even have access to, a single version of 
Module::Build can work on perls from 5.005 up to 5.8.2.


>
> Now if a concerted effort was made to ensure that Module::Build easily
> installed everywhere (as seen with the prerequisites and Win32 build 
> failure
> it does not) and that _every_ distribution produced by Module::Build 
> was
> installable via CPAN.pm then I would feel much more confident about its
> future.

The former is a good goal.  As for the latter, that's really up to the 
author of the distributions, they get to decide how their distributions 
should be installed.  I agree that Module::Build should try to help as 
much as it can, though.

  -Ken

Re: [Module::Build] Is "recommends" friendly enough?

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

Yeah, you're absolutely right - this is actually a documented bug, at
   http://rt.cpan.org/NoAuth/Bug.html?id=2305

I'm working on a little fix to make this better now.

  -Ken


On Saturday, November 1, 2003, at 07:30  AM, Sagar Shah wrote:

> Hi,
>
> First of all thank you for producing Module::Build. Even at this stage
> of development, it is excellent.
>
> I like the idea of the recommends method, as i often have optional
> dependencies for my modules (mainly things that are dependencies of
> specific tests which get skipped when the module isn't there).
>
> I had a quick play with it, and what i'm not sure is whether it's
> friendly enough to the user.
>
> If i have an uninstalled module 'Sagar::Great' => 1, in requires iget
> the following output:
>
> ERROR: Sagar::Great: Prerequisite Sagar::Great isn't installed
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the
> versions
>  of the modules indicated above before proceeding with this
> installation.
>
> Which sounds fairly reasonable. Now if i have an uninstalled module:
> 'Sagar::SICRAP' => 3, i get:
>
> WARNING: Sagar::Great: Prerequisite Sagar::Great isn't installed
> ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the
> versions
>  of the modules indicated above before proceeding with this
> installation.
>
>
> My concern is that the 'ERRORS/WARNINGS FOUND..." message is a bit too
> harsh/unfriendly when all that the user is missing is a recommended
> module. It puts me off using the recommends feature.
>
> What do others think?
>
> Perhaps something more akin to :
>
> WARNING: Sagar::Great: Optional Sagar::Great isn't installed
> You may wish to install the recommended versions of the modules
> indicated above before proceeding with this installation.
>
> Or perhaps i'm just too nice to my users ;-)
>
> S.
>
>
> -- 
> Sagar Shah <sag...@so...>
> <signature.asc>

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

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

Ken Williams wrote:

> Hi Ron,
>
> Whose message are you quoting here?  I don't see it in my mailbox, so 
> I can't tell what the actual issues are that somebody's complaining 
> about.
>
>  -Ken

This thread began on the module-authors list as did the thread "How to 
indicate a dependency in my module".

>
> On Sunday, November 23, 2003, at 05:17  PM, Ron Savage wrote:
>
>> Hi Folks
>>
>>> So by switching to Build.PL we dont actually gain anything but
>>> complexity and balkanization.
>>
>>
>> Also, I hope no-one's lost sight of the fact that some of us use
>> home-grown CGI scripts to install modules, and don't want manually
>> intervention during the installation process. I mention this just in
>> case it happens to be relevant.
>>
>>> I feel obliged to repeat what I said earlier. I think the
>>> Module::Build project and the CPANPLUS project are Good Things. I
>>> think that some of the implementation decisions are not such Good
>>> Things, and I worry that the impact of them over the long haul will
>>> be negative for both CPAN and for Module::Build.  Only time will
>>> tell if im right.
>>
>>
>> I second that.
>

Re: [Module::Build] create_readme =>1 doesn't cause README to be added to MANIFEST

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

On Saturday, November 1, 2003, at 07:54  AM, Sagar Shah wrote:

> Hi,
>
> I found the create_readme feature by searching the mailing lists ( i 
> was
> just about to submit an enhancement for it)
>
> I don't see it in the docs of Module::Build 0.21, but i do see it in 
> the
> code. Since the original mail trail was back in september i decided to
> assume it was complete and gave it a go.

Thanks, I've just added some docs for it.


>
> One problem that i've found is that when generating the MANIFEST
> Module::Build doesn't add the README to it, and so it doesn't actually
> get includede in the dist tarball...
>
> Bug?

I'm reluctant to add things automatically to the MANIFEST, because in 
general I don't want to surprise the user about things.  With the 
SIGNATURE file there's a chicken-egg problem that can only be solved by 
adding it to the MANIFEST automatically, but with the README I think 
the author should just add it him/herself.

  -Ken

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

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

Hi Ron,

Whose message are you quoting here?  I don't see it in my mailbox, so I 
can't tell what the actual issues are that somebody's complaining about.

  -Ken


On Sunday, November 23, 2003, at 05:17  PM, Ron Savage wrote:

> Hi Folks
>
>> So by switching to Build.PL we dont actually gain anything but
>> complexity and balkanization.
>
> Also, I hope no-one's lost sight of the fact that some of us use
> home-grown CGI scripts to install modules, and don't want manually
> intervention during the installation process. I mention this just in
> case it happens to be relevant.
>
>> I feel obliged to repeat what I said earlier. I think the
>> Module::Build project and the CPANPLUS project are Good Things. I
>> think that some of the implementation decisions are not such Good
>> Things, and I worry that the impact of them over the long haul will
>> be negative for both CPAN and for Module::Build.  Only time will
>> tell if im right.
>
> I second that.

Re: [Module::Build] Problem building XS modules on AIX

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

On Tuesday, November 18, 2003, at 08:08  PM, Randy W. Sims wrote:
> +sub prelink_c {
> +  my ($self, $to, $file_base) = @_;
> +  my ($p, $args) = ($self->{properties}, $self->{args});
> +
> +  return unless grep $^O, qw(aix MacOS MSWin32 os2 VMS);
> +

I think you meant

    return unless grep {$^O eq $_} qw(aix MacOS MSWin32 os2 VMS);

But I'm going to change it to add a need_prelink_c() method, default 0 
in the base class and overridden as needed.


> +  $file_base =~ tr/"//d; # remove any quotes
> +  my $basename = File::Basename::basename($file_base);
> +
> +  print "ExtUtils::Mksymlists::Mksymlists('$file_base')\n";
> +
> +  require ExtUtils::Mksymlists;
> +  ExtUtils::Mksymlists::Mksymlists( # dl. abbrev for dynamic library
> +    NAME     => $args->{dl_name}      || $p->{module_name},
> +    DLBASE   => $args->{dl_base}      || $basename,
> +    DL_VARS  => $args->{dl_vars}      || [],
> +    DL_FUNCS => $args->{dl_funcs}     || {},
> +    FUNCLIST => $args->{dl_func_list} || [],
> +    IMPORTS  => $args->{dl_imports}   || {},
> +    FILE     => $file_base,
> +  );

Seems like a lot of parameters, and the parameter space is getting a 
bit crowded, but I don't feel like devising anything better right now 
either.

> +sub link_c {
> +  my ($self, $to, $file_base) = @_;
> +  my $cf = $self->{config};
> +
> +  $file_base =~ tr/"//d; # remove any quotes
> +  my $perl_inc = File::Spec->catdir($cf->{archlibexp}, 'CORE'); 
> #location of perl.exp
> +
> +  my $lddlflags = $cf->{lddlflags};
> +  $lddlflags =~ s/\Q$(BASEEXT)\E/$file_base/;
> +  $lddlflags =~ s/\Q$(PERL_INC)\E/$perl_inc/;

I actually got sent a bunch of patches for AIX linking fixes, I should 
make sure they all basically do the same thing before releasing.

Thanks for the help once again.

  -Ken

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

More specifically it doesn't work for my particular AIX
NFS implementation, which is admittedly pretty poorly done.

Given that this works just fine for most of the modules I
tried and only fails for M::B's XSTest subdirectory, I'd say that
the benefits outweigh the downside.

-----Original Message-----
From: Randy W. Sims [mailto:Ra...@Th...]=20
Sent: Friday, November 28, 2003 11:34 AM
To: Ken Williams
Cc: James.FitzGibbon; mod...@li...
Subject: Re: [Module::Build] Problem building XS modules on AIX


Ken Williams wrote:

>
>  On Wednesday, November 19, 2003, at 04:48 PM, James.FitzGibbon
>  wrote:
>
> > So, this may not be the fault of the patch but instead bad=20
> > assumptions on the part of the test. On the other hand, this same=20
> > test passed with the second revision of the patch (the current one=20
> > being #3 I believe).
> >
> > It may also be related to me running the test on an NFS mounted=20
> > homedir. I tried it on a local disk and it passed. So, I'm willing=20
> > to write off the failures to the assumptions of the test suite and=20
> > say it's a good candidate for then next release unless someone has=20
> > an OS/2 or VMS box to pound on it with.
> >
> > Thanks to everyone who helped.
>
>
>  Did this thread result in a patch for M::B?
>
>  -Ken

No, the previous patch was the best I could do=20
<http://sourceforge.net/mailarchive/message.php?msg_id=3D6567348>, as I=20
know nothing of NFS. The reason that this test passed for James at one=20
point was because an initial version of the patch got the arguments to=20
add_to_cleanup() wrong by not including any directories. When this was=20
fixed it created a problem that is, I believe, directly linked with=20
M::B's cleanup versus NFS. I.E. AIX is fully supported with the above=20
patch, but NFS in general is not and remains an open issue.

Randy.

Re: [Module::Build] have_c_compiler uncovers Windoze bug

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

On Saturday, November 22, 2003, at 04:15  AM, Randy W. Sims wrote:
>
> We talked before about two sub-projects we both agreed would be good 
> for Module::Build: 1) a compiler framework, and 2) a plugin framework. 
> My current thinking is that both of these are part of the solution to 
> this problem.
>
> I think that the compiler framework should provide a low level 
> interface for invoking the compiler/linker/etc in a unified manner. In 
> other words it would define a standard set of options which it would 
> then translate to the proper options to the underlying tool. This low 
> level interface would rarely be used except by Module::Build itself.

Yes, but it should probably be a separate CPAN project with an 
interface well-defined enough that whoever wants to use it could use 
it.  Most likely its development directions would be largely be 
motivated by Module::Build's needs though, for at least the near future.

  -Ken

Re: [Module::Build] Problem building XS modules on AIX

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

Ken Williams wrote:

>
>  On Wednesday, November 19, 2003, at 04:48 PM, James.FitzGibbon
>  wrote:
>
> > So, this may not be the fault of the patch but instead bad
> > assumptions on the part of the test. On the other hand, this same
> > test passed with the second revision of the patch (the current one
> > being #3 I believe).
> >
> > It may also be related to me running the test on an NFS mounted
> > homedir. I tried it on a local disk and it passed. So, I'm willing
> > to write off the failures to the assumptions of the test suite and
> > say it's a good candidate for then next release unless someone has
> > an OS/2 or VMS box to pound on it with.
> >
> > Thanks to everyone who helped.
>
>
>  Did this thread result in a patch for M::B?
>
>  -Ken

No, the previous patch was the best I could do 
<http://sourceforge.net/mailarchive/message.php?msg_id=6567348>, as I 
know nothing of NFS. The reason that this test passed for James at one 
point was because an initial version of the patch got the arguments to 
add_to_cleanup() wrong by not including any directories. When this was 
fixed it created a problem that is, I believe, directly linked with 
M::B's cleanup versus NFS. I.E. AIX is fully supported with the above 
patch, but NFS in general is not and remains an open issue.

Randy.

Re: [Module::Build] Data::FormValidator + Module::Build : local prefix install fails under linux

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

I think the first patch I'll make for this issue is below.  It's too
confusing for the Makefile.PL to accept a PREFIX parameter but not  
respect it.
This will just make it die when it encounters PREFIX.



===================================================================
RCS file:  
/cvsroot/module-build/Module-Build/lib/Module/Build/Compat.pm,v
retrieving revision 1.31
diff -u -r1.31 Compat.pm
--- lib/Module/Build/Compat.pm	7 Sep 2003 23:05:07 -0000	1.31
+++ lib/Module/Build/Compat.pm	28 Nov 2003 17:24:52 -0000
@@ -13,7 +13,9 @@
     VERBINST     => 'verbose',
     INC     => sub { map "extra_compiler_flags=-I$_",  
Module::Build->split_like_shell(shift) },
     POLLUTE => sub { 'extra_compiler_flags=-DPERL_POLLUTE' },
-   INSTALLDIRS => sub {local $_ = shift; 'installdirs=' . (/^perl$/ ?  
'core' : $_) }
+   INSTALLDIRS => sub {local $_ = shift; 'installdirs=' . (/^perl$/ ?  
'core' : $_) },
+   PREFIX => sub {die "Sorry, PREFIX is not supported.  See the  
Module::Build\n".
+		      "documentation for 'destdir' or 'install_base' instead.\n"},
    );

  sub create_makefile_pl {
===================================================================




On Monday, November 17, 2003, at 07:12  PM, Terrence Brannon wrote:

> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : perl  
> Makefile.PL PR\
> EFIX=$PREFIX
> /usr/bin/perl Build.PL config=prefix=/home/princepawn/install
> Deleting _build
> Creating custom builder _build/lib/Data/FormValidator/Builder.pm in  
> _build/lib/\
> Data/FormValidator
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Data-FormValidator' version '3.14'
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : echo  
> $PREFIX
> /home/princepawn/install
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : make  
> install
> /usr/bin/perl Build install
> Warning: You do not have permissions to install into  
> /usr/local/share/perl/5.8.\
> 0 at /usr/share/perl/5.8.0/ExtUtils/Install.pm line 114.
> mkdir /usr/local/share/perl/5.8.0/Data: Permission denied at  
> /usr/share/perl/5.\
> 8.0/ExtUtils/Install.pm line 176
> make: *** [install] Error 255
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : uname -a
> Linux perlmonk.org 2.4.18 #12 Fri Sep 13 17:49:41 EDT 2002 i686  
> GNU/Linux
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 :
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/ 
> g22lp.tmpl
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module::Build] Problem building XS modules on AIX

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

On Wednesday, November 19, 2003, at 04:48  PM, James.FitzGibbon wrote:
> So, this may not be the fault of the patch but instead bad assumptions
> on the part of the test.  On the other hand, this same test passed 
> with the
> second revision of the patch (the current one being #3 I believe).
>
> It may also be related to me running the test on an NFS mounted 
> homedir.
> I tried it on a local disk and it passed.  So, I'm willing to write off
> the failures to the assumptions of the test suite and say it's a good
> candidate for then next release unless someone has an OS/2 or VMS box
> to pound on it with.
>
> Thanks to everyone who helped.

Did this thread result in a patch for M::B?

  -Ken

[Module::Build] Back

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

Hi all,

I'm back from a GREAT honeymoon, and I'm going through my various 
inboxes today now that I have a day off work.  If I miss some M::B 
issue that you care about, please let me know.

  -Ken

Re: [Module::Build] MBC possible missing dependency

[Jim C. <jc...@di...>]

Randy W. Sims wrote:

> On 11/25/2003 2:45 PM, Jim Cromie wrote:
>
>> from 3,4 I infer that  perl Makefile.PL doesnt automatically 
>> invalidate blib
>> by Makefile being newer than blib.
>>
>> while that might be a feature (of really knowing nothing changed), it 
>> could also
>> be a mising dependency.
>
>
> AFAICT, this is the correct behaviour. There is no dependence on the 
> produced 'Makefile' since it will never, ever, under any condition, 
> change. It's a simple pass-thru makefile with no variables or anything 
> else that could change from one run to another. But do note that if 
> you touch anything in lib, it will correctly be copied to blib.


AHH - Duh - youre absolutely right.

>>
>> This could be an " Ouch!,  Well - dont do that " problem,
>> but I thought it worth flagging.
>
>
> The arguments you pass in get stored in '_build/build_params' and not 
> in the 'Makefile'. Again, 'Makefile' never changes, so it does not 
> need to be listed in the dependencies.
>
> I don't see how any problems could arise here. Have you run in to any 
> problems related to this behaviour?


only problem is that Ive gotten into the habit of letting 'make test' do 
the make for me.
this works with perl builds, and with Makefile based CPAN modules.

So reframing things, there seems to be a missing dependency in Build 
when testing things
that havent been, um 'built' isnt quite the right word here..

Build test can proceed w/o Build ''    I'll (later) try and see if I can 
concoct a real failing
use-case for this.

thx.

>
>> tia,
>> jimc
>
>
> Regards,
> Randy.
>
> .
>

Re: [Module::Build] MBC possible missing dependency

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

On 11/25/2003 2:45 PM, Jim Cromie wrote:
> MBers,
> 
> it appears that  Module::Build::Compat  'make test' skips 'make'
> in some circumstances.
> 
> 
> 1. make clean, make  is OK - lib -> blib happens
> 
> [jimc@harpo Array-Compare-1.09]$ make clean
> /usr/local/bin/perl Build clean
> Deleting blib
> [jimc@harpo Array-Compare-1.09]$ make
> /usr/local/bin/perl Build
> lib/Array/Compare.pm -> blib/lib/Array/Compare.pm
> Manifying blib/lib/Array/Compare.pm -> blib/libdoc/Array::Compare.3
> 
> 2. make clean, make test - OK - lib -> blib happens
> 
> [jimc@harpo Array-Compare-1.09]$ make clean
> /usr/local/bin/perl Build clean
> Deleting blib
> [jimc@harpo Array-Compare-1.09]$ make test
> /usr/local/bin/perl Build test
> lib/Array/Compare.pm -> blib/lib/Array/Compare.pm
> t/pod.....make: *** [test] Interrupt
> 
> 3. perl Makefile.PL, make test NOT OK  lib -> blib SKIPPED
> 
> [jimc@harpo Array-Compare-1.09]$ perl Makefile.PL
> /usr/local/bin/perl Build.PL
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Array-Compare' version '1.09'
> [jimc@harpo Array-Compare-1.09]$ make test
> /usr/local/bin/perl Build test
> t/pod.....make: *** [test] Interrupt
 >
> 4. make clean, perl Makefile.PL, make test OK -
> 
> [jimc@harpo Array-Compare-1.09]$ make clean
> /usr/local/bin/perl Build clean
> Deleting blib
> [jimc@harpo Array-Compare-1.09]$ perl Makefile.PL
> /usr/local/bin/perl Build.PL
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Array-Compare' version '1.09'
> [jimc@harpo Array-Compare-1.09]$ make test
> /usr/local/bin/perl Build test
> lib/Array/Compare.pm -> blib/lib/Array/Compare.pm
> t/pod.....
> 
> 
> from 3,4 I infer that  perl Makefile.PL doesnt automatically invalidate 
> blib
> by Makefile being newer than blib.
> 
> while that might be a feature (of really knowing nothing changed), it 
> could also
> be a mising dependency.

AFAICT, this is the correct behaviour. There is no dependence on the 
produced 'Makefile' since it will never, ever, under any condition, 
change. It's a simple pass-thru makefile with no variables or anything 
else that could change from one run to another. But do note that if you 
touch anything in lib, it will correctly be copied to blib.

> 5. I change Makefile inside by giving it a new prefix.
> no lib->blib rebuild.
> This still might be ok, IFF MB is really smart, and knows that a diffferent
> install location doesnt need a re-make.
t>
> [jimc@harpo Array-Compare-1.09]$ perl Makefile.PL PREFIX=~
> /usr/local/bin/perl Build.PL config=prefix=/home/jimc
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Array-Compare' version '1.09'
> [jimc@harpo Array-Compare-1.09]$ make
> /usr/local/bin/perl Build
> [jimc@harpo Array-Compare-1.09]$
> 
> 6. same as above, but with perl Makefile.PL distdir=~
> 
> 
> This could be an " Ouch!,  Well - dont do that " problem,
> but I thought it worth flagging.

The arguments you pass in get stored in '_build/build_params' and not in 
the 'Makefile'. Again, 'Makefile' never changes, so it does not need to 
be listed in the dependencies.

I don't see how any problems could arise here. Have you run in to any 
problems related to this behaviour?

> tia,
> jimc

Regards,
Randy.

[Module::Build] MBC possible missing dependency

[Jim C. <jc...@di...>]

MBers,

it appears that  Module::Build::Compat  'make test' skips 'make'
in some circumstances.


1. make clean, make  is OK - lib -> blib happens

[jimc@harpo Array-Compare-1.09]$ make clean
/usr/local/bin/perl Build clean
Deleting blib
[jimc@harpo Array-Compare-1.09]$ make
/usr/local/bin/perl Build
lib/Array/Compare.pm -> blib/lib/Array/Compare.pm
Manifying blib/lib/Array/Compare.pm -> blib/libdoc/Array::Compare.3

2. make clean, make test - OK - lib -> blib happens

[jimc@harpo Array-Compare-1.09]$ make clean
/usr/local/bin/perl Build clean
Deleting blib
[jimc@harpo Array-Compare-1.09]$ make test
/usr/local/bin/perl Build test
lib/Array/Compare.pm -> blib/lib/Array/Compare.pm
t/pod.....make: *** [test] Interrupt

3. perl Makefile.PL, make test NOT OK  lib -> blib SKIPPED

[jimc@harpo Array-Compare-1.09]$ perl Makefile.PL
/usr/local/bin/perl Build.PL
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Array-Compare' version '1.09'
[jimc@harpo Array-Compare-1.09]$ make test
/usr/local/bin/perl Build test
t/pod.....make: *** [test] Interrupt

4. make clean, perl Makefile.PL, make test OK -

[jimc@harpo Array-Compare-1.09]$ make clean
/usr/local/bin/perl Build clean
Deleting blib
[jimc@harpo Array-Compare-1.09]$ perl Makefile.PL
/usr/local/bin/perl Build.PL
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Array-Compare' version '1.09'
[jimc@harpo Array-Compare-1.09]$ make test
/usr/local/bin/perl Build test
lib/Array/Compare.pm -> blib/lib/Array/Compare.pm
t/pod.....


from 3,4 I infer that  perl Makefile.PL doesnt automatically invalidate blib
by Makefile being newer than blib.

while that might be a feature (of really knowing nothing changed), it 
could also
be a mising dependency.

5. I change Makefile inside by giving it a new prefix.
no lib->blib rebuild.
This still might be ok, IFF MB is really smart, and knows that a diffferent
install location doesnt need a re-make.

[jimc@harpo Array-Compare-1.09]$ perl Makefile.PL PREFIX=~
/usr/local/bin/perl Build.PL config=prefix=/home/jimc
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Array-Compare' version '1.09'
[jimc@harpo Array-Compare-1.09]$ make
/usr/local/bin/perl Build
[jimc@harpo Array-Compare-1.09]$

6. same as above, but with perl Makefile.PL distdir=~


This could be an " Ouch!,  Well - dont do that " problem,
but I thought it worth flagging.

tia,
jimc

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Norbert G. <no...@MP...>]

On Mon, Nov 24 2003, Dave Rolsky wrote:
> On Sun, 23 Nov 2003, Norbert Gruener wrote:
> 
> > On Thu, Nov 20 2003, Dave Rolsky wrote:
> > >
> > > I wrote a patch for CPAN.pm to add support for Module::Build.
> >
> > is this patch available somewhere ?   I would like to patch CPAN at
> > our installation.  I have already applied your patch for
> > EU::ModuleMaker and I would like to do the same with CPAN.
> 
> The latest version is attached.  I think this was against CPAN 1.76.  BTW,

Thank you for your patch.

> EU::ModuleMaker's latest release includes my patch, so you might as well
> install it.

Thank you also for that hint  :-)   I will upgrade ASAP.

Norbert
-- 
Ceterum censeo          | PGP encrypted mail preferred.
Redmond esse delendam.  | PGP Key at www.MPA-Garching.MPG.de/~nog/

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

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

On Thu, Nov 20, 2003 at 04:34:42PM -0000, Orton, Yves wrote:
> Lets consider the situation as we have it from the POV of a CPAN.pm user
> without your patches (like me and the vast majority of production perl
> instances out there).
> 
> 1. CPAN downloads the dist unpacks it and either
>   A. Finds no Makefile.PL, and crashes directly.
>   B. Finds a Makefile.PL which is simply a passthrough to Module::Build and
> Build.PL.
>     i) CPAN passes special options to the Makefile.PL
>     ii) where Module::Build either ignores them or dies with an error.

Ah HA!  I see the problem.

M::B's Makefile.PL *does* honor a healthy chunk of Makefile.PL options.
Including PREFIX.  It might behave a little differently, but that's the
best that can be done without someone doing a lot of work to emulate
MM's fairly crazy prefixification logic.

[/usr/local/src/CPAN/Module-Build-0.21] perl Makefile.PL PREFIX=~
perl Build.PL config=prefix=/Users/schwern
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'Module-Build' version '0.21'


> In what way is the superior to 
> 
> 1. CPAN downloads the dist, unpacks it and
> 2. Runs Makefile.PL with some set of special options
> 3. Makefile.PL uses Module::Build and either ignores them or dies with an
> error.

This is exactly what it does.  If that's not working for you I guess its
just a bug.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
It's Airplane Glue sniffing time!

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

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

On Thu, Nov 20, 2003 at 01:00:07PM -0000, Orton, Yves wrote:
> If you cant install modules then the fact that Module::Build and CPANPLUS
> exist isnt going to help you much. 

*head scratch* if they can't install modules then it really doesn't matter 
how modules are installed since they can't install modules.


> I think it would have caught on a LOT faster if the silly Build.PL decision
> hadnt been made. Breaking the old stuff is ok once the new stuff has
> sufficient market penetration. Breaking the old stuff from the get go just
> means youll never have the market penetration to convince people its
> worthwhile.

Except when the old stuff is Fairly Broken, Mostly Undocumented and would
be a Nightmare to reproduce.  Sort of in the same way that PONIE would
be impossible if it had to replicate all of XS.   We don't now half of
how things are used and a lot of it simply doesn't make sense in the new
module.  

Part of the point of Module::Build is to correct the historical design
mistakes of MM's interface.

Module::Build's Makefile.PL emulation handles most of the commonly used 
MakeMaker options and that's good enough for most uses.  If you've found
an edge case that causes problems, patches welcome.


> Now if a concerted effort was made to ensure that Module::Build easily
> installed everywhere (as seen with the prerequisites and Win32 build failure
> it does not) and that _every_ distribution produced by Module::Build was
> installable via CPAN.pm then I would feel much more confident about its
> future.

M::B is planned to go into 5.10, that's as fast as we can push it.  Both
from new Perl core module inclusion perspective and giving time for M::B 
to mature.

Meanwhile, its installable seperately, backwards compatible and much, much 
more easily maintained across platforms than MakeMaker.  Hell, it even works
on MacPerl.  If its got a glitch on Win32 then it just needs a little work.  
Perhaps from a Win32 developer that's interested in Module::Build.  If only 
we knew one... ;)

As for CPAN.pm, petition Andreas to include Dave's Build.PL patch.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
WOOHOO!  I'm going to Disneyland!
	http://www.goats.com/archive/980805.html

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

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

On Sun, 23 Nov 2003, Norbert Gruener wrote:

> On Thu, Nov 20 2003, Dave Rolsky wrote:
> >
> > I wrote a patch for CPAN.pm to add support for Module::Build.
>
> is this patch available somewhere ?   I would like to patch CPAN at
> our installation.  I have already applied your patch for
> EU::ModuleMaker and I would like to do the same with CPAN.

The latest version is attached.  I think this was against CPAN 1.76.  BTW,
EU::ModuleMaker's latest release includes my patch, so you might as well
install it.


-dave

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