Менеджене управління залежністю від C ++? [зачинено]

Скажімо, у мене є проект C ++, який розділений на кілька підпроектів. Всі підпроекти створюють DLL, і над кожною з підпроектів працюють різні команди розробників. Тепер, якщо я хочу створити основний проект, чи є спосіб уникнути необхідності будувати всі підпроекти власноруч?

Коротше кажучи, я шукаю те, що керує залежністю (тобто для бінарних файлів та заголовків) аналогічно тому, як Maven робить для Java.

Насправді я намагався використовувати Maven для цього, але це досить громіздко, оскільки мені доводиться створювати пакунки вручну і досить часто, Maven не вистачає, щоб забрати останні зміни. Крім того, запуск компіляції - це трохи хак, тому що я повинен викликати NAnt зсередини Maven (я використовую функцію NAnt безпосередньо для створення рішень Visual Studio).

Будь-які підказки та ідеї, як це зробити?

Початковий відповідь : Я б запропонував використовувати CMake. Це мультиплатформенний генератор файлів (також генерує проекти Visual Studio або Eclipse CDT).

http://www.cmake.org/

Я зробив із цим дійсно хороший досвід. Найкраще, що мені подобається в цьому, - це можливість виробляти загальну структуру проекту. Таким чином, ви можете загалом включати пошук підпроектів для одиничних тестів тощо, не змінюючи сценарій кожного разу.

Вони також мають безліч модулів про те, як знайти заздалегідь встановлені бібліотеки збірки, необхідні для проекту (наприклад, Boost, QT тощо)

Оновлення : Тим часом були вкладені певні зусилля, щоб запровадити управління пакетами для C ++. Деякі проекти, які варто переглянути:

• conan.io інтегрується з основними інструментами побудови:
  • CMake
  • Візуальна студія
  • Makefilefile
  • XCode
  • ...
• cpm на основі CMake ( Примітка CPM не підтримується активно.)
• Буккару

Зауважте, як зазначає @RAM в коментарях, cpm більше не підтримується активно.

Для управління залежностями існує новий проект (це стартап-компанія), який реалізує такий інструмент: https://github.com/biicode (менеджер залежності C ++). Ви можете додати свої залежності, і це має спрацювати.

Наразі назва проекту - conan.io , їх придбав JFrog .

ОНОВЛЕННЯ: Проект мертвий ... На жаль, здається, що стартап не міг отримати достатньо клієнтів, які платять преміум-класу, але сервер, здається, працює нормально ...

UPDATE2: Схоже, є проект-замінник: conan.io (спасибі @mucaho)

Я рекомендую такі системи високого рівня складання:

• Плагін Maven Nar: Використання Maven для проектів C / C ++
• Плагін Gradle cpp : Це простіший спосіб, але він наразі інкубує, тут основні особливості та дорожня карта .
• Конан - це більш підхід C ++, він є багатоплатформенним і підтримує найбільш поширені системи побудови C ++.

Якщо ви хочете лише керувати залежністю, спробуйте Ivy , він непогано інтегрується з Ant (і я припускаю, що NAnt може зробити те саме на основі цього блогу , який пов’язаний із сайтом Ivy).

Існує також Билдан , .Net версія Maven. Не знаю, наскільки добре це буде працювати для вас.

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

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

У мене є кілька простих правил, які я вирізав-вклеював у свої файли:

# 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)

Звичайно, можна також відстежувати залежності з іншими проектами, наприклад, наприклад, будувати спільну бібліотеку, якщо це необхідно.

Наприклад, якщо ваші інші команди завжди розміщують свої останні 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

Редагувати:

Бікод застарілий

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

Я рекомендую конан , яким я користувався в ці дні. Це дуже потужно підтримувати всі залежні бібліотеки та бінарні файли у вашому проекті.

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

Дивіться також, NuGet для C ++

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

Я можу порекомендувати спробувати SNOCS (це SCONS) для тих, хто шукає просте управління залежностями та вибирає параметри компіляції в одній команді (компілятор, x86 / x64, налагодження / випуск, статичні / спільні бібліотеки, тест / встановити цілі тощо).

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

Конфігурація CMake стає виснажливою у великих рішеннях, тому технічне обслуговування системи займає значну частину часу розробника. На щастя, як уже згадувався Мартійн, є бікод, який "використовує CMake для генерування вашого проекту з його залежностями".

Спробуйте SCons

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

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

Спробуйте сконс, вас зачеплять. Зробити застарілим, важким і дорогим в обслуговуванні.