Moving this off p5p.

Here's the wrap up.  Its bad to have EUI so tightly integrated with MM.  Its
bad enough that they have a circular dependency, but a circular test
dependency is worse.  Most of basic.t has nothing to do with EUI.  The rest is
testing EUI through MM.  Testing one piece of software through another is
awkward.  EUI is effectively testing the MakeMaker interface to EUI.  That's
MakeMaker's job.

What I realize now is that EUI has a perfectly fine interface with which to
test itself.  There's little reason, other than not having to rewrite the
test, that it needs to test itself through MakeMaker at all.  Its not its
responsible to test its dependents.

Once that's done there's no issue nor files to keep in sync.  MakeMaker tests
its ability to install.  EUI tests its own functions and leaves MakeMaker out
of the picture.  The whole thing will be more robust.  There will be very
little overlap.

Looking at basic.pl I don't see anything its testing about EUI that isn't
being tested somewhere else, so I'd just delete it.

(As an aside, it will make coverage analysis work since Devel::Cover doesn't
see Perl code run in make subprocesses)


demerphq wrote:
> 2009/7/26 Nicholas Clark <n...@ccl4.org>:
>> On Sun, Jul 26, 2009 at 11:03:21PM +0200, demerphq wrote:
>>
>>> Schwern and I will have to sort it out amongst ourselves. And for now
>>> im going to leave basic.pl in place even tho it isnt being used,
>>> please leave it until schwern and i can negotiate a solution to this.
>> I'm not paying close attention to this (for example, I've deleted the 
>> previous
>> messages in this thread, so I can't refer back to them) but I think that
>> Schwern said that the problem may become a lot easier to resolve once
>> dual life modules are detangled from lib and moved each to their own 
>> directory
>> in ext/, with their tests run in ext/
> 
> I don't agree with that assessment. The reason is you have a test file
> that now is one third ExtUtils::Install related, and because the other
> two thirds test EUMM specific functionality it cannot go unchanged
> into an EUI package without tests failing when someone tries to
> install the latest EUI with an older EUMM.
>
> Thus, even if we do the ext/ thing it doesnt change anything, EUI will
> need to have the same tests that EUMM has for installation. If the
> files these test live in are "identical" then cross-applying patches
> is trival. If they are quite different, as they would be without
> taking the tack I did, then getting the same patch to apply to both is
> a pain (this was the origin of why I did this change).
> 
> Back when this presented itself I tried to contact Schwern, couldn't
> find him, and decided to go with what seemed to me to be the better of
> two options, which was to put some switches in the EUMM version so
> that the bits that might break in EUI would not fire when run
> appropriately, and then have the same core file in both, with a
> preloader to set things up right in each package. Schwern has rejected
> this, which I guess leaves the option of  striping out the install
> specific tests into a stand alone test file which is the duplicated in
> EUI and EUMM into a new test file, which is the duplicated in both
> packages. I personally think the latter is trickier and more
> timeconsuming than the former.
> 
> BTW you can see a diff pretty easily:
> 
>    git diff lib/ExtUtils/t/basic.pl lib/ExtUtils/t/basic.t
> 
> As you can see extracting the stuff that is EUI specific, out of the
> set up steps needed which will align with EUMM, isnt so easy, which is
> why I went with the option of selective disablement.
> 
>> Dave asked us not to do this until after 5.10.1 was released.
>> But I think it likely that work will restart rather soon after 5.10.1
> 
> Well, as I said, this is irrelevant, some kind of negotiation between
> Schwern and myself to resolve the this is necessary regardless. Which
> im sure will happen as soon as we are both in irc at the same time.
> :-)
> 
> Yves
> 
> 
> 


-- 
191. Our Humvees cannot be assembled into a giant battle-robot.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
           http://skippyslist.com/list/

Reply via email to