LINUX.ORG.RU

git submodule vs cmake external project

 ,


0

2

ExternalProject

Плюсы:

  • Все зависимости в одном месте
  • Можно подтягивать любые проекты (не только cmake)

Минусы:

  • Сложнее интегрируется с IDE, сот-но если правки в зависимых проектах делать, то только ручками

git submodule

Плюсы:

  • Более простая интеграция при помощи add_subdirectory

Минусы:

  • Поддерживаются только cmake проекты
  • Секс с сабмодулями и бранчами

Что ещё забыл? Ваше мнение, что используете и почему?

★★★★★

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

lu4nik ★★★
()

Пакетный менеджер (например, conan с генератором cmake_paths), так как в энтерпрайзе ребилдить зависимости при разработке малореалистично. Сабмодули хороши для совсем мелких вещей, типа пошаренных схем. Для личных проектов небольшого размера без инфраструктуры я бы взял ExternalProject (отключаемый, чтобы пользователи могли подсунуть свои версии зависимостей, например системные). Разумеется, в любом случае должен быть обеспечен интерфейс для find_package (через экспортированные таргеты или кастомные модули).

d_a ★★★★★
()
Ответ на: комментарий от d_a

Собсно ExternalProject как раз для девелоперских машин. Ибо на Jenkins / в Yocto нужные пакеты / версии уже есть.

UVV ★★★★★
() автор топика

ExternalProject
Плюсы:
Можно подтягивать любые проекты (не только cmake)

git submodule
Минусы:
Поддерживаются только cmake проекты

Ну и бредятина.

cppsektant
()
Ответ на: комментарий от cppsektant

В каком конкретно пункте? Можно с примерами?

UVV ★★★★★
() автор топика

Вы в курсе, что git submodule, это вчерашний день, несмотря на свою популярность ?

anonymous
()

Монорепозиторий. git submodule самое ужасное, что может быть. Это говно никак не версионируемо и разъезжается по API/ABI постоянно.

xpahos ★★★★★
()

Использовать ExternalProject — к большой боли, потому что сборка в основном проекте не будет дёргать сборку во внешнем, потому что не знает, менялось ли там что-то. Причём когда будешь прикручивать, всё будет казаться нормальным, ведь ты будешь с чистого листа собирать. А вот во время разработки грабли-то из кустов и повылезают.

i-rinat ★★★★★
()

Поддерживаются только cmake проекты

Сабмодули git не имеют к cmake никакого отношения. Не связанные между собой технологии.

i-rinat ★★★★★
()

ExternalProject точно нет, ни при каких условиях, без исключений. Нельзя в процессе сборки что-то тянуть с интернета - это подрывает надёжность, предсказуемость и повторяемость сборки, при опакечивании во всех уважающих себя дистрибутивах явно запрещено. По умолчанию все зависимости берутся из системы. В очень редких случаях когда есть общий собственный кусок кода, который не хочется выносить в явную зависимость - git submodule.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Нельзя в процессе сборки что-то тянуть с интернета

При чем тут интернет? Что-то мешает развернуть локальное хранилище?

trex6 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.