Optionally disable legacy reactions in Cantera 2.6

[ischoegl]

Abstract

At the moment, there already is a preprocessor flag CT_NO_LEGACY_REACTIONS_26 introduced in Reaction.h, although it remains untested (at the moment, I am aware of at least one instance where toggling this flag will result in compilation errors). In order to ensure that the new framework introduced in #87 works without legacy support, the use of this preprocessor flag (or an additional CT_NO_LEGACY_26) could be extended to completely eliminate legacy reactions (as well as various CTI/XML tags).

The flag could be adopted in SCons

Motivation

Describe the need for the work being done:

• What problem is it trying to solve? ... ensure that changes introduced in 2.6 are feature complete and do not rely on legacy objects.
• Who is affected by the change? ... early adopters and developers
• Why is this a good solution? ... the preprocessor will allow for CI tests without legacy support prior to the 2.6 release; deprecated code is automatically marked. As 2.6 is the last release to include legacy features, this will add a layer ensuring that everything is ready for the transition to 3.0.

Alternatives

Just make sure that toggling the flag to change defaults works (while still adding a CI runner that covers this configuration).

Edit: Changes proposed in Cantera/cantera#1184 largely address this issue, as remaining 'hybrid' implementations no longer use legacy objects.

[speth]

• What problem is it trying to solve? ... ensure that changes introduced in 2.6 are feature complete and do not rely on legacy objects.

Generally, the method that we try to use to get this assurance, at least for the C++ core, is by having deprecated features call warn_deprecated, and by running the test suite with deprecation warnings treated as errors.

I think the current issue arises from the fact that there are a number of deprecated reaction types that don't raise such warnings and we don't necessarily want them to, at least depending on the path by which these reactions are created (e.g., we don't want to have warnings about deprecated reaction types if you're importing a CTI file -- that should only issue the warning about the CTI format being deprecated). But I think we are missing warnings for these types if they are instantiated explicitly rather than through the mechanism import process.

[ischoegl]

I think the current issue arises from the fact that there are a number of deprecated reaction types that don't raise such warnings and we don't necessarily want them to, at least depending on the path by which these reactions are created (e.g., we don't want to have warnings about deprecated reaction types if you're importing a CTI file -- that should only issue the warning about the CTI format being deprecated). But I think we are missing warnings for these types if they are instantiated explicitly rather than through the mechanism import process.

This is not how I understood the precompiler flag CT_NO_LEGACY_REACTION_26 (see Reaction.h and RxnRates.h). I believe the intent here was to ensure that external code would not break, while providing an opportunity to 'force' the new behavior. At the moment, setting this flag immediately generates compiler errors (which I am currently fixing in Cantera/cantera#1184).

As my limited tests are already showing, switching some objects over appears to introduce wide-spread breakages, which I'd like to pre-emptively address.