headers
Jaap Karssenberg | 15 May 2004 12:13
X-Face
Picon
Picon

Re: [Module::Build] Compat BUG

On Fri, 14 May 2004 17:44:56 -0500 Ken Williams wrote:
: Maybe if you wrote a regression test that fails, I could fix it.  I've
: 
: fixed every related problem I know about.

A test is fairly complex because it should involve multiple files; the
problem itself is simple though:
In the documentation of Module::Build you say one should use

   use lib qw(/nonstandard/library/path);

in Build.PL to include custom modules. Now in Compat.pm you use system()
to run Build.PL, which means that this "use lib" statement is only
executed in a _forked_ process. Later the process executing Makefile.PL
dies because it can't find the custom module.

The patch is simple and I first posted it to the mailing list at the
12th of april. The idea is to replace the system() in
M:B:Compat::run_build_pl() with a do(), this way everything takes place
M:in the same process, thus loading the correct nonstandard library
M:path.

This patch fixes the problems for me:
Module/Build/Compat.pm
173c173,175
<   system($^X, $in{script},  <at> args) == 0 or die "Couldn't run
$in{script}: $!";
---
>   local  <at> ARGV =  <at> args;
>   do $in{script};
(Continue reading)

Permalink | Reply |
headers
Ken Williams | 19 May 2004 03:50
Favicon

Re: [Module::Build] Compat BUG


On May 15, 2004, at 5:13 AM, Jaap Karssenberg wrote:

> On Fri, 14 May 2004 17:44:56 -0500 Ken Williams wrote:
> : Maybe if you wrote a regression test that fails, I could fix it.  
> I've
> :
> : fixed every related problem I know about.
>
> A test is fairly complex because it should involve multiple files;

More complex than the months and paragraphs of descriptions that have 
gone over the mailing list in lieu of a test?

> the problem itself is simple though:
> In the documentation of Module::Build you say one should use
>
>    use lib qw(/nonstandard/library/path);
>
> in Build.PL to include custom modules. Now in Compat.pm you use 
> system()
> to run Build.PL, which means that this "use lib" statement is only
> executed in a _forked_ process. Later the process executing Makefile.PL
> dies because it can't find the custom module.

I guess I still don't quite understand - is the Makefile.PL loading the 
module itself, or is it a pass-through Makefile.PL generated by M::B, 
or something different?

The bottom line is that we *do* need a regression test or else we're
(Continue reading)

Permalink | Reply |
headers
Jaap Karssenberg | 19 May 2004 12:42
X-Face
Picon
Picon

Re: [Module::Build] Compat BUG

On Tue, 18 May 2004 20:50:28 -0500 Ken Williams wrote:
: More complex than the months and paragraphs of descriptions that have 
: gone over the mailing list in lieu of a test?

Ok, ok , I see what I can do

: I guess I still don't quite understand - is the Makefile.PL loading
: the module itself, or is it a pass-through Makefile.PL generated by
: M::B, 
: or something different?

Makefile.PL is the passthrough version generated by M:B

Now the problem is this: if I use "use lib './b'" in Build.PL, how the
will './b' get in the  <at> INC that is used by M:B:Compat (which is called
from Makefile.PL) to make a new object of my custom class ??
Each process has it's own  <at> INC, is that see difficult to visualise ?

But like I said, standardise the name of the included directory and be
done with it !

: The bottom line is that we *do* need a regression test or else we're 
: all going to be frustrated trying to characterize, find, & fix this.

--

-- 
   )   (     Jaap Karssenberg || Pardus [Larus]                | |0| |
   :   :     http://pardus-larus.student.utwente.nl/~pardus    | | |0|
 )  \ /  (                                                     |0|0|0|
 ",.*'*.,"   Proud owner of "Perl6 Essentials" 1st edition :)  wannabe
(Continue reading)

Permalink | Reply |
headers
Ken Williams | 18 May 2004 06:07
Favicon

Re: [Module::Build] Compat BUG


On May 15, 2004, at 5:13 AM, Jaap Karssenberg wrote:
>
> The patch is simple and I first posted it to the mailing list at the
> 12th of april. The idea is to replace the system() in
> M:B:Compat::run_build_pl() with a do(), this way everything takes place
> M:in the same process, thus loading the correct nonstandard library
> M:path.
>
> This patch fixes the problems for me:
> Module/Build/Compat.pm
> 173c173,175
> <   system($^X, $in{script},  <at> args) == 0 or die "Couldn't run
> $in{script}: $!";
> ---
>>   local  <at> ARGV =  <at> args;
>>   do $in{script};
>>   die if $ <at> ;
>
> The only risk is that one might end a Build.PL with 'exit', you could
> advise against this in the documentation about subclassing.

I like the spirit of the patch, but when I apply it I get a bunch of 
failures in the regression tests.  I'm not sure why yet.

  -Ken

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
(Continue reading)

Permalink | Reply |
headers
Randy W. Sims | 18 May 2004 06:55

Re: [Module::Build] Compat BUG

Ken Williams wrote:
> 
> On May 15, 2004, at 5:13 AM, Jaap Karssenberg wrote:
> 
>>
>> The patch is simple and I first posted it to the mailing list at the
>> 12th of april. The idea is to replace the system() in
>> M:B:Compat::run_build_pl() with a do(), this way everything takes place
>> M:in the same process, thus loading the correct nonstandard library
>> M:path.
>>
>> This patch fixes the problems for me:
>> Module/Build/Compat.pm
>> 173c173,175
>> <   system($^X, $in{script},  <at> args) == 0 or die "Couldn't run
>> $in{script}: $!";
>> ---
>>
>>>   local  <at> ARGV =  <at> args;
>>>   do $in{script};
>>>   die if $ <at> ;
>>
>>
>> The only risk is that one might end a Build.PL with 'exit', you could
>> advise against this in the documentation about subclassing.
> 
> 
> I like the spirit of the patch, but when I apply it I get a bunch of 
> failures in the regression tests.  I'm not sure why yet.
(Continue reading)

Permalink | Reply |
headers
Jaap Karssenberg | 18 May 2004 11:54
X-Face
Picon
Picon

Re: [Module::Build] Compat BUG

On Tue, 18 May 2004 00:55:07 -0400 Randy W. Sims wrote:
: How about something like (untested):
: 
: my  <at> inc_args = map { "-I$_" }  <at> INC;
: system($^X,  <at> inc_args, $in{script},  <at> args) == 0 or die "...";
: 
: or the less preferable:
: 
: $ENV{PERL5LIB} = join( $Config{path_sep},  <at> INC );
: system($^X, $in{script},  <at> args) == 0 or die "...";
: 
: I think both accomplish the goal if I understand the problem?

No because this runs Build.PL with the INC from Makefile.PL - the
problem to be solved is to get an INC from Build.PL to Makefile.PL .

A simple workaround is to standardise the name of the custom directory,
or make it a config option (and read the persistent config file after
running Build.PL).

--

-- 
   )   (     Jaap Karssenberg || Pardus [Larus]                | |0| |
   :   :     http://pardus-larus.student.utwente.nl/~pardus    | | |0|
 )  \ /  (                                                     |0|0|0|
 ",.*'*.,"   Proud owner of "Perl6 Essentials" 1st edition :)  wannabe

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
(Continue reading)

Permalink | Reply |

Gmane