CMake и C исходная иерархия - PullRequest
0 голосов
/ 25 января 2019

Я привык к следующей структуре в большинстве моих проектов:

src/
inc/
ext/
build/
[...]
CMakeLists.txt
README
LICENCE

Где src - каталог, в котором находится мой исходный код, inc - заголовки, ext - место для размещения внешних библиотек (которые затем создаются CMake).


Не похоже, что эта структура хороша, потому что я сталкиваюсь со следующей проблемой:

  1. Я пишу библиотеку.

  2. В моем inc каталоге все мои заголовки: частные и публичные единицы.

  3. В моем CMakeLists.txt я использую что-то вроде следующего:

    target_include_directories(${PROJECT_NAME}
        PUBLIC
            inc
    )
    

Проблема в том, что теперь все заголовки распространяются на супер-проект, даже частные. Возможным решением было бы иметь папку private и public внутри inc, следовательно:

src/
inc/
  private/
  public/
ext/
build/
[...]
CMakeLists.txt
README
LICENCE

Я мог бы тогда использовать:

target_include_directories(${PROJECT_NAME}
    PUBLIC
        inc/public
    PRIVATE
        inc/private
)

Вопрос в том, может ли кто-нибудь придумать какие-нибудь серьезные компромиссы? Может быть, есть даже «предложенная иерархия» от CMake?

1 Ответ

0 голосов
/ 25 января 2019

Честно говоря, я не фанат CMake.Я использую GNU make, которая поставляется вместе с моей ОС, и я счастлив, и мой код требует меньше от соавторов.

Но, кроме CMake, я бы повторно посетил структуру.

Структура вашей папки, хотя и не редкость, ничего не говорит о библиотеке или ее компонентах.Он не предоставляет будущему сопровождающему какую-либо полезную информацию.

Рассмотрим следующую структуру исходного кода:

src
src/io
src/http
src/pubsub
src/database

Внезапно, не прочитав ни одной строки кода, у меня есть сильный намеко том, каким может быть приложение (или библиотека) и где я могу найти каждый компонент, который мне может понадобиться просмотреть.

Посмотрите, например, Linux Repo .

Вбиблиотеках, это часто более важно, потому что (надеюсь) многие люди будут читать код и вносить свой вклад.

Таким образом, вы можете спросить , куда идет папка включения? ...

Проблема с отделением файлов заголовков от исходных файлов заключается в том, что это усложняет обслуживание.

Я рекомендую создавать usr/include (общедоступные включаемые файлы для установки) динамически, с использованием сценария или с помощьюmake ... но поскольку вы используете CMake, рассмотрите возможность указания каждого открытого заголовка или:

Другой распространенный параметр, который предполагает, что публичные заголовки явно различаютсяИсходя из заголовков реализации (т. е. содержат ограничения API и не редактируются, кроме как во время основной ревизии), они помещаются в отдельную папку include.

...