Re: [REPATCH MANIFEST lib/ExtUtils/MM_Cygwin.t] use more 'Schwernishness';

[chromatic]

On Sunday 25 November 2001 22:31, Michael G Schwern wrote:

  Porta-paranoia.  cflags() and canonpath() are delegated to it.  This may
  be why File::Spec was commingled.

 Now wait a second, this means you're not actually testing what
 ExtUtils::MM_Cygwin-catfile() and cflags() and perl_script() do.

There exist neither ExtUtils::MM_Cygwin::catfile() or 
ExtUtils::MM_Cygwin::perl_script().  They're both inherited from somewhere, 
and are called within ExtUtils::MM_Cygwin::manifypods().

ExtUtils::MM_Cygwin::cflags() does exist, and it calls 
ExtUtils::MM_Unix::cflags().

My assumption (which may very well be invalid) is that anything that breaks 
ExtUtils::MM_Unix should be caught by the ExtUtils::MM_Unix test.  The 
ExtUtils::MM_Cygwin test is predicated upon the assumption that the bits in 
ExtUtils::MM_Unix Just Work.  As such, I considered them fair game to be 
replaced with decaf crystals.

I may very well be wrong on this, but I think it's testing the essentials.

-- c

Re: [REPATCH MANIFEST lib/ExtUtils/MM_Cygwin.t] use more 'Schwernishness';

[Michael G Schwern]

On Sun, Nov 25, 2001 at 10:31:15PM -0700, chromatic wrote:
 On Sunday 25 November 2001 22:31, Michael G Schwern wrote:
 
   Porta-paranoia.  cflags() and canonpath() are delegated to it.  This may
   be why File::Spec was commingled.
 
  Now wait a second, this means you're not actually testing what
  ExtUtils::MM_Cygwin-catfile() and cflags() and perl_script() do.
 
 There exist neither ExtUtils::MM_Cygwin::catfile() or 
 ExtUtils::MM_Cygwin::perl_script().  They're both inherited from somewhere, 
 and are called within ExtUtils::MM_Cygwin::manifypods().

They should be inherited from ExtUtils::MM_Unix.

Inheritance within the MM_* modules is a little confused.  Actually
it's a lot confused.  ExtUtils::MakeMaker and all the MM_* modules are
all tangled up in each other.  This is something I want to pull apart
after there are some tests.

It basically goes like this:

ExtUtils::MakeMaker sets up the MM class:

@MM::ISA = qw[ExtUtils::MM_Unix ExtUtils::Liblist::Kid 
  ExtUtils::MakeMaker];

It then looks at $^O and requires the appropriate ExtUtils::MM_*
class.  In this case, ExtUtils::MM_Cygwin.  MM_Cygwin then makes it's
own addition to @MM::ISA...

unshift @MM::ISA, 'ExtUtils::MM_Cygwin';

Leaving you with a fine example of multiple inheritance abuse:

@MM::ISA = qw[ExtUtils::MM_Cygwin ExtUtils::MM_Unix 
  ExtUtils::Liblist::Kid ExtUtils::MakeMaker];

So before ExtUtils::MM_Cygwin is used, you have to set the initial
@MM::ISA that ExtUtils::MakeMaker normally does, then let
ExtUtils::MM_Cygwin add itself.  Sorry, forgot to mention that bit of
fun.  In the end, test it like this:

@MM::ISA = qw[ExtUtils::MM_Unix ExtUtils::Liblist::Kid 
  ExtUtils::MakeMaker];
use_ok('ExtUtils::MM_Cygwin');

I'll start tearing apart the way MM inheritance works shortly.


 My assumption (which may very well be invalid) is that anything that breaks 
 ExtUtils::MM_Unix should be caught by the ExtUtils::MM_Unix test.  

Right, the MM_Unix test.  I could have sworn we had one...  And the
patch to make MM_Unix use File::Spec doesn't seem to have gone in.


 The ExtUtils::MM_Cygwin test is predicated upon the assumption that
 the bits in ExtUtils::MM_Unix Just Work.  As such, I considered them
 fair game to be replaced with decaf crystals.

Is there a need to do so?  ExtUtils::MM_Unix::catfile() should work on
Cygwin else MM_Cygwin would override it.  Ditto the rest.  Do they
have weird side effects?


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance  [EMAIL PROTECTED] Kwalitee Is Job One
We have cornered the market on senselessness and have profited.