Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • eclipse/openpass/mantle-api
  • adascri/scenario_api
  • jtschea/scenario_api
  • mstump/mantle-api
  • xiaopan/scenario_api
  • AndreasB/scenario_api
  • kcantero/scenario_api
  • dweiwg6/scenario_api
  • shankarpatali/mantle-api
  • etiennep/mantle-api
  • nutario/mantle-api
  • rbiegel/mantle-api
  • nmraghu/mantle-api
  • rparisha2/mantle-api
  • naidagoro/mantle-api
  • kim10101/mantle-api
  • mbehrischv52/mantle-api
  • khbner/mantle-api
  • lappino/mantle-api
  • anastasiiavolkova/mantle-api
  • daniilnikulin/mantle-api
  • mkellerer/mantle-api
22 results
Show changes
Commits on Source (175)
build --cxxopt='-std=c++17'
7.2.1
......@@ -6,3 +6,4 @@ BinPackArguments: false
BinPackParameters: false
BreakBeforeBraces: Allman
ColumnLimit: 0
InsertNewlineAtEOF: true
---
Checks: >
-*,
boost-*,
bugprone-*,
cppcoreguidelines-*,
-cppcoreguidelines-non-private-member-variables-in-classes,
-cppcoreguidelines-special-member-functions,
google-*,
-google-build-using-namespace,
-google-default-arguments,
-google-readability-todo,
llvm-*,
misc-*,
-misc-non-private-member-variables-in-classes,
modernize-*,
-modernize-use-trailing-return-type,
performance-*,
readability-*,
-readability-identifier-naming,
-readability-magic-numbers
FormatStyle: file
CheckOptions:
- key: readability-identifier-naming.ClassCase
value: CamelCase
- key: readability-identifier-naming.ClassMemberCase
value: lower_case
- key: readability-identifier-naming.ClassMemberSuffix
value: _
- key: readability-identifier-naming.ClassMethodCase
value: CamelCase
- key: readability-identifier-naming.ConstantCase
value: CamelCase
- key: readability-identifier-naming.ConstantPrefix
value: k
- key: readability-identifier-naming.ConstexprVariableCase
value: CamelCase
- key: readability-identifier-naming.ConstexprVariablePrefix
value: k
- key: readability-identifier-naming.EnumCase
value: CamelCase
- key: readability-identifier-naming.EnumConstantCase
value: CamelCase
- key: readability-identifier-naming.EnumConstantPrefix
value: k
- key: readability-identifier-naming.FunctionCase
value: CamelCase
- key: readability-identifier-naming.GlobalVariableCase
value: CamelCase
- key: readability-identifier-naming.GlobalVariablePrefix
value: g
- key: readability-identifier-naming.NamespaceCase
value: lower_case
- key: readability-identifier-naming.ParameterCase
value: lower_case
- key: readability-identifier-naming.StaticConstantCase
value: CamelCase
- key: readability-identifier-naming.StaticConstantPrefix
value: k
- key: readability-identifier-naming.StructCase
value: CamelCase
- key: readability-identifier-naming.TemplateParameterCase
value: CamelCase
- key: readability-identifier-naming.VariableCase
value: lower_case
- key: readability-identifier-length.IgnoredVariableNames
value: "^(id|it)$"
- key: readability-identifier-length.IgnoredParameterNames
value: "^(d|id|os)$"
......@@ -14,12 +14,14 @@ command_case: canonical
keyword_case: upper
additional_commands:
CPMAddPackage:
pargs: "*"
kwargs:
NAME: "*"
GITHUB_REPOSITORY: "*"
GIT_TAG: "*"
VERSION: "*"
OPTIONS: "*"
PATCH_COMMAND: "*"
configure_package_config_file:
flags:
- NO_SET_AND_CHECK_MACRO
......
......@@ -18,7 +18,7 @@ cc_library(
cc_library(
name = "test_utils",
hdrs = ["test/MantleAPI/Test/test_utils.h"],
hdrs = glob(["test/**/*.h"]),
includes = ["test"],
visibility = ["//visibility:public"],
deps = [
......@@ -30,6 +30,6 @@ cc_library(
cc_test(
name = "interface_test",
timeout = "short",
srcs = ["test/interface_test.cpp"],
srcs = ["test/interface_test.cpp"] + glob(["test/**/*.cc"]),
deps = [":test_utils"],
)
......@@ -25,7 +25,7 @@ endif()
project(
MantleAPI
VERSION 0.1.0
DESCRIPTION "MantleAPI, an abstraction layer for environmental simulators"
DESCRIPTION "An abstraction layer for environmental simulators"
LANGUAGES CXX
)
......@@ -37,6 +37,9 @@ option(MantleAPI_PACKAGE "Generate the package target." ${MantleAPI_MAIN_PROJECT
option(MantleAPI_ENABLE_WARNINGS "Enable compiler warnings." ${MantleAPI_MAIN_PROJECT})
option(MantleAPI_ENABLE_WERROR "Fail and stop if a warning is triggered." ${MantleAPI_MAIN_PROJECT})
include(CMakeDependentOption)
cmake_dependent_option(MantleAPI_INSTALL_MOCKS "Install the mocks." OFF "MantleAPI_INSTALL;MantleAPI_TEST" ON)
if(MSVC)
if(MantleAPI_ENABLE_WARNINGS)
add_compile_options(/W4)
......@@ -58,36 +61,20 @@ include(CPM)
CPMAddPackage(
NAME units
GITHUB_REPOSITORY nholthaus/units
GIT_TAG v2.3.3
VERSION 2.3.3
OPTIONS "DISABLE_PREDEFINED_UNITS ON"
"ENABLE_PREDEFINED_ACCELERATION_UNITS ON"
"ENABLE_PREDEFINED_ANGLE_UNITS ON"
"ENABLE_PREDEFINED_ANGULAR_VELOCITY_UNITS ON"
"ENABLE_PREDEFINED_CONCENTRATION_UNITS ON"
"ENABLE_PREDEFINED_FORCE_UNITS ON"
"ENABLE_PREDEFINED_LENGTH_UNITS ON"
"ENABLE_PREDEFINED_MASS_UNITS ON"
"ENABLE_PREDEFINED_PRESSURE_UNITS ON"
"ENABLE_PREDEFINED_TEMPERATURE_UNITS ON"
"ENABLE_PREDEFINED_TIME_UNITS ON"
"ENABLE_PREDEFINED_VELOCITY_UNITS ON"
VERSION 2.3.4
)
# Add library
file(
GLOB_RECURSE HEADERS
RELATIVE ${PROJECT_SOURCE_DIR}/include
CONFIGURE_DEPENDS "*.h"
)
add_library(MantleAPI INTERFACE)
add_library(MantleAPI::MantleAPI ALIAS MantleAPI)
target_link_libraries(MantleAPI INTERFACE units::units)
include(GNUInstallDirs)
set(INSTALL_CONFIG_DIR "${CMAKE_INSTALL_LIBDIR}/cmake/MantleAPI")
set(MantleAPI_INSTALL_CONFIG_DIR
"${CMAKE_INSTALL_LIBDIR}/cmake/MantleAPI"
CACHE STRING "Installation directory for CMake package config files"
)
target_include_directories(
MantleAPI INTERFACE $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
......@@ -95,11 +82,27 @@ target_include_directories(
target_compile_features(MantleAPI INTERFACE cxx_std_17)
# Build docs
if(MantleAPI_DOC)
add_subdirectory(doc)
endif()
# Build tests
if(MantleAPI_TEST)
file(
GLOB_RECURSE INTERFACE_HEADER_SET
RELATIVE "${PROJECT_SOURCE_DIR}/include"
CONFIGURE_DEPENDS "include/MantleAPI/**/*.h"
)
enable_testing()
add_subdirectory(test)
endif()
# Configure export
include(CMakePackageConfigHelpers)
configure_package_config_file(
"${PROJECT_SOURCE_DIR}/cmake/MantleAPIConfig.cmake.in" "${PROJECT_BINARY_DIR}/MantleAPIConfig.cmake"
INSTALL_DESTINATION ${INSTALL_CONFIG_DIR}
INSTALL_DESTINATION ${MantleAPI_INSTALL_CONFIG_DIR}
PATH_VARS CMAKE_INSTALL_INCLUDEDIR
)
......@@ -116,28 +119,17 @@ if(MantleAPI_INSTALL)
install(
EXPORT MantleAPITargets
DESTINATION ${INSTALL_CONFIG_DIR}
DESTINATION ${MantleAPI_INSTALL_CONFIG_DIR}
NAMESPACE MantleAPI::
)
install(
FILES "${PROJECT_BINARY_DIR}/MantleAPIConfig.cmake" "${PROJECT_BINARY_DIR}/MantleAPIConfigVersion.cmake"
DESTINATION ${INSTALL_CONFIG_DIR}
DESTINATION ${MantleAPI_INSTALL_CONFIG_DIR}
COMPONENT dev
)
endif()
# Build docs
if(MantleAPI_DOC)
add_subdirectory(doc)
endif()
# Build tests
if(MantleAPI_TEST)
enable_testing()
add_subdirectory(test)
endif()
# Configure package
if(MantleAPI_PACKAGE)
include(MantleAPICPack)
......
# Community Code of Conduct
**Version 2.0
January 1, 2023**
## Our Pledge
In the interest of fostering an open and welcoming environment, we as community members, contributors, Committers[^1], and Project Leads (collectively "Contributors") pledge to make participation in our projects and our community a harassment-free and inclusive experience for everyone.
This Community Code of Conduct ("Code") outlines our behavior expectations as members of our community in all Eclipse Foundation activities, both offline and online. It is not intended to govern scenarios or behaviors outside of the scope of Eclipse Foundation activities. Nor is it intended to replace or supersede the protections offered to all our community members under the law. Please follow both the spirit and letter of this Code and encourage other Contributors to follow these principles into our work. Failure to read or acknowledge this Code does not excuse a Contributor from compliance with the Code.
## Our Standards
Examples of behavior that contribute to creating a positive and professional environment include:
- Using welcoming and inclusive language;
- Actively encouraging all voices;
- Helping others bring their perspectives and listening actively. If you find yourself dominating a discussion, it is especially important to encourage other voices to join in;
- Being respectful of differing viewpoints and experiences;
- Gracefully accepting constructive criticism;
- Focusing on what is best for the community;
- Showing empathy towards other community members;
- Being direct but professional; and
- Leading by example by holding yourself and others accountable
Examples of unacceptable behavior by Contributors include:
- The use of sexualized language or imagery;
- Unwelcome sexual attention or advances;
- Trolling, insulting/derogatory comments, and personal or political attacks;
- Public or private harassment, repeated harassment;
- Publishing others' private information, such as a physical or electronic address, without explicit permission;
- Violent threats or language directed against another person;
- Sexist, racist, or otherwise discriminatory jokes and language;
- Posting sexually explicit or violent material;
- Sharing private content, such as emails sent privately or non-publicly, or unlogged forums such as IRC channel history;
- Personal insults, especially those using racist or sexist terms;
- Excessive or unnecessary profanity;
- Advocating for, or encouraging, any of the above behavior; and
- Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
With the support of the Eclipse Foundation employees, consultants, officers, and directors (collectively, the "Staff"), Committers, and Project Leads, the Eclipse Foundation Conduct Committee (the "Conduct Committee") is responsible for clarifying the standards of acceptable behavior. The Conduct Committee takes appropriate and fair corrective action in response to any instances of unacceptable behavior.
## Scope
This Code applies within all Project, Working Group, and Interest Group spaces and communication channels of the Eclipse Foundation (collectively, "Eclipse spaces"), within any Eclipse-organized event or meeting, and in public spaces when an individual is representing an Eclipse Foundation Project, Working Group, Interest Group, or their communities. Examples of representing a Project or community include posting via an official social media account, personal accounts, or acting as an appointed representative at an online or offline event. Representation of Projects, Working Groups, and Interest Groups may be further defined and clarified by Committers, Project Leads, or the Staff.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Conduct Committee via conduct@eclipse-foundation.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. Without the explicit consent of the reporter, the Conduct Committee is obligated to maintain confidentiality with regard to the reporter of an incident. The Conduct Committee is further obligated to ensure that the respondent is provided with sufficient information about the complaint to reply. If such details cannot be provided while maintaining confidentiality, the Conduct Committee will take the respondent‘s inability to provide a defense into account in its deliberations and decisions. Further details of enforcement guidelines may be posted separately.
Staff, Committers and Project Leads have the right to report, remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code, or to block temporarily or permanently any Contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. Any such actions will be reported to the Conduct Committee for transparency and record keeping.
Any Staff (including officers and directors of the Eclipse Foundation), Committers, Project Leads, or Conduct Committee members who are the subject of a complaint to the Conduct Committee will be recused from the process of resolving any such complaint.
## Responsibility
The responsibility for administering this Code rests with the Conduct Committee, with oversight by the Executive Director and the Board of Directors. For additional information on the Conduct Committee and its process, please write to <conduct@eclipse-foundation.org>.
## Investigation of Potential Code Violations
All conflict is not bad as a healthy debate may sometimes be necessary to push us to do our best. It is, however, unacceptable to be disrespectful or offensive, or violate this Code. If you see someone engaging in objectionable behavior violating this Code, we encourage you to address the behavior directly with those involved. If for some reason, you are unable to resolve the matter or feel uncomfortable doing so, or if the behavior is threatening or harassing, please report it following the procedure laid out below.
Reports should be directed to <conduct@eclipse-foundation.org>. It is the Conduct Committee’s role to receive and address reported violations of this Code and to ensure a fair and speedy resolution.
The Eclipse Foundation takes all reports of potential Code violations seriously and is committed to confidentiality and a full investigation of all allegations. The identity of the reporter will be omitted from the details of the report supplied to the accused. Contributors who are being investigated for a potential Code violation will have an opportunity to be heard prior to any final determination. Those found to have violated the Code can seek reconsideration of the violation and disciplinary action decisions. Every effort will be made to have all matters disposed of within 60 days of the receipt of the complaint.
## Actions
Contributors who do not follow this Code in good faith may face temporary or permanent repercussions as determined by the Conduct Committee.
This Code does not address all conduct. It works in conjunction with our [Communication Channel Guidelines](https://www.eclipse.org/org/documents/communication-channel-guidelines/), [Social Media Guidelines](https://www.eclipse.org/org/documents/social_media_guidelines.php), [Bylaws](https://www.eclipse.org/org/documents/eclipse-foundation-be-bylaws-en.pdf), and [Internal Rules](https://www.eclipse.org/org/documents/ef-be-internal-rules.pdf) which set out additional protections for, and obligations of, all contributors. The Foundation has additional policies that provide further guidance on other matters.
It’s impossible to spell out every possible scenario that might be deemed a violation of this Code. Instead, we rely on one another’s good judgment to uphold a high standard of integrity within all Eclipse Spaces. Sometimes, identifying the right thing to do isn’t an easy call. In such a scenario, raise the issue as early as possible.
## No Retaliation
The Eclipse community relies upon and values the help of Contributors who identify potential problems that may need to be addressed within an Eclipse Space. Any retaliation against a Contributor who raises an issue honestly is a violation of this Code. That a Contributor has raised a concern honestly or participated in an investigation, cannot be the basis for any adverse action, including threats, harassment, or discrimination. If you work with someone who has raised a concern or provided information in an investigation, you should continue to treat the person with courtesy and respect. If you believe someone has retaliated against you, report the matter as described by this Code. Honest reporting does not mean that you have to be right when you raise a concern; you just have to believe that the information you are providing is accurate.
False reporting, especially when intended to retaliate or exclude, is itself a violation of this Code and will not be accepted or tolerated.
Everyone is encouraged to ask questions about this Code. Your feedback is welcome, and you will get a response within three business days. Write to <conduct@eclipse-foundation.org>.
## Amendments
The Eclipse Foundation Board of Directors may amend this Code from time to time and may vary the procedures it sets out where appropriate in a particular case.
### Attribution
This Code was inspired by the [Contributor Covenant](https://www.contributor-covenant.org/), version 1.4, available [here](https://www.contributor-covenant.org/version/1/4/code-of-conduct/).
[^1]: Capitalized terms used herein without definition shall have the meanings assigned to them in the Bylaws.
# Contributing to Eclipse openPASS
This guide provides all necessary information to enable [contributors and committers](https://www.eclipse.org/projects/dev_process/#2_3_1_Contributors_and_Committers) to contribute to Eclipse openPASS.
## Eclipse openPASS
Eclipse openPASS provides a software platform that enables the simulation of traffic scenarios to predict the real-world effectiveness of advanced driver assistance systems or automated driving functions.
## Developer resources
* [Working Group Website](https://openpass.eclipse.org/)
* [Developer Website](https://projects.eclipse.org/projects/automotive.openpass)
* [Development process](https://gitlab.eclipse.org/groups/eclipse/openpass/-/wikis/home)
* Mailing list: Join our [developer list](httphttps://projects.eclipse.org/projects/automotive.openpass/contact)
* Bugs can be reported in [GitLab](https://gitlab.eclipse.org/groups/eclipse/openpass/-/issues/?sort=updated_desc&state=opened&first_page_size=100) by anybody who owns an Eclipse account. Please use type “Incident”
* [Documentation](https://openpass.eclipse.org/resources/#documentation)
## Eclipse Contributor / Committer Agreement
Before your contribution can be accepted by the project team, contributors and committers must sign the correct agreement depending on their status. Please read on how to proceed on: https://www.eclipse.org/legal/committer_process/re-sign/.
For more information, please see the Eclipse Committer Handbook: https://www.eclipse.org/projects/handbook/#resources-commit.
## Contact
Contact the project developers via the project's "dev" list.
* openpass-dev@eclipse.org
## How to contribute
The openPASS source code can be found [here](https://gitlab.eclipse.org/eclipse/openpass/opSimulation).
The branch 'develop' contains the contributions that will be included in the next release. The 'main' branch contains the latest stable release.
A detailed development process can be found [here](https://gitlab.eclipse.org/groups/eclipse/openpass/-/wikis/home).
# Notices for Eclipse openpass
This content is produced and maintained by the Eclipse openpass project.
* Project home: https://projects.eclipse.org/projects/automotive.openpass
## Copyright
All content is the property of the respective authors or their employers.
For more information regarding authorship of content, please consult the
listed source code repository logs.
## Declared Project Licenses
This program and the accompanying materials are made available under the terms
of the Eclipse Public License v. 2.0 which is available at
https://www.eclipse.org/legal/epl-2.0/.
SPDX-License-Identifier: EPL-2.0
## Source Code
The project maintains the following source code repositories:
* https://gitlab.eclipse.org/eclipse/openpass/mantle-api
## Third-party Content
Open Simulation Interface (3.5.0)
* License: MPL-2.0
* Source: https://github.com/OpenSimulationInterface/open-simulation-interface
Google Protobuf (3.20.0)
* License: New BSD License
* Source: https://github.com/protocolbuffers/protobuf
Boost library (1.74.0)
* License: Boost Software License
* Project: https://www.boost.org/
* Source: https://www.boost.org/users/download/
Google Test (1.13.0)
* License: New BSD License
* Source: https://github.com/google/googletest
Modelon FMILibrary (2.0.3)
* License: New BSD License
* Source: https://github.com/modelon-community/fmi-library
## Cryptography
Content may contain encryption software. The country in which you are currently
may have restrictions on the import, possession, and use, and/or re-export to
another country, of encryption software. BEFORE using any encryption software,
please check the country's laws, regulations and policies concerning the import,
possession, or use, and re-export of encryption software, to see if this is
permitted.
# MantleAPI
A collection of interfaces for abstraction between a scenario engine and an environment simulator.
It is intended to be usable with a wide variety of scenario description languages by implementing according scenario engines.
Remark: This is currently work in progress and no stable state is reached yet.
## Used libraries
### Units
License: MIT License
URL: https://github.com/nholthaus/units
Version: v2.3.3
### GoogleTest
License: BSD-3-Clause License
URL: https://github.com/google/googletest
Version: v1.12.1
### CPM
License: MIT License
URL: https://github.com/cpm-cmake/CPM.cmake
Version: v0.36.0
# MantleAPI
A collection of interfaces for abstraction between a scenario engine and an environment simulator.
It is intended to be usable with a wide variety of scenario description languages by implementing according scenario engines.
❗️ This is currently work in progress and no stable state is reached yet.
## Build
In order to build this project please consider the following sections.
The used configuration for all setups is `Debug`. For release builds change the configuration to `Release`.
### Ubuntu native or wsl2 (preferred)
1. ⚙️ Install requirements
sudo apt-get -y update && sudo apt-get -y install \
build-essential \
cmake \
doxygen \
graphviz \
ninja-build \
plantuml
2. 🛠️ Configure, build, and install
cd <path/to/mantle_api>
cmake -B build -GNinja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=$PWD/install
cmake --build build
cmake --install build
3. 📄 Build docs
cd <path/to/mantle_api>
cmake --build build --target MantleAPI_doc
cat <path/to/mantle_api>/build/doc/html/index.html
4. 🧪 Run tests
cd <path/to/mantle_api>/build
ctest --stop-on-failure
CTest runs the tests from both build targets: `CommonTest` and `MantleAPITest`.
### Windows mingw with cmake
This section introduces a step by step guide to install the requirements to build this API with mingw tooling.
Requirements:
- Follow the following guide to set up the mingw64 shell and the required dependencies (cmake, gcc, ninja, doxygen, graphviz): https://www.eclipse.org/openpass/content/html/installation_guide/20_install_prerequisites.html#installing-the-binary-packages
Build via cmake (on a mingw console):
1. Go to the project dir: `cd <project_dir>`
2. Build via cmake:
```
mkdir build
cd build
cmake -G "Ninja" ..
ninja
```
3. Test the API
```
cd <path_to_mantle_api>/build/test
./MantleAPITest.exe
```
4. Build Doc:
```
cd <path_to_mantle_api>/build
cmake --build . --target MantleAPI_doc
```
### Windows native with cmake
This section introduces a step by step guide to install the requirements to build this API with native tooling.
Requirements:
- install CMake: https://cmake.org/install/
- install Visual Studio build tools 2022: https://visualstudio.microsoft.com/downloads/#remote-tools-for-visual-studio-2022
- install Doxygen: https://www.doxygen.nl/download.html
- install Graphviz: https://graphviz.org/download/
Add doxygen, graphiz, and cmake to at least the current users PATH variable.
1. Configure:
```
cmake.exe --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\Llvm\bin\clang.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\Llvm\bin\clang.exe" -S<path_to_mantle_api> -B<path_to_mantle_api>/build -G Ninja
```
2. Build:
```
cmake.exe --build <path_to_mantle_api>/build --config Debug --target all --
```
3. Run Tests:
Common Test:
```
$> ."<path_to_mantle_api>/build/CommonTest.exe"
Running main() from gmock_main.cc
...
```
Mantle API Test:
```
$> ."<path_to_mantle_api>/build/MantleAPITest.exe"
Running main() from gmock_main.cc
...
```
4. Build Doc:
```
cmake.exe --build <path_to_mantle_api>/build --config Debug --target MantleAPI_doc --
```
The generated html doc is located here: `<path_to_mantle_api>/build/doc/html/index.html`
## Usage in your own project with cmake
1. Adding it to your own CMakeLists.txt similar to:
```cmake
# add mantle to your application
find_package(MantleAPI REQUIRED)
add_executable(MyAppUsingMantle main.cpp)
target_link_libraries(MyAppUsingMantle MantleAPI::MantleAPI)
# add mocks for testing (see option MantleAPI_INSTALL_MOCKS)
enable_testing()
add_executable(MyAppUsingMantleTest my_app_using_mantle_tests.cpp)
target_link_libraries(MyAppUsingMantleTest MantleAPI::Mocks)
```
_For an example of how to integrate testing using googletest, see also [test/CMakeLists.txt](test/CMakeLists.txt)._
2. Then make sure that your cmake call finds mantle-api like this:
```
cmake -DCMAKE_PREFIX_PATH=<path_to_mantle_api>
```
## Developer Notes
### Versioning
Versioning follows the [semantic versioning pattern](https://semver.org/) `MAJOR.MINOR.PATCH`.
Currently this is a manual task that needs to be approved as a part of a code review.
In the following a course guideline is given, when to increment the according fields:
**Major:**
- Even minor changes to a public header will most likely result in an increase of this number (= breaking change).
As this is probably the most common case MAJOR will therefore be incremented relatively frequently compared to other libraries.
**Minor:**
- Increments, if changes are ABI compatible, i.e. independent of the rest of other mantle definitions.
It is expected that this does not happen very often at the current state of development.
- Features related to testing, such as enhancing mocks, adding tests etc.
- Features related to chore tasks, such as CI scripts, CMake enhancements, formatters, etc.
**Patch:**
- Fixing typos in the documentation (as long as they don't change the semantics of a function call!)
- Fixing bugs related to testing
- Fixing bugs related to chore tasks
## Third party
| Name | License | Version |
|--------------------------------------------------------------------|--------------|---------|
| [CPM](https://github.com/cpm-cmake/CPM.cmake) | MIT | 0.40.5 |
| [Doxygen Awesome](https://github.com/jothepro/doxygen-awesome-css) | MIT | 2.3.4 |
| [GoogleTest](https://github.com/google/googletest) | BSD-3-Clause | 1.15.2 |
| [Units](https://github.com/nholthaus/units) | MIT | 2.3.4 |
<!--- https://www.eclipse.org/security/ --->
_ISO 27005 defines vulnerability as:
"A weakness of an asset or group of assets that can be exploited by one or more threats."_
## The Eclipse Security Team
The Eclipse Security Team provides help and advice to Eclipse projects
on vulnerability issues and is the first point of contact
for handling security vulnerabilities.
Members of the Security Team are committers on Eclipse Projects
and members of the Eclipse Architecture Council.
Contact the [Eclipse Security Team](mailto:security@eclipse.org).
**Note that, as a matter of policy, the security team does not open attachments.**
## Reporting a Security Vulnerability
Vulnerabilities can be reported either via email to the Eclipse Security Team
or directly with a project via the Eclipse Foundation's Bugzilla instance.
The general security mailing list address is security@eclipse.org.
Members of the Eclipse Security Team will receive messages sent to this address.
This address should be used only for reporting undisclosed vulnerabilities;
regular issue reports and questions unrelated to vulnerabilities in Eclipse software
will be ignored.
Note that this email address is not encrypted.
The community is also encouraged to report vulnerabilities using the
[Eclipse Foundation's Bugzilla instance](https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Vulnerability%20Reports&keywords=security&groups=Security_Advisories).
Note that you will require an Eclipse Foundation account to create an issue report,
but by doing so you will be able to participate directly in the resolution of the issue.
Issue reports related to vulnerabilities must be marked as "committers-only",
either automatically by clicking the provided link, by the reporter,
or by a committer during the triage process.
Note that issues marked "committers-only" are visible to all Eclipse committers.
By default, a "committers-only" issue is also accessible to the reporter
and individuals explicitly indicated in the "cc" list.
## Disclosure
Disclosure is initially limited to the reporter and all Eclipse Committers,
but is expanded to include other individuals, and the general public.
The timing and manner of disclosure is governed by the
[Eclipse Security Policy](https://www.eclipse.org/security/policy.php).
Publicly disclosed issues are listed on the
[Disclosed Vulnerabilities Page](https://www.eclipse.org/security/known.php).
This document serves as a foundational reference for all contributors.
Any modifications to this document or related files (such as .clang-format) require approval from the primary contributors.
To propose changes, please submit an issue along with a corresponding merge request.
[TOC]
# Foundation
- Use C++17
- Do not use special compiler extensions (e.g. specific gcc attributes)
# Code Organization
- Put mantle related definitions into the namespace `mantle_api`.
# Documentation
- Use doxygen for documentation
- Use tripple slash notation `/// Docs look like this`
- Don't use brief (automatic by default)
- Prefere imperative style for descriptions (`/// Set Position` - not `/// Sets the Position`)
- Document everything, i.e. also private members and indiviudal values of an enumeration.
- Use inline style for members and values (`int my_value ///< goes here`)
# Testing
- We use googletest
- Provide a mock for each interface
- Each interface (mock) must be referenced in a test
# 🦾 CI Enforced Conventions
We don't use git hooks, but our CI checks our rules.
## C++
- **Compiler Flags**: We treat warnings as errors. For the rest see [`CMakeLists.txt`](CMakeLists.txt)
- **Static Code Analysis**:
- We use [`.clang-tidy`](.clang-tidy) and don't accept any warnings/errors
- ⚠️ There are adjusted rules for testing [`test/.clang-tidy`](test/.clang-tidy)
- **Naming**: Also covered through [`.clang-tidy`](.clang-tidy) → Rule `readability-identifier-naming`
- **Formatting**: [`.clang-format`](.clang-format) → It's best, when you format on safe using the same rules.
- **Documentation**: We use a generated `Doxyfile` (see [`doc/CmakeLists.txt`](doc/CmakeLists.txt))
## CMake
- **Formatting**: [`.cmake-format`](.cmake-format)
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("//bazel:deps.bzl", "mantle_api_deps")
http_archive(
name = "googletest",
sha256 = "7b42b4d6ed48810c5362c265a17faebe90dc2373c885e5216439d37927f02926",
strip_prefix = "googletest-1.15.2",
url = "https://github.com/google/googletest/archive/refs/tags/v1.15.2.tar.gz",
)
mantle_api_deps()
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("@bazel_tools//tools/build_defs/repo:utils.bzl", "maybe")
ECLIPSE_GITLAB = "https://gitlab.eclipse.org/eclipse"
UNITS_TAG = "2.3.4"
def mantle_api_deps():
"""Load dependencies"""
maybe(
http_archive,
name = "units_nhh",
url = "https://github.com/nholthaus/units/archive/refs/tags/v{tag}.tar.gz".format(tag = UNITS_TAG),
sha256 = "e7c7d307408c30bfd30c094beea8d399907ffaf9ac4b08f4045c890f2e076049",
strip_prefix = "./units-{tag}".format(tag = UNITS_TAG),
build_file = "//bazel:units.BUILD",
)
cc_library(
name = "units_nhh",
hdrs = ["include/units.h"],
includes = [
"include/",
],
visibility = ["//visibility:public"],
)
set(CPM_DOWNLOAD_VERSION 0.36.0)
# SPDX-License-Identifier: MIT
#
# SPDX-FileCopyrightText: Copyright (c) 2019-2023 Lars Melchior and contributors
set(CPM_DOWNLOAD_VERSION 0.40.5)
set(CPM_HASH_SUM "c46b876ae3b9f994b4f05a4c15553e0485636862064f1fcc9d8b4f832086bc5d")
if(CPM_SOURCE_CACHE)
set(CPM_DOWNLOAD_LOCATION "${CPM_SOURCE_CACHE}/cpm/CPM_${CPM_DOWNLOAD_VERSION}.cmake")
......@@ -10,12 +15,10 @@ endif()
# Expand relative path. This is important if the provided path contains a tilde (~)
get_filename_component(CPM_DOWNLOAD_LOCATION ${CPM_DOWNLOAD_LOCATION} ABSOLUTE)
if(NOT (EXISTS ${CPM_DOWNLOAD_LOCATION}))
message(STATUS "Downloading CPM.cmake to ${CPM_DOWNLOAD_LOCATION}")
file(DOWNLOAD
https://github.com/cpm-cmake/CPM.cmake/releases/download/v${CPM_DOWNLOAD_VERSION}/CPM.cmake
${CPM_DOWNLOAD_LOCATION}
)
endif()
file(DOWNLOAD
https://github.com/cpm-cmake/CPM.cmake/releases/download/v${CPM_DOWNLOAD_VERSION}/CPM.cmake
${CPM_DOWNLOAD_LOCATION} EXPECTED_HASH SHA256=${CPM_HASH_SUM}
)
include(${CPM_DOWNLOAD_LOCATION})
################################################################################
# Copyright (c) 2024 Mercedes-Benz Tech Innovation GmbH
#
# This program and the accompanying materials are made available under the terms
# of the Eclipse Public License 2.0 which is available at
# https://www.eclipse.org/legal/epl-2.0/
#
# SPDX-License-Identifier: EPL-2.0
################################################################################
find_file(PLANTUML_JAR plantuml.jar PATHS ${PLANTUML_JAR_PATH} ENV{PLANTUML_JAR_PATH} /usr/share/plantuml)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(PlantUML DEFAULT_MSG PLANTUML_JAR)
if(PlantUML_FOUND)
if(NOT TARGET PlantUML::PlantUML)
add_executable(PlantUML::PlantUML IMPORTED)
if(EXISTS "${PLANTUML_JAR}")
set_target_properties(PlantUML::PlantUML PROPERTIES IMPORTED_LOCATION "${PLANTUML_JAR}")
endif()
endif()
endif()
......@@ -14,6 +14,10 @@
include(CMakeFindDependencyMacro)
find_dependency(units)
if(@MantleAPI_INSTALL_MOCKS@)
find_dependency(GTest)
endif()
if(NOT TARGET MantleAPI::MantleAPI AND NOT MantleAPI_BINARY_DIR)
set_and_check(MantleAPI_INCLUDE_DIR "@PACKAGE_CMAKE_INSTALL_INCLUDEDIR@")
mark_as_advanced(MantleAPI_INCLUDE_DIR)
......