Слияние кода завершено, страница обновится автоматически
Спасибо за интерес к этому проекту.
В таких областях, как автомобилестроение, робототехника или игры, между различными частями системы необходимо передавать огромное количество данных. Если эти части фактически представляют собой разные процессы в операционной системе на базе POSIX, такой как Linux, это огромное количество данных должно передаваться через механизм межпроцессного взаимодействия (IPC). Подробнее об этом можно узнать на сайте Eclipse.
Прежде чем ваш вклад будет принят командой проекта, участники должны подписать электронное соглашение участника Eclipse (ECA).
Коммиты, предоставленные не коммиттерами, должны иметь поле Signed-off-by в футере, указывающее, что автор знает о условиях, на которых вклад был предоставлен проекту. У не коммиттера также должен быть аккаунт в Eclipse Foundation и подписанное соглашение участника Eclipse (ECA).
Для получения дополнительной информации см. Справочник коммиттера Eclipse.
Свяжитесь с разработчиками проекта через список «dev» проекта.
Мы любим пул реквесты! В следующих разделах рассматриваются большинство соответствующих вопросов. Для более крупных вкладов или архитектурных изменений мы просим вас:
или
Если вы хотите сообщить об ошибке или предложить новую функцию, пожалуйста, поднимите вопрос перед тем, как поднимать пул реквест. Пожалуйста, проведите быстрый поиск заранее, если подобная проблема уже существует. Для приоритизации проблем для конкретного выпуска используется доска релизов, что упрощает отслеживание работы в процессе. Если у вас возникли проблемы с получением назначенной вам задачи, свяжитесь с сопровождающими через Gitter.
Пожалуйста, убедитесь, что вы:
Супер-пупер функция с номером вопроса 123
iox-[вопрос]-branch-name, например, iox-123-супер-пупер-функция
iox-#[вопрос] Сообщение коммита, например, iox-#123 Реализовать супер-пупер функцию
git commit -s
iceoryx-unreleased.md в doc/website/release-notes обновляется с GitHub вопросом, который закрыт пул реквестомmain
ПРИМЕЧАНИЕ: Для поддержки во время разработки вы можете использовать небольшие вспомогательные скрипты, см. git-hooks.
Большие функции или функции, где API ещё не ясен, могут быть реализованы с помощью флага функции IOX_EXPERIMENTAL_POSH. Эти функции не должны быть доступны в установленных заголовках, когда флаг функции IOX_EXPERIMENTAL_POSH не был установлен во время компиляции.
По возможности это должно быть достигнуто путём установки заголовков экспериментальной функции вместо ifdefs. С помощью этого подхода экспериментальные функции всё ещё могут быть собраны на всех целях на CI без указания флага функции IOX_EXPERIMENTAL_POSH и не требуют новых целей CI.
Экспериментальная функция должна находиться в пространстве имён experimental, а путь включения заголовка также должен содержать имя experimental.
Об экспериментальных функциях не следует упоминать в заметном месте, чтобы не побуждать пользователей использовать их, поскольку не будет поддержки сообщества и они могут быть удалены на более позднем этапе.
main
Если требуются конструкции, создающие предупреждения clang-tidy, их можно подавить с помощью обоснования и либо NOLINTNEXTLINE(warning-type), либо NOLINTBEGIN(warning-type) и NOLINTEND(warning-type).
Эти подавления всегда требуют обоснования, которое должно предоставляться с помощью NOLINTJUSTIFICATION. Но не повторяйте себя в обосновании. Если документация doxygen или подавление в заголовке для того же объявления уже содержит аргумент, пожалуйста, обратитесь к нему. Обоснование всегда должно указывать, почему подавленная конструкция необходима и как код обеспечивает безопасное использование.
Кроме того, NOLINTBEGIN следует использовать только для как можно меньшего диапазона и, возможно, для всей функции, но не более.
// NOLINTJUSTIFICATION нам требуется 'construct' для реализации XXX, а безопасное использование
// гарантируется через YYY
// NOLINTBEGIN(some-warning)
auto a = myLineOfCodeWithWarning();
Пожалуйста, используйте doxygen для документирования вашего кода.
Следующие комментарии doxygen необходимы для заголовков общедоступного API:
/// @brief краткое описание
/// @param[in] / [out] / [in,out] имя описание
/// @return описание
Для переопределения виртуальных методов можно использовать тег copydoc:
/// @copydoc BaseClass::method
/// @note Необязательно опишите некоторые особенности переопределения
Хороший пример форматирования кода и структуры doxygen можно найти в swe_docu_guidelines.md (WIP).
Внешние зависимости, такие как STL или другие библиотеки, должны быть сведены к минимуму для iceoryx_posh и iceoryx_hoofs. Если вы считаете, что новая зависимость необходима, выполните следующие действия:
tools/scripts/used-headers.txt, чтобы CI прошёл.В некоторых случаях код в конструкторе и операциях присваивания может быть сильно дублирован. Рекомендуется перенести этот дублированный код в отдельную функцию (например, copy_and_move_impl) для лучшего повторного использования. Кроме того, MoveAndCopyHelper в iceoryx/design (см. MoveAndCopyHelper) предлагает некоторые функции, которые упрощают этот процесс.
Структура папок сводится к следующему:
find_pkg()
Весь новый код должен соответствовать структуре папок.
doc/website/examples/foobar.md и добавьте его в doc/website/examples/.pages. Этот файл должен содержать только заголовок и включать ридми из /iceoryx_examples/foobar/README.md.add_subdirectory в iceoryx_meta/CMakeLists.txt в разделе if(EXAMPLES).Для наших модульных и интеграционных тестов мы используем Google Test (gtest). Требуется совместимость с версией 1.10.0.
Ознакомьтесь с нашими рекомендациями по передовой практике написания тестов и руководством по установке для участников для их создания.
Модульные тесты (они же модульные)
Модульные тесты — это тесты чёрного ящика, которые проверяют общедоступный интерфейс класса. Они требуются для всего нового кода.
Каждому тестовому случаю нужен уникальный идентификатор (UUID согласно RFC 4122) в форме:
::testing::Test::RecordProperty("TEST_ID", "12345678-9ab-cdef-fedc-1234567890ab");
UUID можно сгенерировать, например, с помощью Python или инструмента командной строки:
import uuid
uuid.uuid4()
uuidgen -r
В редких случаях вы можете захотеть исключить случай GoogleTest из выполнения (например, спорадические сбои). При этом вам нужно добавить вызов макроса сразу после идентификатора теста:
::testing::Test::RecordProperty("TEST_ID", "12345678-9ab-cdef-fedc-1234567890ac");
GTEST_SKIP() << "@todo iox-#1234 Enable test once the API is supported";
Необходимы техническая причина и действительный номер заявки для отслеживания повторного включения (или удаления) теста.
Интеграционные тесты
Интеграционные тесты проверяют взаимодействие нескольких классов. Они необязательны для нового кода.
Чтобы убедиться, что предоставленный тестовый код покрывает рабочий код, вы можете выполнить сканирование покрытия с помощью gcov. Отчётность выполняется с использованием lcov и htmlgen. Вам потребуется установить следующие пакеты:
sudo apt install lcov
У нас есть несколько уровней тестирования для покрытия тестами: unit, integration, component и all для всех уровней тестирования вместе. Вы можете создавать отчёты для этих различных уровней тестирования или для всех тестов. Покрытие осуществляется с помощью gcc. Сканирование покрытия применяется к уровню качества 3 и частично к уровню 2 с покрытием ветвей.
Чтобы создать отчёт о покрытии, iceoryx необходимо скомпилировать с флагами покрытия, а тесты должны быть выполнены. Вы можете сделать это одной командой в папке iceoryx, например:
./tools/iceoryx_build_test.sh clean build-all -c <testlevel>
При желании вы можете использовать опцию build-all, чтобы получить покрытие для расширений, таких как C-Binding. Флаг -c указывает, что вы хотите создать отчёт о покрытии и требует указать уровень тестирования. По умолчанию уровень тестирования установлен на all.
./tools/iceoryx_build_test.sh clean debug build-all -c unit
Примечание: iceoryx должен быть собран как статическая библиотека для работы с флагами gcov. Скрипт делает это автоматически.
Флаг -с unit предназначен для создания отчётов только для модульных тестов. В скрипте tools/scripts/lcov_generate.sh начальное сканирование, фильтрация и генерация отчётов выполняются автоматически.
Все отчёты хранятся локально в build/lcov в виде HTML-отчёта (index.html). В GitHub мы используем Codecov для общей отчётности о покрытии кода. Codecov даёт краткий обзор покрытия кода и также указывает в запросах на вытягивание, если вновь добавленный код не покрыт тестами. Если вы хотите увидеть подробные HTML-отчёты для конкретных запросов на вытягивание или веток, вы можете проверить здесь.
Разработчики iceoryx стремятся к соответствию ASIL-D. ISO26262 — хороший источник информации, если вы хотите узнать больше об автомобильной безопасности. На CppCon 2019 было представлено хорошее вводное видео.
Если вы хотите сообщить об уязвимости, пожалуйста, используйте процесс Eclipse.
Разработчики iceoryx имеют партнёрство с Axivion и используют их Axivion. Suite для запуска статического анализа кода.
Для группировки проблем по наборам правил используются метки Github:
| Набор правил | Метка Github | Приоритет |
|---|---|---|
| Adaptive AUTOSAR C++14 | AUTOSAR | :star::star::star: |
| SEI CERT C++ 2016 Coding Standard | CERT | :star::star: |
| MISRA C++ 2008 | MISRA |  |
Если одно из правил не соблюдается, добавляется обоснование следующим образом:
*mynullptr = foo; // AXIVION Same Line Ruleset-A1.2.3 : Краткое описание почему
// AXIVION Next Line Ruleset-A1.2.3 : Краткое описание почему
*mynullptr = foo;
Также можно подавить правило для всей конструкции:
// AXIVION Construct Ruleset-A1.2.3 : Краткое описание почему
class Foo
{
void doSomething()
{
// Do something useful
}
};
Каждый исходный файл должен иметь такой заголовок:
// Copyright (c) [ГОД НАЧАЛЬНОГО ВКЛАДА] - [ГОД ПОСЛЕДНЕГО ВКЛАДА] by [ВКЛАДЧИК]. Все права защищены.
//
// Лицензировано в соответствии с лицензией Apache версии 2.0 (далее «Лицензия»);
// вы не можете использовать этот файл, кроме как в соответствии с Лицензией.
// Вы можете получить копию Лицензии по адресу
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Если иное не требуется применимым законодательством или не согласовано в письменной форме, программное обеспечение,
// распространяемое в соответствии с настоящей Лицензией, распространяется на условиях «КАК ЕСТЬ»,
// БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ ЛЮБОГО РОДА, явных или подразумеваемых. См. Лицензию для конкретного языка, регулирующего разрешения и
// ограничения в рамках Лицензии.
//
// Идентификатор лицензии SPDX: Apache-2.0
Примечание: дата — это год или диапазон лет с разделением первого и последнего года диапазона дефисом. Например: «2004» (начальный и последний вклад в один и тот же год) или «2000–2004». Первый год — когда содержимое файла было впервые создано, а последний год — когда содержимое было последний раз изменено. Годы вклада должны быть упорядочены в хронологическом порядке, поэтому последняя дата в списке должна быть годом самого последнего вклада. Если между вкладами есть разрыв в один или несколько календарных лет, используйте запятую для разделения периодов вклада (например, «2000–2004, 2006»). Пример:
// Copyright (c) 2019 - 2020, 2022 by Acme Corporation. Все права защищены.
// Copyright (c) 2020 - 2022 by Jane Doe <jane@example.com>. Все права защищены.
//
// Лицензировано в соответствии с лицензией Apache версии 2.0 (далее «Лицензия»);
// вы не можете использовать этот файл, кроме как в соответствии с Лицензией.
// Вы можете получить копию Лицензии по адресу
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Если иное не требуется применимым законодательством или не согласовано в письменной форме, программное обеспечение,
// распространяемое в соответствии с настоящей Лицензией, распространяется на условиях «КАК ЕСТЬ»,
// БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ ЛЮБОГО РОДА, явных или подразумеваемых. См. Лицензию для конкретного языка, регулирующего разрешения и
// ограничения в рамках Лицензии.
//
// Идентификатор лицензии SPDX: Apache-2.0
Примечание: для скриптов или файлов CMake можно использовать соответствующий синтаксис комментариев # для заголовка.
Цели CMake разрабатываются в соответствии с уровнями качества ROS. Несмотря на разработку некоторых целей в соответствии с автомобильными стандартами, такими как ISO26262, кодовая база сама по себе НЕ узаконивает использование в критически важных системах безопасности. Все требования более низкого уровня качества включены в более высокие уровни качества, например, уровень качества 4 включён в уровень качества 3.
Этот уровень качества является уровнем качества по умолчанию. Он предназначен для примеров и вспомогательных инструментов.
Производное от уровня качества ROS. Уровень качества 5
Проверено двумя утверждающими.
Нет предупреждений компилятора.
Доступны лицензии и заявления об авторских правах.
Не требуется политика версий.
Не требуются модульные тесты.
Этот уровень качества основан на уровне качества ROS 4:
Этот уровень качества основан на уровне качества ROS 3:
Этот уровень качества предназначен для всех целей, которым нужна поддержка уровня 1 в ROS 2:
Этот уровень качества основан на уровне качества ROS 1:
Этот уровень качества выходит за рамки уровней качества ROS и содержит расширения:
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )