module-build-general

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 16, 2006, at 11:38 AM, David Wheeler wrote:

> On Feb 16, 2006, at 09:27, Ken Williams wrote:
>
>> That's good.  The specific bug I know (knew?) about was that 
>> cpan-testers error reports don't include any diagnostic output when 
>> they're generated by CPANPLUS using a Build.PL - so I guess either 
>> it's fixed, or your modules never generate errors. =)
>
> Someone told me about this bug after cpanp sent them a failure report 
> from my Mac. But what "diagnostic" information is missing, exactly? 
> Maybe there are some links to what it looks like and what it should 
> look like in the cpan-testers archives?

I don't have such a link, but essentially any info sent to 
STDERR/STDOUT during testing is lost because CPANPLUS calls the 'test' 
action through the M::B API, not in a subprocess like it does for 
EU::MM, and doesn't capture those filehandle outputs.

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 16, 2006, at 09:49, Ken Williams wrote:

> I don't have such a link, but essentially any info sent to STDERR/ 
> STDOUT during testing is lost because CPANPLUS calls the 'test'  
> action through the M::B API, not in a subprocess like it does for  
> EU::MM, and doesn't capture those filehandle outputs.

Oh. That should be easy to fix with a tied or piped file handle.  
Test::Output has the code that's needed.

Best,

David

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 16, 2006, at 11:54 AM, David Wheeler wrote:

> On Feb 16, 2006, at 09:49, Ken Williams wrote:
>
>> I don't have such a link, but essentially any info sent to 
>> STDERR/STDOUT during testing is lost because CPANPLUS calls the 
>> 'test' action through the M::B API, not in a subprocess like it does 
>> for EU::MM, and doesn't capture those filehandle outputs.
>
> Oh. That should be easy to fix with a tied or piped file handle. 
> Test::Output has the code that's needed.

Agreed - it's just that until we write a failing test case and see it 
squashed I can't be completely sure that the fix is only in CP+ (and 
its CP+::Dist::Build connector) and not also in M::B.  If it's only 
over in CP+-land, great.

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 16, 2006, at 5:23 PM, demerphq wrote:

> On 2/17/06, demerphq <dem...@gm...> wrote:
>> On 2/16/06, Ken Williams <ke...@ma...> wrote:
>>>
>>> On Feb 16, 2006, at 3:46 PM, demerphq wrote:
>>>
>>>>
>>>> Id be happy to test what you did and/or to put a new patch together
>>>> against a more recent version if you would prefer that.
>>>
>>> Thanks.  I did apply it, can you see whether CVS behaves as you 
>>> expect?
>>> Ideally we'd also get some regression tests, but I'm not sure really
>>> what to be testing so I can't really write them myself.
>>
>> It seems fine. Output below. I think the attached patch should be
>> applied as it might break existing frameworks where the batch files
>> are called directly.  I was overenethusiastic there, sorry. I have no
>> idea what to do about the final warning message. Its harmless so
>> probably should just be documented as a win32 quirk somewhere. As for
>> regression tests, isn't this already existing and tested behaviour
>> pretty well?
>
> And heres the latest pathtools as installed with the EU::Install patch
> I sent out a while back.

That's good, right?  Any loose threads you see around this issue?

Where do we stand with someone releasing a new EU::Install with that 
patch incorporated?

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[demerphq <dem...@gm...>]

On 2/17/06, Ken Williams <ke...@ma...> wrote:
>
> On Feb 16, 2006, at 5:23 PM, demerphq wrote:
>
> > On 2/17/06, demerphq <dem...@gm...> wrote:
> >> On 2/16/06, Ken Williams <ke...@ma...> wrote:
> >>>
> >>> On Feb 16, 2006, at 3:46 PM, demerphq wrote:
> >>>
> >>>>
> >>>> Id be happy to test what you did and/or to put a new patch together
> >>>> against a more recent version if you would prefer that.
> >>>
> >>> Thanks.  I did apply it, can you see whether CVS behaves as you
> >>> expect?
> >>> Ideally we'd also get some regression tests, but I'm not sure really
> >>> what to be testing so I can't really write them myself.
> >>
> >> It seems fine. Output below. I think the attached patch should be
> >> applied as it might break existing frameworks where the batch files
> >> are called directly.  I was overenethusiastic there, sorry. I have no
> >> idea what to do about the final warning message. Its harmless so
> >> probably should just be documented as a win32 quirk somewhere. As for
> >> regression tests, isn't this already existing and tested behaviour
> >> pretty well?
> >
> > And heres the latest pathtools as installed with the EU::Install patch
> > I sent out a while back.
>
> That's good, right?  Any loose threads you see around this issue?

Yep. Not really.

> Where do we stand with someone releasing a new EU::Install with that
> patch incorporated?

I could upload my copy, but its Schwerns decision really as regardless
who uploads it, it wont be indexed until he does the transfer.

Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"