LINUX.ORG.RU

svn и разные компиляторы


0

1

Над одним проектом в svn работает более чем один разнработчик. Проблема в том, что разные разработчики используют разные компиляторы, которым нужны разные фичи из библиотек разных версий. Эффект следующий: допусим первый Разработчик [Р1] сделал апдейт и компелирует. Ему нужны некие сторонние либы. Где ему их взять\хранить? Есть два пути: 1ый, хранить у себя на компе либы, совместимые с его компилятором; 2ой, добавить их в репу и не морочить голову.

Недостаток первого: если сделать checkout от куда-то ещё, соотвественно негде взять сторонние либы. Получается, их надо таскать с собой.
Недостаток второго: Р2 будет говорить нехорошие слова, когда обнаружит, что либы в репе несовместимы с его компилятором.

Р1 не хочет решение №1. Р1 хочет решение №2, но так, что бы Р2 не говорил нехороших слов.

Что посоветуете Р1.

В репозитории не должно быть никаких бинарников и сторонних либ. Каждый хранит их у себя и сам разбирается что и как ему нужно.

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

>В репозитории не должно быть никаких ... сторонних либ

Какой ты чодкей. А 3rd-party-зависимости откуда прикажешь брать?

yoghurt ★★★★★ ()

Я бы отделил куски кода для разных компиляторов ifdef'ами. Вопрос: конечный продукт чем будет собираться?

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

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

yoghurt ★★★★★ ()

Советую не морочить голову. Если уж ситуация, что сборка не может быть выполнена обним и тем же сборочным механизмом совсем не устранима, то просто раздели исходники и системы сборки. Что то типа

src/lib/libmain.cpp
src/lib/libmain.h
builders/cmake/
builders/make
builders/VC
В этом случае тебе действительно не придется париться как Р2 там у себя собирает. Ну и присоединяюсь к некотором ораторам - тащить депенды в дерево плохая манера. На винде надо будет одна версия, на Linux другая, на маке третья...

На а если блобы и все такое, то тут и думать не о чем :)

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

как правило, в описанных тобой ситуациях, УЖЕ знаю как сделать, а не задают вопросы на ЛОРе...

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

> Какой ты чодкей. А 3rd-party-зависимости откуда прикажешь брать?

Оттуда, откуда ты положил бы их в SVN. В нормальных системах всё ставится из репозитория, и, скажем, cmake, находит все библиотеки изкоробки. В винде нет (и проекты, разрабатывающиеся виндузятниками легко опознаются по помойке dll'ек в VCS). Тем не менее, отсутсвие в винде репозитория - не повод тащить дрянь в VCS, потому что она там не нужна. Проблемы винды должны решать либо её разработчики, либо её пользователи.

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

Красноглазая чушь. Кривые руки - они кривые и на винде, и на линухе.

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

И что? Мой проект использут sqlite, мне обязательно добавлять исходники или бинарь в репу? Может лучше предоставить системе сборки заниматься поиском нужных либ?

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

Очень неточно.
В то время как с cmake -> make все понятно, ибо мейк и в африке мейк, то с cmake -> VC все куда сложнее.
По факту cmake -> VС позволяет лишь сгенерировать «первичный» проект, так сказать темплейт, который потом, придется еще донастраивать.

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

Ванильный sqlite, как и многое другое, можно и нужно ставить из реп.

А если у тебя свой, патченный sqlite с блекджеком и шлюхами? Будешь каждый раз его пересобирать? +Перечитай мой пост и вообрази другие варианты.

yoghurt ★★★★★ ()

через cmake это всё разруливается

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

Блобы - да, доступные нормальные либы - нет.

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