FastCGi on IIS... The tale of Microsoft and my new Perl Module...

[Ken Williams]

Matt S Trout wrote:
> "Anything but Module::Build".
>

It's disappointing to see a FUDdy post like this about a project so  
many people have put work into. =(  Thanks to a Minneapolis.pm member  
for pointing it out to me.


> Module::Build is a FPITA because -
>
> (1) it's neither core (on 5.8) nor self-bundling ala MI, so you  
> have no
> guarantees at all about what the user's got

Modern versions of CPAN (Jan. 2006) and CPANPLUS (Jan. 2003) both  
know how to deal with installing M::B properly for distributions that  
use it.  It thus becomes no more of a burden than any other module  
dependency.

Also it is of course a new core module in the upcoming 5.10, and  
we're working on a new self-bundling mechanism similar to (but better  
than, i.e. giving the user more control) M::I's mechanism, so it will  
be even *less* of a burden than now.

Adam Kennedy (M::I author) has also suggested creating a new  
configure_requires flag for the META.yml which would advise CPAN and  
CPANPLUS to install M::B (or whatever installer the author uses) even  
earlier in the process.  We're adopting that mechanism too.


>
> (2) it does its $VERSION etc. handling using a set of fragile regexes

We use the same approach that MakeMaker uses, could you please  
provide a realistic test case that fails under M::B but succeeds  
under MakeMaker?  I am not aware of any such cases at this point.


>
> (3) it changed the meaning on INSTALL_BASE in the last major  
> release (yes,
> that was a year ago. Unfortunately due to (1) I -still- see the  
> problem
> randomly popping up on a regular basis)

That was not a year ago, that was 2.5 years ago.  It debuted first in  
a beta release because people (like you, I presume) don't like to see  
lots of quick changes in major releases.

In any case, the whole point of install_base (which never would have  
happened if it weren't for M::B, I might add) is to guarantee a  
predictable install location.  That's not possible when using PREFIX  
(see e.g. http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.36/ 
lib/ExtUtils/MakeMaker.pm#PREFIX_and_LIB_attribute).  And the only  
reason we changed install_base 2.5 years ago was because Schwern  
wanted the paths different when he added install_base support to  
EU::MM, so we changed it so that EU::MM and M::B did things the same  
way.

If you're still seeing "the problem randomly popping up" I think that  
just means you have old versions of M::B installed.  If you'd rather  
not standardize your versions, you can use the --install_path option  
to specify exactly where you'd like things to go.  But either way the  
power is in your hands at this point.


>
> (4) it decides -at install time- what capabilities to build,  
> requiring a
> re-install of the same version to fix it later.

No, that was corrected in April of 2005.  auto_features are now  
evaluated at runtime, not install time.

  -Ken