Hi Bryan-

The problem is that PDL::PP has a safety check that the version of the PDL
core it was compiled against is the same as the version using the module.
Unfortunately, this version has nothing to do with the version numbers of
your modules and I don't know of a way to get the CPAN Testers to do the
right thing.  One thing you could to to avoid false FAIL reports would be
to check compatibility yourself at Makefile.PL or Build.PL configuration
time and exit indicating NA if there is a conflict---at least that would
not be a FAIL.

Regards,
Chris


On Mon, Nov 16, 2015 at 8:16 AM, Bryan Jurish <moocow.bov...@gmail.com>
wrote:

> morning all,
>
> Apologies in advance for an annoying and quite possible off-topic
> question, but I can't seem to get my head around this bug, and I'm hoping
> perhaps someone on the list can enlighten me.
>
> in the wake of the release of PDL 2.014 and some associated buglets
> manifesting in a few of my CPAN modules, I've noticed some very strange
> behavior coming from cpantesters, to wit: systems reporting near-identical
> configurations aren't testing identically; compare e.g.
> http://www.cpantesters.org/cpan/report/c9c3665a-87b1-11e5-99df-94052cde3c15
> (PASS) with
> http://www.cpantesters.org/cpan/report/e77c5196-897a-11e5-b552-e159351a082c
> (FAIL).  Both systems report themselves as "perl v5.22.0, GNU/Linux,
> 3.16.0-4-amd64, x86_64-linux-thread-multi", both running PDL-2.014, yet
> the one fails with a "PDL::VectorValued::Utils needs to be recompiled
> against the newly installed PDL" message during testing, while the other
> succeeds.
>
> I understand the why such a message can be useful; in this case, I'm not
> sure that situation (re-linking and/or re-compilation required) applies.
> The module in question, PDL::Ngrams
> <https://metacpan.org/release/PDL-Ngrams>, depends on my CPAN module
> PDL::VectorValued <https://metacpan.org/release/PDL-VectorValued> both
> for runtime utilities (rlevec() & co) and compile-time macros
> (vv_indx_sig(), vv_indx_typedef()).  For consistency reasons, I've put the
> version information for PDL::VectorValued in a specialized file
> PDL/VectorValued/Version.pm
> <https://metacpan.org/source/MOOCOW/PDL-VectorValued-1.0.3/VectorValued/Version.pm>
> (which itself does not require PDL).  Then, in PDL-Ngrams/Makefile.PL
> <https://metacpan.org/source/MOOCOW/PDL-Ngrams-0.06/Makefile.PL>, I had
> to specify
>
>    PREREQ_PM => { ..., 'PDL::VectorValued::Version' => ... }
>
> because ExtUtils::MakeMaker doesn't seem to resolve it correctly if I
> specify it as PREREQ_PM=> { ..., 'PDL::VectorValued' => ... } when the
> actual package $VERSION declaration isn't really in PDL/VectorValued.pm (as
> it isn't).  On the other hand, I want PDL::VectorValued::Dev
> <https://metacpan.org/pod/PDL::VectorValued::Dev> to carry the same
> $VERSION as PDL::VectorValued itself, and I even need the Dev module in
> order to build PDL::VectorValued::Utils
> <https://metacpan.org/pod/PDL::VectorValued::Utils>, which provides the
> PDL::PP guts for PDL::VectorValued.
>
> I'm guessing that the "needs re-compilation" messages from the FAIL report
> are occurring on a smoker with an older version of PDL::VectorValued
> installed, which passes the PREREQ_PM test because the referenced
> PDL::VectorValued::Version package isn't itself built with PDL::PP, but
> then fails during 'make test' because the actual PDL::VectorValued::Utils
> guts aren't current.  Can anyone suggest a configuration that would allow
> me to (a) specify a $VERSION for PDL::VectorValued and its sub-packages
> once and only once, (b) specify PREREQ_PM for dependent modules like
> PDL::Ngrams in a manner which is more palatable to CPAN smokers than the
> current hacks, and (c) continue to use PDL::VectorValued::Dev when building
> PDL::VectorValued::Utils itself?  Or is there something else going on here?
>
> I realize it's rather a complex situation but I'm about at my wits' end
> here, and would be grateful for any suggestions.
>
> marmosets,
>   Bryan
>
>
> --
> Bryan Jurish                           "There is *always* one more bug."
> moocow.bov...@gmail.com         -Lubarsky's Law of Cybernetic Entomology
>
>
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
> _______________________________________________
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
------------------------------------------------------------------------------
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

Reply via email to