This guide covers how to integrate your code into ADTF. After reading this guide, you will know:
The Plugin Description Generator (PDGen) extracts meta information from an ADTF plugin and stores it in an XML file. Tools such as the ADTF Configuration Editor use the extracted information to provide plugin related functionality without having to load the actual plugin.
To extract information such as any provided and/or required interfaces the PDGen has to actually load the plugin DLL and instantiate the contained ADTF Services and Filters. In some cases it may be necessary to include information which is not provided by the plugin at runtime. To achieve this you can provide an additional plugin description file to be merged with the generated file.
The Plugin Description Generator (PDGen) is located in <ADTF_DIR>/bin/
and <ADTF_DIR>/bin/debug
respectively.
For a more technical explanation please follow this link
To connect your code with ADTF you can choose from one of these interfaces:
All begins with a plugin. The SDK provides the ADTF_PLUGIN
macro to connect your code
with the ADTF world. The macro requires two parameters. The first parameter is the name of your new
plugin. The second parameter is the name of the new class representing the plugin. The macro is used like this:
ADTF_PLUGIN("ADTF Demo Signal Provider Plugin", cMySignalProviderFilter);
*.adtfplugin
that represents
your code as a shared library which ADTF can load at runtime. To make your new plugin available
inside the Configuration Editor, you need an XML based description, which the Plugindescription Generator
can create for you:
adtf_plugin_description_generator.exe -plugin="demo_data_triggered_filter.adtfplugin"
*.plugindescription
looks like:The recommended way to call the PDGen is via the CMake function adtf_create_plugindescription
.
For further reference see the function definition and documentation in <ADTF_DIR>/ADTFMacros.cmake
.
Example usage:
adtf_add_filter(MyFilter my_filter.cpp my_filter.h)
...
adtf_create_plugindescription(
TARGET MyFilter
PLUGIN_SUBDIR "bin"
VERSION "0.8.15"
LICENSE "ADTF"
SUPPORT_MAIL "support@mycompany.org"
HOMEPAGE_URL "www.mycompany.org"
)
If your adtfplugin requires addtional libraries during runtime, you can specify the dependencies by using DEPENDENT_DYNAMIC_LIBS
.
Example usage:
adtf_create_plugindescription(
TARGET MyFilter
PLUGIN_SUBDIR "bin"
VERSION "0.8.15"
LICENSE "ADTF"
SUPPORT_MAIL "support@mycompany.org"
HOMEPAGE_URL "www.mycompany.org"
DEPENDENT_DYNAMIC_LIBS
"path/to/some_lib.dll"
"path/to/another_lib.dll"
)
As described in our guide for generating plugin descriptions
you can use MERGE_DESCRIPTION
option to define platform specific dependencies within the platform nodes
inside a plugin description file and merge these information automatic within your post build step.
Example usage:
adtf_create_plugindescription(
TARGET MyFilter
PLUGIN_SUBDIR "bin"
VERSION "0.8.15"
LICENSE "ADTF"
SUPPORT_MAIL "support@mycompany.org"
HOMEPAGE_URL "www.mycompany.org"
MERGE_DESCRIPTION
"path/to/platform_dependencies.plugindescription"
)
Please see the output of a call with --help
for all available command line options.
adtf_plugin_description_generator
Usage:
adtf_plugin_description_generator -h
adtf_plugin_description_generator -p <pluginfile> [-m <mergefile>] [-o <outputfile>]
[--adtf-core-plugin <adtfcorepluginfile>] [--no-system] [--ignore-state-errors] [--system
<adtfsystemfile>] [--settings <cesettingsfile>] [--plugin-version <major.minor.patch>]
[--license-name <name>] [--support-mail <email address>] [--homepage-url <name>]
[--issue-url <name>] [--plugin-directory <plugindirectory>]... [--dynamic-link
<sharedlibrary>]... [--platform-dep <sharedlibrary>]... [--platform-dep-release
<sharedlibrary>]... [--platform-dep-debug <sharedlibrary>]...
Options:
-h, --help Print the usage info and quit.
-p, --plugin <pluginfile>
Path to the .adtfplugin
-m, --merge <mergefile>
Path to the .plugindescription which will be merged
-o, --output <outputfile>
Path to the resulting .plugindescription file
--adtf-core-plugin <adtfcorepluginfile>
Path to adtf_core.adtfplugin (EXPERIMENTAL)
--no-system Do not load an adtfsystem file at all.
--ignore-state-errors
Ignore errors from changing the state of graph objects to 'constructed'.
--system <adtfsystemfile>
Path to a .adtfsystem file. Providing additional platform dependencies, services
and plugins (EXPERIMENTAL)
--settings <cesettingsfile>
(EXPERIMENTAL)
--plugin-version <major.minor.patch>
Plugin version that should be stored in the generated description.
--license-name <name>
License name that should be stored in the generated description.
--support-mail <email address>
Support mail address that should be stored in the generated description.
--homepage-url <name>
Homepage URL that should be stored in the generated description.
--issue-url <name>
Bug/Issue tracker URL that should be stored in the generated description.
--plugin-directory <plugindirectory>
A path containing additional .plugins (EXPERIMENTAL)
--dynamic-link <sharedlibrary>
A shared library to be loaded before loading the plugin during description
generation.
--platform-dep <sharedlibrary>
A shared library to be loaded before loading the plugin within ADTF, both
release and debug
--platform-dep-release <sharedlibrary>
A shared library to be loaded before loading the plugin within ADTF, release
only
--platform-dep-debug <sharedlibrary>
A shared library to be loaded before loading the plugin within ADTF, debug only
Now you know a lot about setting up an ADTF Session but what about manipulating it without UI ? Let's have a look at ADTF Config Tool.