Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

Билет 13

Теоретический вопрос

Что меняется в восстановлении состава C/C++, когда у проекта есть менеджер сборки — Conan, vcpkg — против голого make/qmake? Объясните, почему conan graph info даёт идентичность пакета (имя, версия, package_id, устойчивый PURL) и разрешённый граф, тогда как legacy qmake-проект с ручными third_party/ каталогами идентичности не даёт. Почему наличие манифеста (conanfile, vcpkg.json) — это переход от «угадывания» к декларации, но private-qualifiers и внутренние remote всё ещё требуют аккуратной нормализации PURL?

Практический вопрос

Мини-кейс Два модуля одного продукта: один на Conan с conanfile.txt, другой — legacy на qmake с библиотеками, скопированными в third_party/. Опишите, как для первого получить идентичность и граф пакетов, а для второго — почему придётся опираться на ELF-анализ и ручную доразметку. Что сделать с private-qualifier в PURL, чтобы не утёк внутренний remote? 

conan graph info . --format=json     # идентичность + граф (package_id, версии)
# qmake-проект: манифеста нет → состав восстанавливаем из сборки и ELF
qmake -query QT_INSTALL_LIBS

Что должен показать ответ

Опорные материалы