Project Guide#
Project File Structure#
Here’s a high-level overview of the directory layout:
/build → output folder of all framework binaries, including examples and tests.
/doc → documentation files, based on sphinx.
/examples → sub 'repository', to be build it requires the framework binaries and framework header files.
/export → framework header files, together with the framework binaries allows to build new projects.
/framework_tests → sub 'repository', contains tests for the auto generated code, to be build it requires the framework binaries and framework header files.
/global → general framework code (anything except SDV execeutables, SDV services and tests).
/sdv_executables → framework source code for all framework executables.
/sdv_services → framework source code for all framework services.
/tests → contains source code for all framework tests.
/tmp_project → template project to setup a new work space so that nobody needs to put his new code inside the framework itself.
Here’s a overview of the build output layout:
/bin → framework binaries
/examples/bin → framework example binaries
/examples/system_demo_example/generated/fmu_DemoExampleFMU/fmus → fmu of system demo example
/framework_tests/bin → framework auto generated code test binaries
/tests/bin → framework test binaries
Each module is self-contained and follows a consistent naming and structure convention.
Deep Dive Into Examples#
First build the examples and then take your time to have a close look at the different examples.
Open Visual Studio Code.
Navigate to the Examples Directory.
Go to
File > Open Folder...
and select subfolder<your-project-directory>/examples
Replace
<your-project-directory>
with the path to your project directory.
Run CMake.
Do the same configuration and build steps as in Step 6.
Run executable:
After the compilation is complete, you can run the test examples generated in the build directory. The executable can be found in
<your-project-directory>/build/<selected-compiler-platform>/examples/bin
Note
<output-folder>/examples/bin
and can be executed:Examples: Learn how to use the framework to build SDV components
Contributing Guidelines#
Setup your own working space so that you do not need to put your code inside the framework layout. Instead you can place it anywhere you like by using
Environment variables
Attention
It is recommended to create a new root folder for your own projects. Do not add your code below the existing framework as the structure is not finalized yet. It will change in future!
To setup an own working space is easy:
Create the environment variables which are pointing the framework header files and binaries
SDV_FRAMEWORK_RUNTIME(…/build/<compiler>/bin)(sdv_control can be found there)The environment variable SDV_FRAMEWORK_RUNTIME needs to be pointing to the SDV V-API framework location!SDV_COMPONENT_INSTALL(…/build/<compiler>/bin)(sdv_packager can be found there)The environment variable SDV_COMPONENT_INSTALL needs to be pointing to the SDV V-API component installation location!SDV_FRAMEWORK_DEV_TOOLS(…/build/<compiler>/bin)(sdv_dbc_util can be found there)The environment variable SDV_FRAMEWORK_DEV_TOOLS needs to be pointing to the SDV V-API development tools location!SSDV V-API framework and SDV V-API development tools may be the same.SDV_FRAMEWORK_DEV_INCLUDE(…/export)The environment variable SDV_FRAMEWORK_DEV_INCLUDE needs to be pointing to the SDV V-API development include files location!
SDV_FRAMEWORK_RUNTIME …./build/msvc_x64_x64_ninja_debug/bin SDV_COMPONENT_INSTALL …./build/msvc_x64_x64_ninja_debug/bin SDV_FRAMEWORK_DEV_TOOLS …./build/msvc_x64_x64_ninja_debug/bin SDV_FRAMEWORK_DEV_INCLUDE …/export
Copy the tmp_project folder to any place you like. The tmp_project folder contains a CMakeLists.txt file and a subfolder already. Start your project directly in the subfolder. Use tmp_project folder as root folder.
Hint
Keep path names short. If you rename the subfolder or add more folders, then you have to update the CMakeLists.txt file in your root folder accordingly.
Follow the coding style outlined in docs/style-guide.md.
Write unit tests for new features or bug fixes.
Submit a pull request with a clear description of your changes.
Please ensure your code passes all tests and adheres to the formatting rules.
Reporting Issues#
If you encounter a bug or have a feature request:
Check if the issue already exists in the GitHub Issues.
If not, create a new issue with:
A descriptive title
Steps to reproduce
Expected vs. actual behavior
Environment details (OS, compiler, etc.)