Is the supported version check necessary?

[eserte]

On my CentOS7 smoker the test suite fails:

...
ccflags         = -fPIC -I/usr/include -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -Wall -Wno-sometimes-uninitialized -Wno-unused-function -Wno-unused-value -Wno-unused-function -Wno-unused-variable -Wno-gnu -g -fPIC -fno-omit-frame-pointer -I/usr/include
ldflags         = -shared -lgsl -lgslcblas -lm -fPIC -fno-omit-frame-pointer
PERL5LIB        = ...
LD_LIBRARY_PATH = 
unsupported version: 1.15.1 at t/00-load.t line 14.
BEGIN failed--compilation aborted at t/00-load.t line 15.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 1.
t/00-load.t ........ 
Dubious, test returned 255 (wstat 65280, 0xff00)
All 1 subtests passed 
...
Test Summary Report
-------------------
t/00-load.t      (Wstat: 65280 Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/SF.t           (Wstat: 0 Tests: 1074 Failed: 0)
  TODO passed:   22
Files=56, Tests=3899, 15 wallclock secs ( 0.70 usr  0.17 sys +  8.79 cusr  5.68 csys = 15.34 CPU)
Result: FAIL
Failed 1/56 test programs. 0/3899 subtests failed.

However, t/00-load.t is the only test file failing. So, assuming that the test suite is comprehensive (and I think so, at least it doesn't look that short), it looks like the module is working on this system. So maybe it would be best to remove this check at all, or at least make it non-fatal?

[leto]

@eserte it seems draconian but it is actually necessary for the case when a user has a brand new GSL version that our library has no idea about, which often will cause compile or run-time errors.

Also, this bug has been fixed in a recent commit and we just need a new release to fix this, I think:

816f6d6

Also, thank you very much for your bug report, it's greatly appreciated! And thank you very much for your epic history of testing in Perl.

[leto]

FYI, our new fix is to not care about sub-releases like 1.15.1 but we would still fail for a new normal release we don't know about, such as 2.99

[leto]

It may also be interesting to add an ENV variable that testers can set, which ignores this check and we could get test report submissions for GSL versions we don't know about yet

[eserte]

@eserte it seems draconian but it is actually necessary for the case when a user has a brand new GSL version that our library has no idea about, which often will cause compile or run-time errors.

But in this case the rest of the test suite will fail, and this is enough to prevent normal (unforced) installation of the module.

[eserte]

It may also be interesting to add an ENV variable that testers can set, which ignores this check and we could get test report submissions for GSL versions we don't know about yet

Some (most?) testers set AUTOMATED_TESTING=1. (I normally don't, but if I know, then I can set arbitrary environment variables through distropref files)

[leto]

@eserte I forgot about that, and yes, it seems that we could turn this check off for CPANtesters with that ENV var to get results for versions we potentially have never seen. Thanks for this suggestion!

Mostly what we see, is that package managers and OS's will append their own weird version number that breaks our very complex logic of which XS code to compile for the given GSL library version found locally