the first place.)
I fail to see why M:B needs a MANIFEST.SKIP when it is not being called
upon to generate a MANIFEST.
-zefram
irst
(manually handling the dependency). So overall I wouldn't worry about it.
-zefram
uires,
though it certainly does require it at configure time if using Build.PL.
It thus disguises the circularity.)
-zefram
Result: FAIL
Failed 1/44 test programs. 2/1183 subtests failed.
On 5.6 the same tests fail, but glibc reports memory corruption and
gives a memory map dump. This is not really a regression from M:B 0.35,
which also failed on 5.6. I think this should be fixed if possible,
nevertheless.
-zefram
r...@savage.net.au wrote:
>at my new job we use Debian packages
>to install modules. How would they be linked to plugins?
Same way they're linked to any other CPAN modules.
-zefram
David Golden wrote:
>I don't want someone to "Build manifest" and add it by mistake.
Maybe "./Build manifest" needs some new logic, then. Not distclean.
-zefram
David Golden wrote:
>I'll sort it out. Now that we have MYMETA files we need to be sure they
>don't get packed up in a dist.
The contents of the distribution is controlled by MANIFEST. There's no
new reason to use SKIP files here.
-zefram
"clean"
part of what I asked it to do. The problem does not occur with M:B 0.35.
-zefram
r from the distribution or from the installed stuff, give it a name
of its own and an explicit protocol.
-zefram
1.60.0
Why shouldn't this situation be an error, and die because "1.06" can't
be compared with "v1.7.0"?
-zefram
John Peacock wrote:
>How would you translate them?
I suggest not translating them. Compare tuple against tuple, or
float against float, but with tuple against float only compare the
integer/first part.
-zefram
David Golden wrote:
>Subject: Re: versions just won't ever be sane *and* compatible
Dotted tuples were a mistake. Plain decimals are sane, and compatible
all the way back.
-zefram
hash that it uses is keyed by "perl"-style keys, but it's
being given the "Perl_5" key. So it returns undef, and the META.yml
comes out looking like this:
license: perl
resources:
license: ~
-zefram
emporary files, but it looks
like this is the only compiling method that doesn't start with input
files already in the filesystem.
M:B has places for temporary files. Should it be able to tell EU:CB to
use a particular directory?
-zefram
David Golden wrote:
>How about this for a simple fix: rather than cache the CBuilder object
>in properties, create a new "stash" for non-persistent caching.
Looks good.
> Unfortunately, that doesn't help Zefram deal with older
>Module::Builds,
Actually it do
about it, though. I don't care about
the availability of EU:CB myself; it is neither necessary nor sufficient.
I care, precisely, about whether M:B is offering C building facilities.
The other option that I see is to delete $self->{properties}->{_cbuilder}
at some opportune moment, possibly by wrapping ->write_config.
-zefram
hen upgrade each other happily. For older perls we
must ensure that there is an upgrade path to get the circle established;
old-style Makefile.PLs for the critical modules suffice.
-zefram
user, as one failed test in t/compat.t.
The dependency should be versioned, to require a version of EU:I that
lacks the bug. Version 1.32 suffices. I don't know about versions
between 1.29 and 1.32.
-zefram
f programmers using C and its derivatives.
Perl is one of the languages that perpetuates the confusion.
-zefram
leading the design engineer to
drill out some mass to correct it.
-zefram
dir' ...) conditional.
No need. Nothing outside the conditional modifies %$no_index.
-zefram
pplied as an argument.
I think it's bad style to cause undocumented side effects on one's
parameters.
>We have no documentation coverage for this?
There's a lot in M::B that is not properly documented.
-zefram
The attached patch replaces the _cbuilder method with a public cbuilder
method, as discussed.
-zefram
--- Module-Build-0.2808_01.mod0/lib/Module/Build/Base.pm2007-10-25
19:22:56.264034077 +0100
+++ Module-Build-0.2808_01.mod1/lib/Module/Build/Base.pm2007-10-25
19:30:46.107001947
g was supplied.
This makes CPANTS happier.
-zefram
--- Module-Build-0.2808_01.orig/lib/Module/Build/Base.pm2007-10-24
17:48:08.0 +0100
+++ Module-Build-0.2808_01.mod0/lib/Module/Build/Base.pm2007-10-25
19:22:56.264034077 +0100
@@ -3424,14 +3424,19 @@
}
;
if (
e default. Not sure about a good interface
for that either, yet. It wouldn't be too difficult to effectively
reimplement make, but I think we can do better than that, and make it
more dynamic as well as achieving that generality.
-zefram
ts into the build process?
Have I missed some bits of M::B that I could override to greater effect?
My development version of the module in question is at
<http://www.fysh.org/~zefram/tmp/Time-UTC-Now-0.006001.tar.gz>.
-zefram
sitive dependency thus:
requires:
Math::BigInt: >=1.64, !=1.70
But how would I declare this in the negative form? I essentially want
to do
conflicts:
Math::BigInt: <1.64
Math::BigInt: ==1.70
but of course I can't duplicate the "Math::BigInt" key. I would need
a logical-OR syntax:
conflicts:
Math::BigInt: <1.64 or ==1.70
-zefram
t, but it can be used
perfectly well without any bignum modules. I don't want to downgrade the
requirement to a "recommends", though, if it means the version requirement
won't be automatically handled when some other module knows that it *will*
be doing bignum date arithmetic.
-zefram
28 matches
Mail list logo
