LINUX.ORG.RU

maven for c++

 , ,


3

4

Я могу с++ простить все, что угодно, кроме отсутсвтия мавена. Суть такова: есть проект А, который зависит от проектов B, C. Все лежат в разных репозиториях. Задача - склонировать А, запустить любимую систему сборки и получить автоподпуливание B, C, их сборку и установку.

Впринципе я могу сделать custom_target для А, благо там cmake и все далется с полпинка. Но както это уж слишком костылевелосипедно. Нету ли вменяемых инструментов решения поставленной задачи?

★★★★★

Вообще-то это даже ближе к CVS. Мапишь папки с B & C как подпапки A, в CMakeLists.txt добавлешь add_subdirectory(А) add_subdirectory(В) и готово

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

add_directory практически то, но остается вопрос, кто будет клонировать B, C git репозитории?

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

Скрипт лежащий в проекте. Пишется на баше.. Вызывается перед каждой сборкой

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

дык ТСу хочется кнопку «Сделать зашибись»:

но остается вопрос, кто будет клонировать B, C git репозитории?

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

Я слежу за конкурентами, естественно. git-subtree - это едва ли не единственная вещь из Git, которую я хотел бы видеть в Mercurial.

tailgunner ★★★★★
()

Мы внешние проекты кладем в свой репозиторий. И если очень нужно обновляем вручную. Нет никакого желания зависеть от внезапных багов во внешних проектах

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

а это все и есть свои проекты. чего я как раз и хотел избежать, так это кастомного бутстрапа на шелле, который чегото там клонирует.

гляну что там с subtree насоветовали и как это впихнуть в cmake.

x0r ★★★★★
() автор топика
Последнее исправление: x0r (всего исправлений: 1)
Ответ на: комментарий от vromanov

Мы внешние проекты кладем в свой репозиторий. И если очень нужно обновляем вручную. Нет никакого желания зависеть от внезапных багов во внешних проектах

$ mkdir x
$ cd x
$ git init 
$ echo 'a' > file
$ git add file
$ git commit -a -m 'body:a'
$ cd ..
$ mkdir y
$ cd y
$ git init
$ echo 'y' > file
$ git add file
$ git commit -a -m 'first commit'
$ git submodule add ../x/
$ git commit -a -m 'add submodule'
$ cd ..
$ cd x
$ echo 'b' > file
$ git commit -a -m 'body:b'
$ cd ..
$ git clone y z
$ cd z
$ git submodule init
$ git submodule update
$ cd x
$ cat file 
a
quest ★★★★
()

Чувак ты не перестаёшь жечь.

Я могу автомобилю простить все, что угодно, кроме отсутствия перископа.

//фикседъ

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

Для йавы удобный, не спорю. Но для спп? Как ты себе представляешь его работу? Что хранить в репе? Исходники? Чем отличается тогда от любой vcs?

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

Это очень круто! Я просто описался от крутизны использованных команд! Но у нас исторически используется perforce.

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

Мавен как репозиторий пакетов на самом деле заменяется командой

yum install somelib-devel
а это в смаке сделать без проблем

Т.е. он не продназначен для получения сорцов, он для jar-ников. А в мире C это либы+заголовки.

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

я себе представляю это более сжато, в рамках одного сервера со своими поделками (набор git репозиториев). я пишу кресто-pom в котором указываю имена зависимостей + их версии (теги/бранчи), они подтягиваются, компилятся.

да, все это я могу накостылять на шелле, но было интересно, не костылял ли кто до меня.

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

это все самой разумеющиеся вещи, но речь идет о библиотеках. я то конечно могу собрать свои deb/rpm пакеты и сделать свой репозиторий под них, но это прокатило если бы я сидел в федорах и убунтах. проблема в том, что я сижу под гентой и ебилды мне писать западло.

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

cmake ExternalProject

похоже это пока лучшый вариант, спасибо.

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

ааа Т.е. у речь идет именно о ваших проектах? У нас для этого просто workspace в perforce собирается из разных веток. И уже они включаются в сmake. Для настройки workspace сделан батник, который надо запускать только один раз, либо если он поменялся.

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

Это очень круто! Я просто описался от крутизны использованных команд!

я вам наглядно доказал что не стоит бояться что вы будете «зависеть от внезапных багов во внешних проектах».

Но у нас исторически используется perforce.

Это очень печально. Perforce это просто кусок &^%^. Надеюсь вы это понимаете и постараетесь перейти на Git?

quest ★★★★
()
Последнее исправление: quest (всего исправлений: 2)

google repo - и всё будет выкачано и разложено. останется только собрать.
Выше верно сказали - гит сабмодуль - боль и страдания. Гит сабтри - достойная альтернатива.

Сам смотрю в сторону гугл репо, никак не хватает времени затестить..

aol ★★★★★
()

Я могу с++ простить все, что угодно, кроме отсутсвтия мавена.

/0

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

Переходить? Зачем? Нас вполне устраивает перфрсе.

Это печально. Реально печально что вы не понимаете зачем и вас все устраивает. Perforce даже из консоли со скриптами обвязки полный &^%^. Освойте Git - добрый совет вам.

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

Perforce это просто кусок &^%^. Надеюсь вы это понимаете и постараетесь перейти на Git?

Нет смысла менять одно говно на другое.

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

Нет смысла менять одно говно на другое.

Юзайте rcs фигли. Rcs в BSD - самый true way!

quest ★★★★
()
Последнее исправление: quest (всего исправлений: 1)
Ответ на: комментарий от tailgunner

ты ничего не понимаешь. Мсьи разбираются в сортах говна

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

ну тогда ты знаешь, что твои add_subdirectory - это даже близко не то, что есть maven. Поддиректории в мавене накодили, наверное, в первый же день, а потом были многие годы развития. тысячи плагинов, итп

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

Конечно, мавен куда круче. Но топикстартер описывает конкретную проблему (хотя тоже оставляет простор для фантазии), я предлагаю решение этой проблемы. Я не предлагаю полную замену мавена.

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

Мы пишем ПО. У нас не стоит задача использовать самую модную систему контроля версий.

офигенно. типа я еду на грузовике, а вы на телеге и при этом вы говорите «нафига мне грузовик? мы возим грузы, а не гонимся за модой!».

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

Типа мы едем в пробке, ты на розовом мини, а мы на грузовике. Ты так нчиего полезного и не напсиал кроме кидания какашками. Чем НАМ git лучше?

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

Git кому угодно лучше. Можно спорить еще с фанатами hg/bazaar, но perforce? Да всем Git лучше - это удобный инструмент который ускоряет разработку. Юзал я ваш перфорс. Напрямую это вообще мрак, со скриптами обвязки и локальным Git - чуть лучше но все одно отстоище жуткое причем это понимают даже его создатели.

Вообщем хотите крутить винты отверткой - ваше дело, а мы будем юзать шуруповерт!

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

И снова голословные утверждения. Чем он удобнее? Как он ускоряет разработку? Код начинает писаться быстрее? Вы похоже работали продавцом бадов :). Аргументация похожая.

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