LINUX.ORG.RU

third-party библиотеки в репозитарии


0

1

Всем привет. Прошу помочь с вопросом из серии «а как лучше сделать».

Предположим, при разработке используется большая библиотека. Например, буст. В приложении используется только малая часть библиотеки. Отказаться от ее использования и перейти на что-нибудь другое не представляется возможным (например, ввиду корпоративных соглашений).

Сейчас рассматриваем три варианта организации структуры проектов.

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

2. Слить в репозитарий всю библиотеку, подключать например с помощью svn:externals. Скорее всего, придется опять-таки тащить всю библиотеку при экспорте. Зато не придется устанавливать ее отдельно на каждую машину.

3. Раздраконить библиотеку, выдрать нужную часть и только ее положить в репозитарий.

1. хорош легкостью поддержки. aptitude dist-upgrade обновит все стандартные библиотеки, никаких лишних телодвижений. Но отдельная установка на все компьютеры разработчиков... не очень нравится.

3. плох (ИМХО) возможной сложностью перехода на новые версии. Да и если потребуется использовать дополнительные части библиотеки... придется заново раздирать библиотеку.

2. вообще практически со всех сторон плох :)

Собственно, кто что посоветует в данном случае?


>1. хорош легкостью поддержки. aptitude dist-upgrade обновит все стандартные библиотеки, никаких лишних телодвижений. Но отдельная установка на все компьютеры разработчиков... не очень нравится.

Да всё ок. Репозиторий нужен для того, чтобы из него ставить программы, а компьютер разработчиков - не компьютер клиента, поэтому можно потерпеть. А иначе тогда и IDE удалять надо - они большие и их надо ставить на все компы разработчиков.

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

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

Дак vim же :)

А если серьезно, то в случае настройки nightly builds + tests на виртуалке потребуется больше (значительно) места для компиляции проекта.

ksv ()

> Собственно, кто что посоветует в данном случае?

Оставить подключение сторонних библиотек на совести конкретных разработчиков, они разберутся.

svn:externals


Да, для начала надо выкинуть SVN и перейти на git/mercurial.

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

> Да, для начала надо выкинуть SVN и перейти на git/mercurial.

Предлагаю флейм по поводу scm не начинать. subversion - исключительно в качестве примера.

Оставить подключение сторонних библиотек на совести конкретных разработчиков, они разберутся.

Я один из разработчиков. Сейчас с коллегами решаем как лучше.

Я правильно понимаю, что вы предлагаете оставить право выбора каждому как получить библиотеку, т.е. репозитарий с ней все равно создать? Если да - то что именно положить в репозитарий - всю библиотеку или только ее часть?

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

>Если да - то что именно положить в репозитарий - всю библиотеку или только ее часть?

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

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

Хорошо, согласен, смысла во втором варианте очень мало.

Как насчет третьего варианта? Положить только используемую часть библиотеки? Библиотека в этом случае будет очень сильно «тронута», правда, коды останутся практически без изменения (возможно, пара модификаций кода, исключительно косметических).

ksv ()

Мне кажется, что лучше бы у всех разработчиков одна версии либы была. Т.е. положить какую-то скомпиленную версию либы в репозиторий вместе с инструкцией, как собирали, или скриптом сборки, чтобы потом проще было обновлять. А выдрать нужные boost'овые хидеры из всей мошны можно достаточно просто с помощью bcp, например.

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

Не понял при чем тут ld -static. Можно поподробнее?

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