- не библиотеки?
PFL?
Да, но если для библиотек он вопросов не вызывает, то include/ в корне проекта условного .exe/firmware/etc выглядит странно
Хм. А *.cmake-скрипты в случае с PFL принято также располагать в корне репозитория?
Общепринятых особо нет. Кто во что горазд. Можно посмотреть на организацию каких-то крупных проектов на гитхабе.
Их размещаю в tools/cmake/, но официального предписания, вроде, нет. Листы, разумеется, в корень (разрешается в 1.2).
А как пробрасываете пути к cmake-модулям "наверх"?
Автор их хранит в корне, в cmake и в extras/pf-cmake
Кажется, не понимаю вопрос, поскольку хочется ответить "не пробрасываю". Модули - локальные зависимости проекта же.
Я создавал голосование про две популярные структуры. Обе годятся не только для библиотек, хотя и оформлять исходный код цельного приложения как библиотеки, намного проще. Это ничего не стоит в начале, но Дарь даёт потом неплохую гибкость
Обе эти структуры не затрагивают специфических применений... Например, куда положить скрипт линкера? Или набор файлов от производителя железки: external/ или src/details?
Я думаю, что Pitchfork отвечает на оба вопроса, скрипт куда-то в tools/, а набор файлов в /external/<vendor-files>/
А вы не разделяете публичные и приватные хедеры? Мое правило выглядит так - публичные в include, приватные в src. У бинарника естественно нет публичных хедеров и include.
Для разделения на публичные и приватные, вовсе не обязательно их держать в разных директориях
Да, но я не вижу зачем приватные хедеры держать вместе с приватными. Ошибки компиляции искать после пакетирования звучит не очень.
В src/CMakeLists.txt придется пробросить путь к скрипту. Есть ли способ сделать это красивее, кроме определения переменной с явным путём tools/link/xxx.lds?
Из вариантов — включать скрипт в корневом CMakeLists.txt. Или использовать CMAKE_MODULE_PATH. Но первый вариант, кажется, популярнее
Обсуждают сегодня