Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Хватит это терпеть. Структуризация домашних проэктов.

Хватит это терпеть. Структуризация домашних проэктов.

Страницы: 1 2 3 4 Следующая »
SuslikМодераторwww27 окт. 20186:15#0
Думаю, все с этим сталкивались: сначала пишешь какую-нибудь наколеночную миддлварю вроде векторной математики или поиска пути. Потом используешь её в каком-то из своих проэктов. Потом ещё в одном. Потом из второго проэкта дописываешь небольшую хреновину к своей миддлваре и хочется, чтобы оно автоматически появилось в первом проэкте и желательно ничего не уронило. Ещё лучше — чтобы зависимость из первого проэкта можно было обновить, когда будет возможность, исправив все конфликты.

Как это сделать? Сейчас я заметил, что каждый раз, когда я обновляю свою наколеночную библиотеку с векторной математикой, я её копирую вручную в как минимум десяток проэктов, которые от неё зависят. Что-то мне подсказывает, что это не нормально.

Для начала положим, что мой middleware хочется интегрировать просто как связку .h +.cpp файлов внутрь нескольких проектов(раскиданных по случайным папкам), которые от него зависят. Все проекты и middleware используют локальные git репозитории (git kraken фронтенд). Как принято такое организовывать?

WraithПостоялецwww27 окт. 20186:21#1
Симлинки сделай.
SuslikМодераторwww27 окт. 20186:26#2
мне дедушка рассказывал, что они в во время второй мировой пользовались симлинками. хочется всё-таки надеяться, что сейчас есть более элегантные решения. например, мой нубогуглёж показал, что есть такая вещь как submodules, специально придуманная в гите для таких вещей. кто пробовал? как ощущения?
WraithПостоялецwww27 окт. 20186:39#3
Так тебе шашечки или ехать? :)
CDПостоялецwww27 окт. 20186:57#4
Если разработка ведется на нескольких компах, то сабмодули, да.
Иначе проще через настройки проекта, ну или те же симлинки, чтобы меньше возни было.

Правка: 27 окт. 2018 6:57

VolodarПостоялецwww27 окт. 20186:59#5
Suslik
Тоже есть такой набор утили и классов. Вынесены в отдельный репозиторий, который как раз таки подключается сабмодулем.

Wraith
Будет работать только локально. И вообще гит плохо с симлинками дружит. Сылшал, что его можно сконфигурить для работы с ними, но зачем?

skalogryzУчастникwww27 окт. 20188:10#6
в паскале всё чётко решается. Может переехать с крестов?
раб вакуумной лампыПостоялецwww27 окт. 20188:34#7
Я думал это у меня одного такая придурь - два проекта вести параллельно. А тут некоторые десяток ведут. Одновременно. Могу лишь выразить автору свои соболезнования.
/A\Постоялецwww27 окт. 20189:34#8
Обычно я кидаю все проекты в один репозиторий и никаких проблем, особено с тем чтоб закомитить и запушить один проект, чтоб изменения появились во всех других.
Кроме сабмодулей гита есть еще cmake с external project или fetch content, только не уверен что они работают с приватными репозиториями.
MrShoorУчастникwww27 окт. 20189:52#9
Прикольно, отсутствие пакетов в языке решают костылями в системе контроля версий. :)
SuslikМодераторwww27 окт. 20189:58#10
разумеется, с submodules в гите всё не так просто. если submodule хранить как локальный репозиторий, то из него можно вытаскивать изменения, но push'ить в него обратно изменения нельзя, потому что он считается non-bare. как быть? если указать все submodules как bare, то это значит, что с ними ни один gui client работать не сможет. что я делаю не так?
MrShoorУчастникwww27 окт. 201810:10#11
Suslik
> как быть?
Перейти на svn. В нем в external-ы можно коммитить. :)
Ghost2Постоялецwww27 окт. 201810:19#12
Suslik

Храни bare где-нибудь на дропбоксе/гуглдиске.

Alexander KПостоялецwww27 окт. 201810:35#13
Suslik
У меня все библиотечные проекты лежат в папке, на которую указывает environment variable. Потом в других проектах я инклудаю их через эту env var, что позволяет спокойно работать на нескольких машинах со всеми проектами (и библиотечными, и использующими этими библиотеки). Работает и для студийных проектов, и для всяких cmake, в т.ч. под линукс.
Я для каждого проекта использую git, но и тут этот подход вообще никак не ограничивает.

Правка: 27 окт. 2018 10:41

SuslikМодераторwww27 окт. 201810:41#14
Ghost2
> Храни bare где-нибудь на дропбоксе/гуглдиске.
меня смущает, что ни один git gui client не умеет не то что создавать, даже открывать bare репозитории. я пробовал посто в .git/config прописать bare = true. это позволяло в этот репозиторий коммитить, но я не уверен, что это вообще законно и меня в тюрьму за это не посадят.

Alexander K
мне хочется уметь делать чекаут репозитория вместе со всеми зависимостями.

Страницы: 1 2 3 4 Следующая »

/ Форум / Программирование игр / Общее

2001—2018 © GameDev.ru — Разработка игр