В связи с выходом Boost 1.48.0 озадачился данным вопросом ;) Насколько я могу судить, с каждым новым релизом размер tar.bz2-архива увеличивается приблизительно на 2Mb. Для версии 1.48.0 это уже 48.2, а zip-овского архива – 94.8Mb. Тогда как размер qt-everywhere-commercial-src-4.7.4.zip – 236Mb. Пока у Qt ощутимое преимущество, но, возможно, всего лишь пока ;)
PS. Да, не любитель я Boost-а :) И чем больше он становится, тем больше не любителем становлюсь я :)))
Надо сказать, что с приходом нового стандарта необходимость в boost снизилась.
ОтветитьУдалитьПравда вот не знаю, зачем в стандарт притащили биндинги, когда есть лямбды?
Но в любом случае, указатели и биндинги и форич, это едва ли не основные вещи, которые использовались мной в бусте.
Совсем без буста жить я пока не хочу, там еще остались вкусности. :)
А размер, да какая собственно разница, сколько он занимает в дистрибутиве. Если конечно его не нужно тащить вместе с проектом...
@Андрей Валяев:
ОтветитьУдалить>А размер, да какая собственно разница, сколько он занимает в дистрибутиве. Если конечно его не нужно тащить вместе с проектом...
У нас просто большинство сторонних проектов (за исключением разве что Qt, iconv и openssl) включаются в соответствующие репозитории. И затем на них делаются ссылки из проектов.
Распространена ситуация, когда проект A версии 3.8 использует ACE 5.6.8 и POCO 1.3.5, а версии 3.9 -- уже ACE 6.0.3 и POCO 1.4.0. И, поскольку обе версии (а так же ряд промежуточных) находятся в разработке и эксплуатации, то на машине разработчика может быть сразу куча разных версий ACE, POCO, PCRE и пр. сторонних библиотек.
У такого подхода есть и минусы, но есть и плюсы. В любом случае, так уж у нас повелось и чем больше размер дистрибутива сторонней либы, тем сложнее с ней работа становится.
Да, это бывает, мы сами с рабочим проектом таскаем буст...
ОтветитьУдалитьЭто проблема.
Буст можно было бы весь не таскать, раздербанить его на либы, и таскать только необходимые. Но тогда с ним больше возни пожалуй. :)
С ACE я давно не работал.. лет наверное 7 :), насколько помню - она тоже немеряно толстая и немеряно долго собирается. :)
>Буст можно было бы весь не таскать, раздербанить его на либы, и таскать только необходимые. Но тогда с ним больше возни пожалуй. :)
ОтветитьУдалитьУгу. А был бы он изначально раздербаненным на отдельные библиотеки, было бы проще, имхо. Чем вручную этим через bcp заниматься.
>С ACE я давно не работал.. лет наверное 7 :), насколько помню - она тоже немеряно толстая и немеряно долго собирается. :)
Да, есть такое. Но все-таки ~10Mb -- это много меньше, чем 48Mb.
ну так 3 либы добавились же в набор, размер должен был уменьшиться при этом?
ОтветитьУдалить@Андрей Валяев:
>Правда вот не знаю, зачем в стандарт притащили биндинги, когда есть лямбды?
Лямбды в стандарте мономорфные, так что полезность их довольно небольшая.
@eao197
> чем больше размер дистрибутива сторонней либы, тем сложнее с ней работа становится.
Не понял, какая разница, сколько места либа ест в репозитории? (у нас в репозитории лежат только файлы настройки сборки, но не сами либы, но не суть). Я понимаю сложно от количества версий библиотеки, но от объема...?
@jazzer:
ОтветитьУдалить>ну так 3 либы добавились же в набор, размер должен был уменьшиться при этом?
Я еще раз повторю свое мнение о Boost-е: он должен бы развиваться как сообщество связанных библиотек, а не как одна большая мега-библиотека. Чтобы можно было взять только то, что мне нужно. И не париться о том, что с обновленной версией Asio приходится тянуть к себе еще 3 новых библиотеки.
>Я понимаю сложно от количества версий библиотеки, но от объема...?
Очень быстро засираются винты (особенно у любителей бранчей, вроде меня). И очень увеличивается время компиляции/рекомпиляции.
>И не париться о том, что с обновленной версией Asio приходится тянуть к себе еще 3 новых библиотеки
ОтветитьУдалитьПосмотри на это с другой стороны: каждый релиз буста - это когерентный набор библиотек, которые гарантировано (оттестировано кучей народа) работают вместе на куче конфигураций.
Сравни это с ситуацией, когда ты выкачиваешь новую Asio, а она - опаньки - работает с новой версией какой-нть MPL, а у тебя программа пользуется старой, хуже того, она еще пользуется библиотекой Osia, которая тоже работает только со старым MPL, и если свой код ты еще можешь подрихтовать, то с Osia ты в пролёте. Что будешь делать?
Ты немножко забываешь о том, что мы живем в мире С/С++, в которой исходники включаются текстово напрямую, если ты что-то подключил в недрах какой-то либы, то оно теперь видно в твоей программе тоже, причем в том самом виде, в котором оно в той либе подключено, и невозможно подключить две версии одной и той же либы одновременно.
Может это в какой-нть Руби одна либа подключит какую угодно версию другой, и никто об этом не узнает, но в С++ это не так, все насквозь и все всем видно. В таких условиях с моделью буста мне гораздо комфортнее работать.
А насчет бранчей - у тебя бранчи пакета сторонних библиотек??? Ну это ты тогда ССЗБ...
@jazzer:
ОтветитьУдалить>Посмотри на это с другой стороны: каждый релиз буста - это когерентный набор библиотек, которые гарантировано (оттестировано кучей народа) работают вместе на куче конфигураций.
Я смотрю, и кроме двух крайних точек зрения, а именно:
1. Все вместе, зато протестированно.
2. Все независимо и контроль совместимости лежит на совести пользователя,
я вижу еще и промежуточную: релиз boost-а -- это декларация того, что вот этот конкретный набор библиотек, вот этих конкретных версий, протестирован в совокупности. А дальше уже пусть пользователь решает -- хочет он брать все или частями, а если частями, то какими.
Например, к часу X разработчики всех библиотек Boost-а должны зафиксировать где-то версии, которые они хотят включить в релиз Boost-а. Эти версии централизовано собираются и тестируются. После чего релиз выкатывается на публику. Всем входящим в него библиотекам присваивается одинаковый номер версии. Скажем asio-1.48.0, filesystem-1.48.0, mpl-1.48.0.
До следующего релиза Boost-а эти библиотеки могут выпускать независимые минорные версии с баг-фиксами и мелкими дополнениями. Но нумероваться эти версии должны соответственно. Например, asio-1.48.0.11 или filesystem-1.48.0.15.
Пользователь, если хочет, может взять asio-1.48.0.11. Но тогда его задача проверить, а совместим ли этот asio с другими частями Boost-а, которые есть у пользователя.
Т.е. и у разработчиков Boost-а нет лишнего геморроя(как собирали релизы, так и собирают) и никаких новых гарантий они никому не дают. И у пользователей есть свобода и большая гибкость.
учитывая, что буст релизят раз в квартал, не вижу смысла в такой возне с мелочами - промежутоных версий дай бог чтоб одна была при такой частоте релизов. Я с такой скоростью все равно не обновляю библиотеки, это нереально просто, еще и работать же надо когда-то.
ОтветитьУдалитьРеально библиотеки обновляются где-то раз в два года, и гораздо легче их забирать пачкой и накатывать патчи выборочно из трекера, если вдруг что-то нашлось важное.
@jazzer:
ОтветитьУдалить>А насчет бранчей - у тебя бранчи пакета сторонних библиотек??? Ну это ты тогда ССЗБ...
Если бы в мире OpenSource все было быстро и детерминировано, тогда я бы не был ССЗБ. А так приходится приспосабливаться.
Например, сделали мы новый нужный нам функционал в ACE (создав у себя бранч). Отдали патчи разработчикам ACE. А те накатили их только в ACE 6.0, тогда как мы делали патчи еще на 5.6.5. И пару лет мы у себя использовали нашу версию ACE, поскольку в официальной версии нужного функционала не было.
Или еще пример. Задействовали в неком проекте X версии 3.7.7 библиотеку POCO версии 1.3.4. Запустили и забыли, работает себе версия 3.7.7 в какой-то инсталляции несколько лет, мы и горя не знаем. Потом обнаруживается в ней баг. Оказывается, что баг в POCO. Понятное дело, что баг исправляется, попутно выясняется, что он уже исправлен в POCO 1.4.1. Но что нам делать с X-3.7.7? Переводить его на POCO-1.4.1? А у нас уже есть X-3.8.12, которая давно работат на POCO-1.4.1. И версию 3.7.* мы уже не развиваем. И переход с 3.7.7 на 3.8.12 не простой, а требует модификации конфигов и переучивания персонала у заказчики. Так что по свокупности различных организационных, финансовых и политических причин может быть выгодно создать у себя бранч POCO 1.3.4.1 и выпустить X-3.7.7.1 именно на этой версии POCO. Чтобы просто убрать баг и позволить софту проработать в том же самом режиме еще несколько лет.
@jazzer:
ОтветитьУдалить>Реально библиотеки обновляются где-то раз в два года, и гораздо легче их забирать пачкой и накатывать патчи выборочно из трекера, если вдруг что-то нашлось важное.
Ну не знаю. Библиотеки разные. PCRE, например, у нас уже фиг знает сколько стоит без обновления. А вот OTL, скажем, обновлятся очень часто. Да и тот же ACE лучше после минорных bug-fix релизов лучше забирать, чтобы задействовать в trunk-версиях основных проектов.
ну, твои примеры с бранчами показывают, что необходимость в создании бранча не возникает чаще чем раз в пару лет. Имхо, оптимизировать то, что раз в пару лет случается, несколько странно.
ОтветитьУдалить@jazzer:
ОтветитьУдалить>ну, твои примеры с бранчами показывают, что необходимость в создании бранча не возникает чаще чем раз в пару лет. Имхо, оптимизировать то, что раз в пару лет случается, несколько странно.
Мои примеры касались бранчей чужих библиотек. В собственных проектах бранчи создаются намного чаще. И есть таки большая разница, зависит ли твой собственный бранч от левых библиотек в 10Mb, или от 50Mb. Поскольку если только архив 50Mb, то заколупешься ждать пока он придет из репозитория, распакуется, скомпилируется и пр. При все при этом из 50Mb мне нужно всего от силы 2-3Mb.
>заколупешься ждать пока он придет из репозитория, распакуется, скомпилируется и пр.
ОтветитьУдалитьХм... а зачем вместе с бранчем своего кода выкачивать и пересобирать весь пакет сторонних библиотек?
У нас вот все библиотеки, предварительно собранные, лежат в специальном месте (считай, у них свой репозитарий), расшаренном на все девелоперские машины. А твой собственный код просто линки на соответствующие версии несет на борту, которые не весят ничего. Так что при выкачивании бранча своего кода ничего, кроме своего кода, не выкачивается и не пересобирается. ЧЯДНТ? :)
@jazzer:
ОтветитьУдалитьНу а вот у нас не так. У нас одних только версий ACE в разных ветках разных проектов используется версии 3-4, как минимум. И работают люди иногда из дому, иногда из коммандировок (а даже по ADSL-ым соединениям у нас особо с сетевыми шарами не поработаешь).
И допустим у разработчика должны лежать скомпилированные версии того же ACE (в разных вариантах, под разные компиляторы). Да в таких условиях пути к include и lib-каталогам задолбешься отслеживать и настраивать.
А так взял из репозитория конкретный бранч, вместе с ним все нужное пришло. Собрал как тебе нужно и другими лежащими у тебя на диске проектами никаких пересечений.
Только вот после определенного размера сторонней библиотеки это перестает работать. Например, с Qt так не получается. Вот и с растущим Boost-ом то же.