module-build-general

[Module::Build] UNINST=1?

[Tyler M. <ty...@yi...>]

I just tried installing a package I'm working on and got notified that I had
an older version of the package installed. I was advised to run "make
install UNINST=1" to get rid of this. That seemed odd to me, since I'm using
Module::Build, not ExtUtils::MakeMaker. But I decided to try "Build install
UNINST=1" and this is what I got: 



pipewrench:/home/faraway/dev/Apache2-AUS# ./Build install UNINST=1
Skipping /usr/local/share/perl/5.8.8/Apache2/AUS.pm (unchanged)
Skipping /usr/local/share/perl/5.8.8/Apache2/AUS/Util.pm (unchanged)
Skipping /usr/local/share/perl/5.8.8/Apache2/AUS/RequestRec.pm (unchanged)
Skipping /usr/local/man/man3/Apache2::AUS.3pm (unchanged)
Writing /usr/local/lib/perl/5.8.8/auto/Apache2/AUS/.packlist
## Differing version of Apache2/AUS.pm found. You might like to
rm /usr/local/share/perl/5.8.7/Apache2/AUS.pm
## Differing version of Apache2/AUS/Util.pm found. You might like to
rm /usr/local/share/perl/5.8.7/Apache2/AUS/Util.pm
## Running 'make install UNINST=1' will unlink all those files for you.



It turned out I had to write "uninst=1" (lower case). I think we should
either support the uppercase method, or somehow change the warning message
that is displayed. In fact, doing both might be preferable. :) The first
option is trivial ... I think the second one falls into this domain:

	http://www.makemaker.org/wiki/index.cgi?ModulesForSale

	Thanks,
		Tyler

Re: [Module::Build] UNINST=1?

[Randy W. S. <ml...@th...>]

Tyler MacDonald wrote:
> I just tried installing a package I'm working on and got notified that I had
> an older version of the package installed. I was advised to run "make
> install UNINST=1" to get rid of this. That seemed odd to me, since I'm using
> Module::Build, not ExtUtils::MakeMaker. But I decided to try "Build install
> UNINST=1" and this is what I got: 

Where you installing with CPAN.pm? If its prefer_installer config option 
is set to EUMM, it will use the Makefile.PL in preference to the 
Build.PL. Recent versions of M::B (?>=0.26) will translate more common 
options: make install UNINST=1 will be translated and passed through to 
M::B as `Build install uninst=1`

> ## Running 'make install UNINST=1' will unlink all those files for you.

This is output from ExtUtils::Install. This module is currently part of 
ExtUtils::MakeMaker, but we use it for installing modules. It still has 
some cruft that needs to be cleaned up so that it can be used by other 
tools like M::B.

> It turned out I had to write "uninst=1" (lower case). I think we should
> either support the uppercase method, or somehow change the warning message
> that is displayed. In fact, doing both might be preferable. :) The first
> option is trivial ... I think the second one falls into this domain:

The first option would set bad precedent. We'd then have people wanting 
direct translations of all MakeMakeresqe options. verbose, prefix, etc. 
I think we just need to learn to work better with existing modules 
(ExtUtils::Install) and tools (CPAN.pm, CPANPLUS).

Randy.

Re: [Module::Build] UNINST=1?

[Tyler M. <ty...@yi...>]

Randy W. Sims <ml...@th...> wrote:
> >It turned out I had to write "uninst=1" (lower case). I think we should
> >either support the uppercase method, or somehow change the warning message
> >that is displayed. In fact, doing both might be preferable. :) The first
> >option is trivial ... I think the second one falls into this domain:
> 
> The first option would set bad precedent. We'd then have people wanting 
> direct translations of all MakeMakeresqe options. verbose, prefix, etc. 

	Yeah, that's another thing I was going to mention. This subclassing
thing is great and all, but I really miss being able to just write a "sub
MY::postamble" to paste makefile snippets for me... can we get that put into
Module::Build as well?

	...

	Kidding! Seriously though, there's been quite the debate about
PREFIX and it sounds like people are working to get that into
Module::Build... I can understand Module::Build behaving differently where
it provides a technological advantage, but when there's a feature that's
supported by both MM and MB and the difference is just a matter of
commandline syntax or terminology, shouldn't we be making MB's syntax as
close as possible to MM's (or at least support MM's) to smooth the
transition?

	Cheers,
		Tyler

Re: [Module::Build] UNINST=1?

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

On Feb 21, 2006, at 11:35 AM, Tyler MacDonald wrote:

> Randy W. Sims <ml...@th...> wrote:
>>> It turned out I had to write "uninst=1" (lower case). I think we  
>>> should
>>> either support the uppercase method, or somehow change the  
>>> warning message
>>> that is displayed. In fact, doing both might be preferable. :)  
>>> The first
>>> option is trivial ... I think the second one falls into this domain:
>>
>> The first option would set bad precedent. We'd then have people  
>> wanting
>> direct translations of all MakeMakeresqe options. verbose, prefix,  
>> etc.
>
> 	Yeah, that's another thing I was going to mention. This subclassing
> thing is great and all, but I really miss being able to just write  
> a "sub
> MY::postamble" to paste makefile snippets for me... can we get that  
> put into
> Module::Build as well?
>
> 	...
>
> 	Kidding!

Dude, you almost sent me into some kind of manic rage! =)


> Seriously though, there's been quite the debate about
> PREFIX and it sounds like people are working to get that into
> Module::Build...

No, it's actually been done for quite a while now in the 0.27_xx  
branch - yet another reason we really need to get that branch out the  
door.


> I can understand Module::Build behaving differently where
> it provides a technological advantage, but when there's a feature  
> that's
> supported by both MM and MB and the difference is just a matter of
> commandline syntax or terminology, shouldn't we be making MB's  
> syntax as
> close as possible to MM's (or at least support MM's) to smooth the
> transition?

Yeah - my motto here is "compatible where possible".  Definitely  
where it's possible to support EU::MM compatibility, we should do so.

  -Ken