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

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

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

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

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

Ответ 1

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

http://www.cmake.org/

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

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

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

conan.io интегрируется с основными инструментами построения:
- CMake
- Visual Studio
- Makefile
- XCode
- ...
cpm на основе CMake

Ответ 2

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

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

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

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

Ответ 3

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

Maven Nar Plugin: Использование Maven для проектов C/С++
Gradle плагин cpp: это более простой способ, но в настоящее время он инкубирует здесь основные функции и дорожная карта.

Ответ 4

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

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

Ответ 5

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

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

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

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

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

Теперь, если ваши объектные файлы объявлены в списке 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

Ответ 6

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

Edit:

Biicode устарел

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

Попробуйте SCons

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

Ответ 12

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