Breaking changes for art series 3.02


 CET_PLUGIN_PATH environment variable

Due to various build-system developments, the environment variable now used for loading plugins is CET_PLUGIN_PATH, which is a colon-delimited list of directories where art-specific plugin libraries reside. Users of cetbuildtools/mrb need not make any changes to their build environment for loading art plugins. Those who do not use cetbuildtools will need to set the CET_PLUGIN_PATH explicitly.

 art to art_root_io migration

There are various header and library relocations due to the art and art_root_io migration. The primary changes required are:

Header changes
- #include "art/Framework/Services/Optional/TFileService.h" 
+ #include "art_root_io/TFileService.h" 

- #include "art/Framework/Services/Optional/TFileDirectory.h" 
+ #include "art_root_io/TFileDirectory.h" 

Bare library link-line change
- libart_Framework_Services_Optional_TFileService_service.(so|dylib)
+ libart_root_io_TFileService_service.(so|dylib)

CMake variable library link-line change

A script has been provided that enables the above migrations and many more that are not listed. After setting up the art_root_io UPS product, call:

$ART_ROOT_IO_DIR/tools/migration/art-3.02-migration -d <top-level directory> [--dry-run]

where the '--dry-run' program option will list which files will be changed if the migration script is applied to the top-level directory.

Using ROOT in module, service, and source constructors

Due to the art and art_root_io split, some of the steps taken during the art program initialization happen later than they used. The consequence is that anyone using ROOT in the constructors of their modules, services, or sources may need to take additional steps to ensure successful execution of the program. In particular:

  • N.B. If any self-registering objects are created in the constructor, please call TH1::AddDirectory(false); to ensure that the registered objects are not associated with any currently open ROOT file.
  • Anyone requiring the use of art-specific ROOT constructs (e.g. custom streamers) in the constructor should first call art::root::setup(), which is provided by the art_root_io/setup.h header file.

 MixFilter<Detail, RootIOPolicy> declaration

Users must now declare which I/O policy their MixFilter detail class will use (only the art::RootIOPolicy is currently supported). This is done by making the following changes:

+ #include "art_root_io/RootIOPolicy.h" 

- using ModuleType = art::MixFilter<DetailClass>; 
+ using ModuleType = art::MixFilter<DetailClass, art::RootIOPolicy>; 

Also note that because a comma appears in the template instantiation, the preprocessing of the DEFINE_ART_MODULE macro is less flexible:

A comma in the macro call causes problems:
- DEFINE_ART_MODULE(art::MixFilter<DetailClass, art::RootIOPolicy>)
+ using ModuleType = art::MixFilter<DetailClass, art::RootIOPolicy>;

In addition, all MixFilter modules must link against the art_root_io library.

 art-provided SAM metadata

Please note the following changes in how the SAM metadata is stored:

From To
first_event art.first_event
last_event art.last_event
applicationVersion application.version
file_format_era art.file_format_era
file_format_version art.file_format_version
process_name art.process_name
run_type art.run_type

In addition, the top-level fields first_event and last_event are also stored in single integer form, as specified by SAM. The art-specific first_event and last_event triplets are still stored but with the 'art.' prefix.

 MixFilterDetail::startEvent function signature

The startEvent function for a MixFilter detail class no longer supports a function signature with no arguments, a signature that has been deprecated since art 1.00.00. Please make the following changes:

- void MixFilterDetail::startEvent()
+ void MixFilterDetail::startEvent(art::Event const& e)



All uses of boost::any have been replaced with std::any. Any users that have provided fhicl::detail::(encode|decode) overloads should change their function signatures to use std::any instead (with the '#include <any>' header dependency).