Release 21.06
Optional Components
GPI-Space now supports disabling some components at configuration time
to reduce the dependencies needed as well as build time. The following
options can be given to CMake with either =OFF
or =ON
appended:
-DGSPC_WITH_MONITOR_APP
: Thegspc-monitor
(also known as “gantt”) application for execution monitoring. This component requires Qt5.
‘eureka-group’ is now available as a tag that contains an expression
The attribute eureka-group
of the XML tag <module>
can only store
constant strings. To allow for data dependent eureka groups, the
element <eureka-group>
has been introduced as an alternative.
The content of the new tag <eureka-group>
is interpreted as an
expression and evaluated with the evaluation context of the
transition, e.g. with all the input tokens are known. The expression
shall return a value of type string
.
Please choose between the attribute or the tag, it is an error to specify both.
In general prefer the tag over the attribute as the tag is more flexible. Current application code
<module ... eureka-group="value" ...>
</module>
can now be written as
<module ... ...>
<eureka-group>"value"</eureka-group>
</module>
Note that the meaning of the double quotes ‘”’ has changed in the
example: In the former eureka-group="value"
they enclose the
attribute value, which is a string. Now, in
<eureka-group>"value"</eureka-group>
the double quotes are
interpreted by the expression parser to parse the (same) string.
The possibility to let the eureka group depend on the inputs of a transition is demonstrated by the example code:
<defun>
<in name="eureka_group" type="string"/>
<module>
<eureka-group>${eureka_group}</eureka-group>
</module>
</defun>
It determines the eureka group by the value of an input port.
String concatenation can be used to combine information into a more complex eureka group:
<defun>
<in name="eureka_group" type="string"/>
<in name="eureka_id" type="string"/>
<module>
<eureka-group>${eureka_group} + "_" + ${eureka_id}</eureka-group>
</module>
</defun>
Installed libraries now hide unintended symbols
To avoid implementation details leaking into user code, GPI-Space’s
libraries now no longer export all symbols but instead explicitly
export the intended API. Only symbols marked GSPC_DLLEXPORT
in the
headers are part of the API and other symbols may vanish or change
without notice.
This implies that applications might break due to relying on symbols that weren’t intended to be used. This might also be the case when using intended API but linking the wrong library. It might also happen that due to GPI-Space’s dependencies linking a previously missing third-party dependency is now missing.
If an application fails to link with undefined symbols after updating to this version, check whether these symbols came from GPI-Space before. If that’s the case, check
- whether the correct library is linked
- whether all third-party dependencies are linked and not relied upon GPI-Space to be provided
- whether the symbol used is actually part of the public GPI-Space API
The first two cases can be resolved by changing the libraries linked to include the correct dependencies. In the latter case, a sibling function might be part of the API and should be used instead. If there is no such sibling function, contact GPI-Space support to discuss whether it should be added to the API.
[API CHANGE] gspc::worker_description hides its implementation
The structure gspc::worker_description
now hides its implementation
in order to allow for future changes.
Applications that access the internal information must now store it by themselves.
Also applications can not copy gspc::worker_descriptions
any longer
but only move
them. To adapt to this a current application code of
the form
gspc::worker_description const description {args...};
drts.add_worker ({description}, ...);
must now be written as
std::vector<gspc::worker_description> descriptions;
descriptions.emplace_back {args...};
drts.add_worker (descriptions, ...);
CMake Utility Restructuring
GPISpace’s CMake utilities underwent some restructuring as a step
towards modernizing the build infrastructure and the ongoing
modularization of GPISpace. It is now organized as a standalone
project (util-cmake
) including install targets and a find package
config file. In addition, the directory structure of the scripts was
modified to prepend a namespace directory to better reflect the origin
of the scripts.
util-cmake
enforces the usage of a compatible cmake minimum version (currently 3.13). Parent projects will throw a fatal error if they don’t set an appropriate CMake version withcmake_minimum_required
before addingutil-cmake
.- All CMake utility scripts need to have the namespace
util-cmake/
prepended to them (e.g.include (add_macros)
=>include (util-cmake/add_macros)
) - The
add_unit_test
function is no longer part ofadd_macros.cmake
, but resides now in script of its ownadd_unit_test.cmake
. - The
bundle.sh
script should no longer be accessed using a hard-coded path. Instead, util-cmake exposes a variable calledutil_cmake_bundle_sh
populated with the correct absolute path. util-cmake
can now be installed if required. By default, the installation is deactivated.
GPISpace CMake Minimum Version Enforcement
Same as util-cmake
, GPISpace’s package config file now enforces the
usage of a required minimum CMake version (currently 3.13).
Applications failing to use at least that version will fail with a
fatal error during configuration time.
Fixes
- Removed methods marked
INDICATES_A_RACE
from production code. - Respect
TESTING_RIF_STRATEGY
andTESTING_RIF_STRATEGY_PARAMETERS
in all tests. - Fixed bug related to the thread-safe creation of SSL contexts.
- Improved documentation: added documentation for the Eureka feature and for creating topology descriptions.
Miscellaneous
- Applications that link
pnetc
generated libraries can now linkGPISpace::APIGuard
instead of definingWE_GUARD_SYMBOL
themselves. - Removed the attribute
children_allowed
from workers. The agent can have only terminal components as workers now. - Made the worker manager a component that belongs only to the scheduler, forbidding the direct interaction between agent and worker manager. The agent is now just talking to the scheduler, which is the only one who may access the worker manager, in a thread-safe way.
- Moved functionality proper to scheduling from the worker manager to the scheduler side.