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

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

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

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

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

 

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

 <http://www.cmake.org/>

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

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

---

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

* [conan.io](https://www.conan.io/) интегрируется с основными инструментами построения:
	+ CMake
	+ Visual Studio
	+ Makefile
	+ XCode
	+ ...
* [cpm](https://github.com/iauns/cpm) на основе CMake

 

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

В настоящее время имя проекта [conan.io](https://www.conan.io/), они были приобретены [JFrog](https://https//www.jfrog.com).

UPDATE: проект [мертвый](http://blog.biicode.com/biicode-just-the-company-post-mortem/)... К сожалению, кажется, что запуск не может получить достаточное количество платных клиентов, но сервер кажется работает нормально...

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

 

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

* Maven Nar Plugin: [Использование Maven для проектов C/С++](/questions/71128/using-maven-for-cc-projects)
* [Gradle плагин cpp](http://www.gradle.org/docs/current/userguide/nativeBinaries.html): это более простой способ, но в настоящее время он инкубирует [здесь основные функции и дорожная карта](http://www.gradleware.com/video/creating-a-world-class-cc-build-system-in-gradle-2/).

 

Если вы хотите только управлять зависимостями, попробуйте [Ivy](http://ant.apache.org/ivy/), он прекрасно сочетается с Ant (и я предполагаю, что NAnt может делать то же самое основанный на этом [blog](http://chris-engn.blogspot.com/2005/07/naven-dotnet-continous-integration.html), который связан с сайтом Ivy).

Существует также [Byldan](http://www.codeplex.com/byldan/).Net-версия Maven. Не знаю, насколько хорошо это сработает для вас.

 

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

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

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

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

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

```

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

```
 

Недавно выпущено: [biicode](http://biicode.com) Многоплатформенный инструмент и услуга хостинга для разработчиков

Edit:

Biicode устарел

Альтернатива: [Conan.io](https://conan.io/)

 

Я рекомендую [conan](https://www.conan.io/), который я использовал в эти дни.
Это очень удобно для поддержки всех зависимых библиотек и двоичных файлов в вашем проекте.

 

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

См. также [NuGet для С++](http://blogs.msdn.com/b/vcblog/archive/2013/04/26/nuget-for-c.aspx)

 

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

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

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

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

 

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

 

Попробуйте [SCons](http://www.scons.org/)

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

 

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