by Kyle Knoepfel
Attendees:
Chris Backhouse, Alex Himmel, Chris Jones, Gianluca Petrillo, Erica Snider
artists: Lynn Garren, Chris Green, Kyle Knoepfel, Marc Paterno
art 1.15.02:
All builds of 1.15.02 were out on Friday, 8/14. See the release notes for details.
Resolved issues:
Bug #9769 – An attempt to dereference a default-constructed art::Handle, or one that has been cleared, now throws an exception. This prevents a dereferencing of nullptr.
Discussion about including deprecations in the art suite:
There was extensive discussion about how to introduce deprecations within art code. Specifically, art developers would like to start using the [[deprecated(opt. message)]] attribute. At compile-time, a deprecation warning is triggered if a deprecated function/class/etc. is used, and an optional message is printed to the screen. The artists would include descriptive messages that indicate how users can adjust their code to avoid calling deprecated facilities.
Stakeholders, in general, were very supportive of including deprecations. The focus of the discussion was how to handle the deprecations in light of the build settings used by the various experiments. Within art, compile-time warnings are turned into errors by compiling with the cetbuildtools WERROR flag as specified in the top-level CMakeLists.txt files of each package. This flag turns warnings into errors. Such settings, as used by the experiments, would induce broken user builds if deprecations are used.
There are multiple ways each experiment could preserve the warning status of the deprecations, either through the use of ‘-Wno-deprecated’ for a particular source file, or using the relevant pragma inside of source code. For individuals who use cetbuildtools, two proposals were discussed:
Retain the current semantic of WERROR, and add an additional flag (e.g.) ALLOW_DEPRECATIONS, which would not turn deprecation warnings into errors.
Change the semantic of WERROR so that deprecations remain warnings, but add an additional flag (e.g.) ERROR_DEPRECATIONS that, when specified, would force all deprecation warnings to become errors.
There was slight preference for the first option, so it will be sent to the art-stakeholders email list for their input. [The email was sent on 8/20.]
Discussion about deprecating ParameterSet::get_keys and friends.
Kyle proposed introducing two new functions:
ParameterSet::get_names()
ParameterSet::get_pset_names()
which will replace the deprecated functions, respectively:
ParameterSet::get_keys()
ParameterSet::get_pset_keys()
The reason for this change is so that the distinction between ‘names’ (simple keys without any ‘.’ or array subscripts) and ‘keys’ (compound keys including ‘.’ and/or subscripts) can be preserved. The distinction is important for “getters,” which can receive any key, and “putters,” which can receive only names.
The deprecated functions will call the new functions, retaining the old behavior.
There was general agreement that this was fine.