You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6f69769
Browse filesBrowse the repository at this point in the historyBrowse files
DPL: allow building a workflow as a workflow plugin
A workflow opts in with WORKFLOW_PLUGIN, on o2_add_dpl_workflow or on
o2_add_executable. Its sources are then compiled once, into the DSO
libO2<Name>Plugin holding the workflow plugin <Name>, the CamelCase of
the executable name without o2-: o2-testworkflows-diamond-workflow gives
O2TestworkflowsDiamondWorkflowPlugin:TestworkflowsDiamondWorkflow. The
executable keeps its name and options, and only has a main() which
calls dpl_workflow_main() of the plugin it links. That one runs the
plugin as the one embedded in the executable, exactly as main() does for
any other workflow, so its behaviour and dumps are the same. The plugin
is installed in lib with the executable.
WORKFLOW_PLUGIN, rather than PLUGIN, because DPL has several kinds of
plugins and this one is DplPluginKind::Workflow, loaded with
--workflow-plugin; the same name works on both functions.
The existing o2-dpl-run, whose embedded workflow is empty, is the
generic loader: o2-dpl-run --workflow-plugin A:X,B:Y runs the workflows
of the plugins, and its children are again o2-dpl-run.
Workflows which do not opt in are built exactly as before. The diamond
workflow, the simple source, processor and sink, and the two test
plugins of test_WorkflowPlugins opt in.
test_Framework_test_WorkflowPluginDump checks that the plugin of the
diamond workflow, run by o2-dpl-run, defines the same workflow as its
executable, apart from the executable, plugin and command line.
0 commit comments