C++ Buildsystem со способностью скомпилировать зависимости заранее

Есть несколько интересных замен make, которые автоматически отслеживают неявные зависимости (из файлов заголовков), являются кроссплатформенными и могут работать со сгенерированными файлами (например, определениями шейдеров). Два примера, с которыми я работал, это SCons и Jam / BJam .

Я не знаю кроссплатформенного способа получения * make для автоматического отслеживания зависимостей. Лучшее, что вы можете сделать, - это использовать какой-нибудь скрипт, который сканирует исходные файлы (или делает это компилятором C ++) и находит #includes (условная компиляция делает это сложным) и генерирует часть make-файла. Но вам придется вызывать этот сценарий всякий раз, когда что-то может измениться.

Я использую GNU Autotools (Autoconf, Automake, Libtool) в течение последних нескольких месяцев в нескольких проектах, которые я были вовлечены, и я думаю, что это прекрасно работает. По правде говоря, нужно немного привыкнуть к синтаксису, но я успешно использовал его в проекте, который требует распространения скриптов Python, библиотек C и приложений C ++. Я' Я дам вам несколько ссылок, которые помогли мне, когда я впервые задал подобный вопрос здесь.

• Страница GNU Autotools предоставляет лучшую документацию по системе в целом, но довольно многословна.
• В Википедии есть страница , на которой объясняется, как все работает. Autoconf настраивает проект на основе платформы, на которой вы собираетесь компилировать, Automake создает файлы Makefile для вашего проекта, а Libtool обрабатывает библиотеки.
• Пример Makefile.am и пример configure.ac должны помочь вам начать работу.

Еще несколько ссылок:

1. http://www.lrde.epita.fr /~adl/autotools.html
2. http://www.developingprogrammers.com/index.php/2006/01/05/autotools-tutorial/
3. http://sources.redhat.com/autobook/

Единственное, в чем я не уверен, - это какой-либо тип оболочки Windows для GNU Autotools. Я знаю, что вы можете использовать его внутри Cygwin, но что касается фактического распространения файлов и зависимостей на платформах Windows, вам, вероятно, лучше использовать установщик Windows MSI (или что-то, что может упаковать ваш проект в Visual Studio).

Если вы хотите распространять зависимости, вы можете настроить их в другом подкаталоге, например, libzip , с определенной записью Makefile.am, которая будет создавать эту библиотеку. Когда вы выполняете make install , библиотека будет установлена ​​в папку lib , которую сценарий настройки определил, что она должна использоваться.

Удачи!

но что касается фактического распространения файлов и зависимостей на платформах Windows, вам, вероятно, лучше использовать установщик Windows MSI (или что-то, что может упаковать ваш проект в Visual Studio).

Если вы хотите распространять зависимости, вы можете настроить их в другой подкаталог, например libzip , с определенной записью Makefile.am, которая будет собирать эту библиотеку. Когда вы выполняете make install , библиотека будет установлена ​​в папку lib , которую сценарий настройки определил, что она должна использоваться.

Удачи!

но что касается фактического распространения файлов и зависимостей на платформах Windows, вам, вероятно, лучше использовать установщик Windows MSI (или что-то, что может упаковать ваш проект в Visual Studio).

Если вы хотите распространять зависимости, вы можете настроить их в другой подкаталог, например libzip , с определенной записью Makefile.am, которая будет собирать эту библиотеку. Когда вы выполняете make install , библиотека будет установлена ​​в папку lib , которую сценарий настройки определил, что она должна использоваться.

Удачи!

Вопрос в том, существует ли реальный способ автоматически настроить зависимости.

Что вы имеете в виду?

Как вы сказали, CMake скомпилирует все, как только зависимости будут установлены на машинах. Вы просто ищете способ упаковать источник зависимостей? Когда все исходные коды есть, CMake и инструмент сборки (gcc, nmake, MSVS и т. Д.) - это все, что вам нужно.

Изменить: примечание: в CMake есть команда file, которая может использоваться для загрузки файлов, если они есть необходимо: файл (ЗАГРУЗИТЬ url-файл [TIMEOUT timeout] [STATUS status] [LOG log])

Edit 2: CPack - это еще один инструмент от разработчиков CMake, который можно использовать для упаковки файлы и тому подобное для распространения на различных платформах. Он может создавать NSIS для Windows и файлы .deb или .tgz для * nix.

Во многих системах * nix для этого используется какой-то менеджер пакетов или система сборки. Самым распространенным источником исходных текстов является GNU Autotools, который, как я слышал, вызывает крайнее горе. Однако с помощью нескольких скриптов и онлайн-хранилища для ваших подразделений вы можете настроить что-то подобное, например, так:

