Скажем, у меня есть проект C ++, который разделен на несколько подпроектов. Все подпроекты создают DLL, и над каждым подпроектом работают разные группы разработчиков. Теперь, если я хочу построить основной проект, есть ли способ избежать создания всех подпроектов самостоятельно?
Короче говоря, я ищу что-то, что управляет зависимостями (то есть для двоичных файлов и заголовков) так же, как Maven для Java.
Фактически, я пытался использовать для этого Maven, но это довольно обременительно, потому что мне приходится создавать пакеты вручную, и довольно часто Maven пропускает самые последние изменения. Кроме того, запуск компиляции - это своего рода взлом, поскольку мне нужно вызывать NAnt из Maven (я использую функцию NAnt для непосредственного создания решений Visual Studio).
Любые подсказки и идеи, как это сделать?
источник
maven, вы упускаете всю сутьmaven, или 10 лет назад, когда я не использовалmavenдля C ++, это было гораздо менее полезно для C ++. Я не могу говорить о 2009 году, но по опыту последних летmavenэто именно то, что вы бы использовали для решения описываемой вами проблемы. Он делает именно то, что вы хотите, довольно эффективно и хорошо, и не делает того негативного, о котором вы заявляете. Любой, кто читает это в 2019 году или позже, должен серьезно подумать об использованииmavenдля этой цели.Ответы:
Первоначальный ответ : я бы предложил использовать CMake. Это многоплатформенный генератор файлов make (также генерирует проекты Visual Studio или Eclipse CDT).
http://www.cmake.org/
У меня был действительно хороший опыт. Больше всего мне в нем нравится возможность создавать общую структуру проекта. Таким образом, вы можете в общем случае включить поиск подпроектов для модульных тестов и т. Д., Не меняя каждый раз сценарий.
У них также есть много модулей о том, как найти предустановленные библиотеки сборки, необходимые для проекта (например, Boost, QT и т. Д.).
Обновление : Тем временем были предприняты некоторые усилия по внедрению управления пакетами для C ++. Некоторые проекты, на которые стоит обратить внимание:
Обратите внимание, как указывает @RAM в комментариях, cpm больше не поддерживается активно.
источник
Для управления зависимостями существует новый проект (это стартап), который реализует этот тип инструмента: https://github.com/biicode (менеджер зависимостей C ++). Вы можете добавить свои зависимости, и он должен работать.
В настоящее время проект носит название conan.io , он был приобретен JFrog .
ОБНОВЛЕНИЕ: проект мертв ... К сожалению, похоже, что стартап не смог получить достаточно клиентов, платящих премию, но сервер, похоже, работает нормально ...
ОБНОВЛЕНИЕ 2: похоже, есть заменяющий проект: conan.io (спасибо @mucaho)
источник
Я рекомендую следующие системы сборки высокого уровня:
источник
Если вам нужно только управление зависимостями, попробуйте Ivy , он прекрасно интегрируется с Ant (и я предполагаю, что NAnt может делать то же самое на основе этого блога , ссылка на который есть на сайте Ivy).
Существует также Byldan , версия Maven .Net. Не знаю, насколько хорошо это сработает для вас.
источник
Make и GCC - отличная комбинация для действительно хорошей проверки зависимостей.
GCC может автоматически генерировать файлы зависимостей make (ключ командной строки -MD), чтобы иметь возможность, например, перестроить все исходные файлы, которые зависят от данного заголовка.
У меня есть несколько простых правил, которые я вставляю в свои 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источник
${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@Мне было трудно разобрать все эти символы Make, похоже, это разрешает что-то вроде того,g++ -c main.cc -MD -MF testесли вы хотите запустить его автономно в командной строке, и он помещает результаты в файл с именем 'test'.Редактировать:
Biicode устарел
Альтернатива: Conan.io
источник
Я рекомендую Conan , который я использовал в эти дни. Это очень мощный инструмент для поддержки всех зависимых библиотек и двоичных файлов в вашем проекте.
источник
Вы можете создать пакет NuGet для используемых библиотек и использовать NuGet для управления зависимостями.
См. Также NuGet для C ++
источник
Существует ряд инструментов, расположенных поверх SCons, обеспечивающих функциональность более высокого уровня, аналогичную Autotools, которая пытается облегчить жизнь разработчикам (например, WAF, SNOCS). К сожалению, у самого SCons есть главный недостаток - большее время компиляции для больших проектов.
Я могу порекомендовать попробовать SNOCS (который является перевернутым SCons) для тех из вас, кто ищет простое управление зависимостями и выбирает параметры компиляции в одной команде (компилятор, x86 / x64, Debug / Release, статические / общие библиотеки, test / установить мишени и т. д.).
SNOCS также пытается решить проблему длительного времени компиляции, сохраняя выходные данные конфигурации проектов в отдельных файлах, что позволяет последующим сборкам полностью пропускать этап конфигурации и переходить прямо к этапу сборки (последняя функция сейчас находится в стадии разработки)
Конфигурация CMake становится утомительной в более крупных решениях, поэтому обслуживание системы сборки занимает значительную часть времени разработчика. К счастью, как уже упоминал Мартин, существует biicode, который «использует CMake для создания вашего проекта с его зависимостями».
источник
Попробуйте SCons
SCons - это инструмент для создания программного обеспечения с открытым исходным кодом, то есть инструмент для сборки нового поколения. Считайте SCons улучшенной кроссплатформенной заменой классической утилиты Make со встроенной функциональностью, аналогичной autoconf / automake и кешам компилятора, таким как ccache. Короче говоря, SCons - это более простой, надежный и быстрый способ создания программного обеспечения.
источник
Я рекомендую использовать мать всех систем зависимостей сборки: make.
источник
Попробуйте бра, вас зацепит. Марка устарела, сложна и дорога в обслуживании.
источник