-
-
Notifications
You must be signed in to change notification settings - Fork 348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple fix for Sundials 5.1 compatibility #814
Conversation
The Sundials 5.1 has no any changes in CVODES API in comparison with sundials 4.0, 4.1, 5.0 therefore the compatibility configuration fix is trivial.
P.s. Tested for system installed sundials. I tried to make changes like in 94a7003 |
@band-a-prend Thanks for submitting this! You can update the submodule by
After that, assuming no code in SUNDIALS has moved around, the other changes in 94a7003 should be straightforward. |
Thank you for the clue. The command I push changes now and hope to check build process on my local machine this evening. |
Thanks @band-a-prend perhaps the remote was not configured for the submodule or something. Anyways, the change seems to be appropriate |
I recheck currently build and tests, please wait. |
Appropriate sha1-snapshot (b78e575639babe99aea9a0558d0f64732d6d729e) of sundials tag v5.1.0 is fetched now into
|
Given the increased rate of releases of SUNDIALS, and the fact that we haven't seen breaking changes (at least, that affect Cantera) in several recent minor releases, I think we should assume compatibility with at least minor versions, i.e. 5.x. A build-time warning for versions newer than the latest we have tested would probably still be useful. |
Also, since we now support every released version back to 2.4, I think we should turn this into a if LooseVersion(env['sundials_version']) >= LooseVersion('6.0'):
error... |
@bryanwweber, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of small changes
SConstruct
Outdated
@@ -1048,6 +1048,7 @@ env['has_demangle'] = conf.CheckDeclaration("boost::core::demangle", | |||
'#include <boost/core/demangle.hpp>', 'C++') | |||
|
|||
import SCons.Conftest, SCons.SConf | |||
from distutils.version import LooseVersion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to import this, LooseVersion
is imported somewhere in the builtutils
, which is *
imported in SConstruct
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed.
SConstruct
Outdated
@@ -1108,7 +1109,7 @@ if env['system_sundials'] == 'y': | |||
|
|||
# Ignore the minor version, e.g. 2.4.x -> 2.4 | |||
env['sundials_version'] = '.'.join(sundials_version.split('.')[:2]) | |||
if env['sundials_version'] not in ('2.4','2.5','2.6','2.7','3.0','3.1','3.2','4.0','4.1','5.0'): | |||
if LooseVersion(env['sundials_version']) < LooseVersion('2.4') or LooseVersion(env['sundials_version']) >= LooseVersion('6.0'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest creating a variable for LooseVersion(env['sundials_version'])
here to shorten this line... the whole point was to make it shorter 😂 You could then reuse that variable on line 1118 in that other if
statement comparing to 2.4
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I then also could safely reuse this shorter variable at line 1610 because it's within another one if env['system_sundials'] == 'y'
condition check.
system_sundials_version
seems as reasonable name this case: although this will not make expression significantly shorter but it will avoid evaluation of LooseVersion() again and again for if env['system_sundials'] == 'y'
blocks.
the whole point was to make it shorter 😂
Yes, at this point of view this attempt certainly has failed. But it then should become more readable in comparison with rapidly expanding list of numbers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last commit is updated.
SConstruct
Outdated
@@ -1108,13 +1108,14 @@ if env['system_sundials'] == 'y': | |||
|
|||
# Ignore the minor version, e.g. 2.4.x -> 2.4 | |||
env['sundials_version'] = '.'.join(sundials_version.split('.')[:2]) | |||
if env['sundials_version'] not in ('2.4','2.5','2.6','2.7','3.0','3.1','3.2','4.0','4.1','5.0'): | |||
system_sundials_version = LooseVersion(env['sundials_version']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't necessarily associated with the system SUNDIALS though, so I think just sundials_ver
would be sufficient and shorter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
We expect that minor version number release will not introduce breaking changes, but the user should be warned that their version of SUNDIALS is untested.
Codecov Report
@@ Coverage Diff @@
## master #814 +/- ##
=======================================
Coverage 71.39% 71.39%
=======================================
Files 372 372
Lines 43482 43482
=======================================
Hits 31045 31045
Misses 12437 12437 Continue to review full report at Codecov.
|
Checklist
scons build
&scons test
) and unit tests address code coverageIf applicable, fill in the issue number this pull request is fixing
Fixes #
Changes proposed in this pull request
The Sundials 5.1 has no any changes in CVODES API in comparison with sundials 4.0, 4.1, 5.0 therefore the compatibility configuration fix is trivial.