• В вашем проекте Makefile создайте цель (необязательно с подцелями), которая покрывает ваши зависимости.
• Внутри цели для каждой зависимости, сначала проверьте, есть ли в проекте источник dep (в * nix вы можете использовать touch для этого, но вы могли бы быть более тщательными)
• Если dep отсутствует, вы можно использовать curl и т. д., чтобы загрузить dep
• . Во всех случаях пусть цели dep выполняют рекурсивный вызов make ( make; make install; make clean; и т. Д.) В Makefile (или другой файл сценария конфигурации / сборки) зависимости. Если dep уже собран и установлен, make вернется довольно быстро.

Однако будет множество угловых случаев, которые приведут к поломке, в зависимости от установщиков для каждого dep (возможно, установщик интерактивен?) , но этот подход должен охватывать общую идею.

У меня на работе (мы создаем встроенные системы для защиты электропитания) мы использовали CMake для решения проблемы. Наша установка позволяет запускать cmake из разных мест.

/
CMakeLists.txt "install precompiled dependencies and build project"
   project/
      CMakeLists.txt "build the project managing dependencies of subsystems"
      subsystem1/
         CMakeLists.txt "build subsystem 1 assume dependecies are already met"
      subsystem2/
         CMakeLists.txt "build subsystem 2 assume dependecies are already met"

Хитрость заключается в том, чтобы убедиться, что каждый файл CMakeLists.txt может вызываться изолированно, но что файл верхнего уровня все еще может правильно построить все. Технически нам не нужны дополнительные файлы CMakeLists.txt, но это радует разработчиков. Было бы абсолютной болью, если бы нам всем пришлось редактировать один монолитный файл сборки в корне проекта.

Я не настраивал систему (я помог, но это не мое детище). Автор сказал, что в системе сборки boost cmake есть несколько действительно хороших вещей, которые помогают ему добиться плавного построения всей системы.

Наша установка позволяет запускать cmake из разных мест.

/
CMakeLists.txt "install precompiled dependencies and build project"
   project/
      CMakeLists.txt "build the project managing dependencies of subsystems"
      subsystem1/
         CMakeLists.txt "build subsystem 1 assume dependecies are already met"
      subsystem2/
         CMakeLists.txt "build subsystem 2 assume dependecies are already met"

Хитрость заключается в том, чтобы убедиться, что каждый файл CMakeLists.txt может вызываться изолированно, но что файл верхнего уровня все еще может правильно построить все. Технически нам не нужны дополнительные файлы CMakeLists.txt, но это радует разработчиков. Было бы абсолютной болью, если бы нам всем пришлось редактировать один файл монолитной сборки в корне проекта.

Я не настраивал систему (я помогал, но это не мое детище). Автор сказал, что в системе сборки boost cmake есть несколько действительно хороших вещей, которые помогают ему добиться плавного построения всей системы.

Наша установка позволяет запускать cmake из разных мест.

/
CMakeLists.txt "install precompiled dependencies and build project"
   project/
      CMakeLists.txt "build the project managing dependencies of subsystems"
      subsystem1/
         CMakeLists.txt "build subsystem 1 assume dependecies are already met"
      subsystem2/
         CMakeLists.txt "build subsystem 2 assume dependecies are already met"

Хитрость заключается в том, чтобы убедиться, что каждый файл CMakeLists.txt может вызываться изолированно, но что файл верхнего уровня все еще может правильно построить все. Технически нам не нужны дополнительные файлы CMakeLists.txt, но это радует разработчиков. Было бы абсолютной болью, если бы нам всем пришлось редактировать один файл монолитной сборки в корне проекта.

Я не настраивал систему (я помогал, но это не мое детище). Автор сказал, что в системе сборки boost cmake есть несколько действительно хороших вещей, которые помогают ему добиться плавного построения всей системы.

txt, но это радует разработчиков. Было бы абсолютной болью, если бы нам всем пришлось редактировать один монолитный файл сборки в корне проекта.

Я не настраивал систему (я помог, но это не мое детище). Автор сказал, что в системе сборки boost cmake есть несколько действительно хороших вещей, которые помогают ему добиться плавного построения всей системы.

txt, но это радует разработчиков. Было бы абсолютной болью, если бы нам всем пришлось редактировать один файл монолитной сборки в корне проекта.

Я не настраивал систему (я помогал, но это не мое детище). Автор сказал, что в системе сборки boost cmake есть несколько действительно хороших вещей, которые помогают ему добиться плавного построения всей системы.