Maven-подобный контроль зависимостей для С++?

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

Короче говоря, я ищу что-то, что делает управление зависимостями (т.е. для двоичных файлов и заголовков) аналогичным образом, как Maven для Java.

На самом деле, я пытался использовать Maven для этого, но это довольно громоздко, потому что я должен создавать пакеты вручную и довольно часто, Maven пропускает самые последние изменения. Кроме того, запуск компиляции - это немного взломать, поскольку я должен вызвать NAnt из Maven (я использую функцию NAnt для непосредственного создания решений Visual Studio).

Любые подсказки и идеи о том, как это сделать?

+64
16 июл. '09 в 7:55
источник поделиться
12 ответов

Я бы предложил использовать CMake. Это многоплатформенный генератор файлов файлов (также создает проекты Visual Studio или Eclipse CDT).

http://www.cmake.org/

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

У них также есть много модулей о том, как найти предварительно установленные библиотеки сборки, необходимые для проекта (например, Boost, QT и т.д.)


Обновление. В то же время было несколько попыток внедрить управление пакетами для С++. Некоторые проекты, на которые стоит обратить внимание:

  • conan.io интегрируется с основными инструментами построения:
    • CMake
    • Visual Studio
    • Makefile
    • XCode
    • ...
  • cpm на основе CMake
+20
16 июл. '09 в 10:13
источник

Для управления зависимостями существует новый проект (это стартап-компания), который реализует этот тип инструмента: https://www.biicode.com/ (менеджер зависимостей С++). Вы можете добавить свои зависимости, и они должны работать.

В настоящее время имя проекта conan.io, они были приобретены JFrog.

UPDATE: проект мертвый... К сожалению, кажется, что запуск не может получить достаточное количество платных клиентов, но сервер кажется работает нормально...

UPDATE2: Кажется, есть альтернативный проект: conan.io (спасибо @mucaho)

+13
25 июн. '14 в 12:09
источник

Я рекомендую следующие высокоуровневые системы сборки:

+6
23 сент. '14 в 8:24
источник

Если вы хотите только управлять зависимостями, попробуйте Ivy, он прекрасно сочетается с Ant (и я предполагаю, что NAnt может делать то же самое основанный на этом blog, который связан с сайтом Ivy).

Существует также Byldan.Net-версия Maven. Не знаю, насколько хорошо это сработает для вас.

+5
16 июл. '09 в 8:10
источник

Make и GCC - отличная комбо для действительно хорошей проверки зависимостей.

GCC может автоматически генерировать файлы зависимостей make (-MD), чтобы иметь возможность перестроить все исходные файлы, которые зависят от данного заголовка, например.

У меня есть несколько простых правил, которые я нарезал-n-paste в свои make файлы:

# compile c files   
%.o:    %.c
    ${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@

# compile c++ files
%.opp:  %.cpp
    ${CPP} ${CPPFLAGS} -c $< -MD -MF $(<:%.cpp=%.dep) -o $@

Теперь, если ваши объектные файлы объявлены в списке OBJ_C и OBJ_CPP:

.PHONY: cleandep
cleandep:
    rm -f $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

-include $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

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

Например, если ваши другие команды всегда помещают свои последние DLL в какую-либо общую папку:

myapp: ${SRC_CPP} ${LIB_DIR}other_team.lib
  ...

${LIB_DIR}other_team.lib: /shared_folder/latest/other_team.lib
  cp /shared_folder/latest/other_team.lib ${LIB_DIR}other_team.lib
+3
16 июл. '09 в 8:51
источник

Недавно выпущено: biicode Многоплатформенный инструмент и услуга хостинга для разработчиков

Edit:

Biicode устарел

Альтернатива: Conan.io

+3
12 янв. '15 в 13:51
источник

Я рекомендую conan, который я использовал в эти дни. Это очень удобно для поддержки всех зависимых библиотек и двоичных файлов в вашем проекте.

+2
03 нояб. '16 в 5:58
источник

Вы можете создать пакет NuGet для используемых библиотек и использовать NuGet для управления зависимостями.

См. также NuGet для С++

+1
14 янв. '14 в 13:29
источник

Существует множество инструментов, расположенных поверх SCons, обеспечивая более высокую функциональность, аналогичную функции Autotools, которая пытается упростить жизнь разработчиков (например, WAF, SNOCS). К сожалению, сам SCons имеет главный недостаток - более длительное время компиляции для крупных проектов.

Я могу порекомендовать попробовать SNOCS (который был изменен на SCons) для тех из вас, кто ищет легкое управление зависимостями и выбирает параметры компиляции в единственной команде (компилятор, x86/x64, Debug/Release, статические/разделяемые библиотеки, задачи тестирования/установки и т.д.).

SNOCS также пытается решить проблему длительной компиляции, сохраняя вывод конфигурации проектов в отдельных файлах, что позволяет последующим сборкам полностью пропускать фазу конфигурации и перейти прямо к фазе здания (последняя функция сейчас находится в разработке)

Конфигурация CMake становится утомительной в более крупных решениях, поэтому обслуживание системы сборки занимает значительную часть времени разработки. К счастью, как уже упоминал Martijn, biicode, который "использует CMake для генерации вашего проекта с его зависимостями".

0
24 авг. '15 в 14:01
источник

Попробуйте SCons

SCons - это инструмент для создания программного обеспечения с открытым исходным кодом, то есть инструмент построения следующего поколения. Подумайте о SCons как улучшенной кросс-платформенной замене классической утилиты Make со встроенной функциональностью, подобной кэшам autoconf/automake и компилятора, таким как ccache. Короче говоря, SCons - это более простой, надежный и быстрый способ создания программного обеспечения.

-1
30 июн. '14 в 13:47
источник

Я рекомендую использовать мать всех систем зависимостей сборки: make.

-1
16 июл. '09 в 7:56
источник

Попробуй счётчиков, ты зацепишься. Make устарел, сложный и дорогой в обслуживании.

-5
16 июл. '09 в 11:24
источник

Посмотрите другие вопросы по меткам или Задайте вопрос