C C++ build scan make cmake qmake

О чём

Предмет проверки — механизм захвата состава C/C++ проектов на этапе сборки, когда пакетного менеджера (Conan) нет, а зависимости проявляются только в момент компиляции и линковки. ТЗ (п. 3.3) прямо требует анализ проектов C/C++ со средствами автоматизации сборки make, cmake, qmake, не использующих пакетный менеджер. Здесь рассматривается именно режим build scan агента (наблюдение за сборкой), а не разбор готовых артефактов — это смежная тема Ограничения готовых бинарников.

Что подтверждено

• Документация и материалы демонстрации подтверждают C/C++ build scan через агент с использованием eBPF: агент наблюдает за реальной сборкой, фиксирует вызовы компилятора и линковщика и восстанавливает состав.
• Подтверждены тулчейны GCC/Clang и системы сборки CMake / Make.
• По материалам поставщика полнота инвентаризации C/C++ достигается именно на этапе сборки (а не по статике исходников). Это согласуется с архитектурой build scan.
• Разделение прямых/транзитивных зависимостей и построение графа поддержаны для многих экосистем; для C/C++ build scan это требует отдельной проверки в пилоте (см. ниже).

Почему build scan, а не manifest scan Для экосистем с пакетным менеджером состав читается из манифеста. В C/C++ без Conan манифеста нет, поэтому единственный надёжный путь — перехват фактической сборки. Это переносит требования на права агента: см. eBPF права агента и ограничения.

Что не подтверждено или ограничено

• qmake прямо не подтверждён. Документация и демонстрационные материалы покрывают CMake/Make; qmake (сборки на основе Qt) в подтверждённом перечне отсутствует. Для ТЗ это разрыв: qmake указан в списке наравне с make/cmake.
• Конкретные сборки Организации (их структура, генераторы, окружение) не проверялись — заявление о полноте на этапе сборки не равно подтверждению на реальном legacy-проекте.
• Разделение директивных/транзитивных зависимостей и граф именно для C/C++ build scan в матрице помечены как «проверить» — на уровне build scan это не то же самое, что для npm/maven.

Риск для ТЗ qmake входит в обязательный список п. 3.3, но не подтверждён ни документацией, ни демо. Если в контуре Организации есть Qt-проекты на qmake, это потенциальный блокер соответствия — закрывается только демонстрацией на пилоте, не словами.

Что проверить на пилоте

Вопросы и приёмочные проверки - Поддерживается ли build scan для qmake out of the box, или требуется обёртка/ручная настройка? Просить демонстрацию на Qt-проекте. - Выполнить build scan на реальном C/C++ проекте Организации без Conan: отдельно на make, отдельно на cmake, отдельно на qmake — и сравнить полноту графа. - Что попадает в состав при build scan: только то, что реально слинковалось, или и заголовочные зависимости? Где границы? - Как build scan различает прямые и транзитивные C/C++ зависимости и строит ли граф трассировки? - Что делать с компонентами, которые сборка тянет, но агент не смог сопоставить с известным пакетом+версией (переход к Статическая линковка и форки)? - Зафиксировать минимальные требования к среде сборки, чтобы захват сработал (см. права агента).

Связь

• Матрица соответствия требованиям OSA SCA — разрыв № 3 (C/C++ make/cmake/qmake) и строка SCA «проверить для C/C++ build scan».
• eBPF права агента и ограничения — какие права нужны агенту для захвата сборки.
• Статическая линковка и форки — что не опознаётся даже при наличии сборочного контекста.
• Ограничения готовых бинарников — смежный случай: артефакт без сборочного контекста.
• Приемочные сценарии пилота · Вопросы для пилота CodeScoring
• Документация: https://docs.codescoring.ru/en/user-guide/agent/scan-build