Разъяснение о современной структуре CMake
Я не опытный программист на C или C++, но мне нужно написать приложение на C и C++ для двух курсовых проектов. Чтобы начать с правильной ноги, я читал руководство о как структурировать код проекта CMake.
Я хотел бы уточнить значение и использование каталога include:
- Если проект представляет собой библиотеку, предназначен ли каталог
includeдля хранения функций API, которые пользователи библиотеки могут включать в свой код и вызывать? Если да, то какой каталог следует использовать для заголовков, содержащих объявления внутренних функций? Должны ли такие заголовки быть вместе с исходным кодом (который содержится в каталогеsrc)? - Если проект представляет собой приложение, предназначен ли каталог
includeдля хранения заголовочных файлов исходного кода? Если да, то в чем преимущество отделения заголовков от источников? Это просто вопрос предпочтения организации?
Спасибо за любое понимание.
Не существует единого стандарта для включаемого или исходного каталога. Мне нравится хранить исходный код и включать его в каталог в зависимости от темы. Один из моих товарищей по команде сменил организацию и решил поместить все включаемые файлы в отдельную директорию (под тематическую папку). Каталоги «include» обычно включают файлы заголовков, которые содержат объявления и, возможно, константы.
Точно; они для двух разных курсов. Один (C) посвящен параллельным вычислениям в MPI/OpenMP, другой (C++) связан с CUDA.
Не существует «современной структуры CMake», и я, например, никогда бы не использовал структуру, описанную по ссылке. Так что выбирайте то, что вам подходит, и вперед.
Это скорее вопрос cmake, чем общий. Это действительно хорошая идея - хранить объявления типов и функций для типов и функций, используемых целями, связывающими вашу библиотеку, в отдельном каталоге. include/libname (например, #include "opencv2/imgproc.hpp") является стандартом де-факто для установленных библиотек, поэтому выбор такой же структуры в вашем проекте может быть хорошей идеей. Что касается внутренних заголовков, то здесь нет стандарта; Я обычно помещаю их рядом с файлами реализации, чтобы сократить относительные включения.
Заголовки исполняемых файлов следует обрабатывать так же, как и заголовки внутренних библиотек. Для исполняемых файлов пользователю не требуется доступ к каким-либо заголовкам. Информация в заголовках больше не нужна в процессе сборки после того, как компилятор завершит работу с вашими единицами перевода, и, поскольку никто не будет связывать вашу исполняемую цель, заголовки исполняемых целей имеют ту же цель, что и внутренние заголовки в библиотечной цели.
Ответы 1
Если вы пишете приложение, вы можете размещать его там, где хотите. Пользователь в основном ожидает, что у вас есть подкаталог bin с вашими бинарными исполняемыми файлами. О, и, пожалуйста, поддержите CMAKE_INSTALL_PREFIX: сборки в исходном коде - это зло, насколько я понимаю.
Если вы пишете библиотеку, пользователь ожидает подкаталоги include и lib в префиксе установки. Для приятного unix-y материала вы можете включить man, если вы знаете, как генерировать troff.
О каталоге include. Вы можете поместить свой файл mylib.h прямо туда, но если ваша библиотека вообще имеет общее имя, скажем format, это может привести к конфликту имен, поэтому в наши дни многие пакеты организуют его как /home/mylibinstallation/include/mylibrary/mylib.h. Затем вы бы export MYLIBINC=/home/mylibinstallation/include и программа `#include "mylibrary/mylib.h". Этот дополнительный уровень также хорош, если у вас есть несколько включений.
Помогите мне понять. Вам нужно написать два приложения, одно на C, а другое на C++?