On Tue, 22 Jul 2008 15:59:11 +0200, Steffen Schwigon [EMAIL PROTECTED]
said:
Hi!
I'm experimenting with an Acme module and want to provide meta
information explicitely in the META.yml because the PAUSE indexer
doesn't seem to look into my utf-8 filenames.
You are not alone. See
You can bundle a Build.PL (Module::Build) and use it to generate the dist, and
you'll get a shiny meta file :) Or you can drop EU::MM and use only M::B which
has some transition mechanism for EU::MM users. However I prefer to use a
native Makefile.PL...
Original-Nachricht
On 07/21/2008 10:57 PM, Bill Ward wrote:
My module Number::Format has some red areas in its Kwalitee report
http://cpants.perl.org/dist/kwalitee/Number-Format
When I release 1.60, I tried to fix a lot of the kwalitee issues with
the previous version, 1.52. However, it appears that some of
I'm not interested in Module::Build.
I've checked your Makefile.PL and you're not doing anything special with it
(like subclassing or XS stuff, etc.), so it'll be straight forward to add
Module::Build support to your module. And since M::B is in core starting with
5.10, I think it's the way
--- On Wed, 23/7/08, Burak Gürsoy [EMAIL PROTECTED] wrote:
I'm not interested in Module::Build.
I've checked your Makefile.PL and you're not doing
anything special with it (like subclassing or XS stuff,
etc.), so it'll be straight forward to add
Module::Build support to your module. And
On Wed, Jul 23, 2008 at 4:28 AM, Burak Gürsoy [EMAIL PROTECTED] wrote:
I'm not interested in Module::Build.
I've checked your Makefile.PL and you're not doing anything special with it
(like subclassing or XS stuff, etc.), so it'll be straight forward to add
Module::Build support to your
Bill Ward wrote:
But to my mind, the may problem with M::B is that it's moving away
from the traditional Unix concept of using make to install things.
And I'm not willing to go there.
Just as a counterpoint, I refuse to use EU::MM in new code. It's too broken
and there's no reason to use a
Bill Ward [EMAIL PROTECTED] writes:
But to my mind, the may problem with M::B is that it's moving away
from the traditional Unix concept of using make to install things.
A lot of Perl is about platform-independence. Probably even more than
other languages that occupied this cliché ad nauseam.
Elliot Shank wrote:
Bill Ward wrote:
But to my mind, the may problem with M::B is that it's moving away
from the traditional Unix concept of using make to install things.
And I'm not willing to go there.
Avoiding something because it's not what you're used to strikes me as
being a bit silly.
On Wed, Jul 23, 2008 at 1:06 PM, Steffen Schwigon [EMAIL PROTECTED] wrote:
Bill Ward [EMAIL PROTECTED] writes:
But to my mind, the may problem with M::B is that it's moving away
from the traditional Unix concept of using make to install things.
A lot of Perl is about platform-independence.
David Cantrell wrote:
As a counter-counter-point, if you're going to refuse to use EU::MM
because it's too broken, you have to refuse to use Module::Build for the
same reason.
Ah. Ok, I'll use nothing.
Elliot Shank wrote:
David Cantrell wrote:
As a counter-counter-point, if you're going to refuse to use EU::MM
because it's too broken, you have to refuse to use Module::Build for
the same reason.
Ah. Ok, I'll use nothing.
Well done! Ten out of ten for deliberately misunderstanding!
--
On Wed, Jul 23, 2008 at 2:09 PM, David Cantrell [EMAIL PROTECTED] wrote:
Even if you only care about Unix-a-likes, you still need to remember that
GNU make, Sun make, SGI make, etc are only partially compatible. Then
consider that GNU software tends to break in stupid ways from one release to
13 matches
Mail list logo
