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
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);
*.adtfpluginthat 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:
The recommended way to call the PDGen is via the CMake function
For further reference see the function definition and documentation in
adtf_add_filter(MyFilter my_filter.cpp my_filter.h) ... adtf_create_plugindescription( TARGET MyFilter PLUGIN_SUBDIR "bin" )
If your adtfplugin requires addtional libraries during runtime, you can specify the dependencies by using
adtf_create_plugindescription( TARGET my_plugin PLUGIN_SUBDIR "path/to/bin/dir" 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
inside a plugin description file and merge these information automatic within your post build step.
adtf_create_plugindescription( TARGET my_plugin PLUGIN_SUBDIR "path/to/bin/dir" 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-directory <plugindirectory>]... [--dynamic-link <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-directory <plugindirectory> A path containing additional .plugins (EXPERIMENTAL) --dynamic-link <sharedlibrary> A shared library to be loaded before loading the plugin.
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.