> On Tue, 22 May 2007 12:17:41 -0400, John Peacock <[EMAIL PROTECTED]> said:
>> > What's the rationale for treating 1.0 differently from 1.00? I
>> mean, we're > talking about version numbers, not dictionaries.
>>
>> The rationale is that if two version strings are written differently,
On 5/22/07, Ken Williams <[EMAIL PROTECTED]> wrote:
There's a problem with that: if you don't have a Makefile.PL, and
someone's running an old CPAN that expects a Makefile.PL to be there,
it'll try creating a Makefile.PL and fail badly, with no helpful
message for the user. Old CPANs think that
On May 21, 2007, at 4:29 PM, David Golden wrote:
On 5/21/07, John Peacock <[EMAIL PROTECTED]> wrote:
Austin Schutz wrote:
> What is the point of the compatibility file if it requires
> Module::Build to work correctly?
But the compatibility file *itself* doesn't require Module::Build
-
Hi Josh
> Has there been experimentation to do use Module::Install to install
> Module::Build or CPAN.pm during the `make' or 'Makefile.PL' part of
> the module installation by CPAN.pm?
But this introduces its own horrible complications.
Many of Adamk's modules ship with Module::Install in the i
On 5/22/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
# from Joshua ben Jore
# on Tuesday 22 May 2007 03:38 pm:
>> Where *exactly* is "their prerequisites" defined?
>
>Well... I expect it to be in PREREQ_PM in Makefile.PL using
>ExtUtils::MakeMaker.
Ugh. I was hoping for an answer more like "MET
# from Joshua ben Jore
# on Tuesday 22 May 2007 03:38 pm:
>> Where *exactly* is "their prerequisites" defined?
>
>Well... I expect it to be in PREREQ_PM in Makefile.PL using
>ExtUtils::MakeMaker.
Ugh. I was hoping for an answer more like "META.yml".
How is Makefile.PL going to tell you to inst
On 5/22/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
# from Joshua ben Jore
# on Tuesday 22 May 2007 02:01 pm:
>The purpose of my tests is similar to imacat's. I test that it is
>possible to take a fresh perl and install a module without failure.
>When modules require a newer install chain, they
# from Joshua ben Jore
# on Tuesday 22 May 2007 02:01 pm:
>The purpose of my tests is similar to imacat's. I test that it is
>possible to take a fresh perl and install a module without failure.
>When modules require a newer install chain, they have to declare it in
>their prerequisites.
Where *ex
On 5/21/07, John Peacock <[EMAIL PROTECTED]> wrote:
Austin Schutz wrote:
> What is the point of the compatibility file if it requires
> Module::Build to work correctly?
FWIW, I ran your module against all of 5.6.2, 5.8.1->5.8.8 in
threaded,non-threaded,debug,non-debug perls. All of these
Andreas J. Koenig wrote:
But what you are saying is that "2.004000" sorts between v2.3999 and
v2.4001, right? Can you please show us the code that backs this claim?
No, that isn't right. "2.004000" sorts between v2.3.999 and v2.4.1
(split on three decimals). In fact qv("2.004000") is complet
> On Tue, 22 May 2007 01:26:54 +, Julian Mehnle <[EMAIL PROTECTED]>
> said:
> Andreas J. Koenig wrote:
>> Julian Mehnle <[EMAIL PROTECTED]> said:
>> > For anyone who has similar problems in the future and who reads this
>> > thread, I'd like to explain the cause of the problem ex
On 5/21/07, John Peacock <[EMAIL PROTECTED]> wrote:
Austin Schutz wrote:
> What is the point of the compatibility file if it requires
> Module::Build to work correctly?
But the compatibility file *itself* doesn't require Module::Build - it
merely checks to see whether it M::B is installed
Andreas J. Koenig wrote:
> > > > The problem I had is that my META.yml (generated by M::B 0.26)
> > > > had version numbers of the form "2.004000", which is
> > > > numerically correct, but in the new version.pm regime sorts
> > > > between v2.3999 and v2.4001, as opposed to between
13 matches
Mail list logo
