maven for c++

самый главный вопрос - причем тут C++?

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

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

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

а есть в гите аналог svn:externals?

git submodule

он вроде автоматом не выкачивает

man git submodule

пускай выкачивает не автоматом

Git submodules сосут, git-subtree ваше всё: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

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

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

вот так, пришел ярый меркуриалец и зарулил гитовцев.

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

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

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

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

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

$ 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

что мешает делать git submodule init; git submodule update в Makefile ?

Лучше уж

git submodule update --init --recursive

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

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

//фикседъ

ну скажи еще что мавен тут не пришей козе боян. удобный инструмент же.

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

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

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

fixed

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

yum install somelib-devel

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

http://www.cmake.org/pipermail/cmake/2011-July/045245.html

И ищешь/пишешь модуль для этого функционала.

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

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

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

cmake ExternalProject

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

enjoy your c/с++. Только bash

причем тут java

аха, накастовал блин.

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

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

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

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

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

А если написать плагин к мавену? :3

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

Ты же поди не знаешь, что такое мавен, wtf?

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

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

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

/0

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

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

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

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

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

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

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

Пришлось поработать и с ним.

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

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

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

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

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

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

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

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

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