Messages can be enabled by setting the `ENABLE_GAUDITOOL_SUMMARY`
environment variable.

Closes #215

so that things work in a super project build

Change the type of the properties used to specify the input / output locations of {Merging,Splitting}Transformer
from vector-of-string to the more appropriate vector-of-DataObjID

- and add a `#define` to simplify migration

Currenly, the constructors of the Gaudi::Functional baseclasses use
`std::array<KeyValue,N>` as arguments where N is the number of inputs
or outputs specified. However, this implies that one can specify a list
of less than N KeyValues, as `std::array` will happily
default-initialize any missing items. This will then result in an error
in genConf, as this implies a property with a default-initialized string
(i.e. an empty string) as key.

This can be fixed by replacing the `std::array<KeyValue,N>` with a tuple
with N `KeyValues, eg. for N=2 an `st::tuple<KeyValue,KeyValue>`.

* allow distinct types of columns to be filled in a single call

* avoid using C-style VA_ARGS which assumes 'double' arugments without any checking
* generalize to 'all the same type of arguments' instead of 'all double', and check
  at compile time
* avoid creating an `std::vector` to tokenize the format string

* remove one level of indirection in memory layout
* allow the use of std::string_view in find

* remove one redundant layer of indirection in the storage of the
  'value' -- items in a `std::unordered_map` are stable, so no need
  to store a `unique_ptr<T>`, and instead just store a `T` directly
  (as T is highly constraint already in order to be able to write it
  into an NTuple)
* make lookup by `std::string_view` instead of `std::string` as most
  usecases have a string literal (which is not an `std::string`) as
  argument, and in case of `std::string` this implies at least copying
  the characters, and (in case it overflows the SBO of `std::string`)
  a potential memory allocation

Based on the MultiMergingTransformer implementation, but allows for
algorithms to return a boolean which sets the 'filter passed' property
for the control flow.

A new test checks an example instantiation along one of
MultiMergingTransformer, which was not previously tested. To make this
test more obvious the IntDataProducer example now has a configurable
value property.

This one is dedicated to void returning signatures in case of legacy algorithm

This is purely a convenience alias to MergingTransformer created for
consistency with the naming of the Consumer algorithms.

Also added tests for it, as well as the missing python code for testing
the MergingTransformer with void output

The current MergingTransformer signature cannot return void. This is
fixing it

Namely m_header, m_format1, m_format2, m_useEffFormat, m_printEmptyCounters, m_statEntityList

This should have in principle no consequences, but most tests will
actually fail as the properties values are printed to the output, and
these will be missing now

Allow a second template argument on `DataObjectWriteHandle` eg.
DataObjectWriteHandle<GetType,PutType> (note: by default, in case
of a single template argument, PutType=GetType, and the original
behaviour is kept).  In this case, `DataObjectWriteHandle::put`
will accept an rvalue reference to `PutType`, which it will create
a dedicated 'wrapper', which contains both the moved instance of
`PutType` as well as a `GetType` constructed from the moved instance,
into the event store. This wrapper can be retrieved and unwrapped
by a `DataObjectReadHandle<GetType>`.

Thomas Cluzel authored 4 years ago and Marco Clemencic committed 4 years ago

see https://its.cern.ch/jira/browse/LBCOMP-23



Co-authored-by: Marco Clemencic <marco.clemencic@cern.ch>

specifically, remove `typePrint()`, `propsPrint()`, and `errorsPrint()`

also properly set algorithm type string in GaudiPython::PyAlg<>

Gitlab CI authored 4 years ago and Sebastien Ponce committed 4 years ago

patch generated by https://gitlab.cern.ch/lhcb/Gaudi/-/jobs/10087220