При всем уважении к авторам библиотек, которые входят в Boost, не могу не сказать в очередной раз, что сам по себе Boost -- это помойка. Все завязано со всем и если ты хочешь использовать какую-то милипиздрическую часть Boost-а, то ты вынужден иметь дело со всей помойкой. И таскать ты ее будешь за собой постоянно. Вот сделал ты 5 лет назад небольшую тулзу на Boost-1.54, сейчас тебе потребовалось что-то в ней поменять и... И либо ты берешь откуда-то этот самый 1.54, ли пытаешься собрать свой старый код с современным Boost-ом. Ну или делаешь ты сейчас что-то на Boost-1.66, твой код кто-то другой пытается доработать под своим Linux-ом, а там из коробки только Boost-1.58.
Так что еще раз, для лучшего понимания сути претензий. Boost -- это такое говносборище C++ных библиотек, которое изначально рассчитано на то, чтобы быть только говносборищем и работать только в говносборе.
Возможно, это было актуально где-то в 1998-ом или, может быть, даже в 2001-ом. Но блин, мир давно изменился. Boost, хоть и был значимым явлением в мире C++, никогда не применялся повсеместно. Не было присутствия Boost-а в 100% С++ проектов. Посему точка зрения Boost-оводов о том, что есть милый и уютный мир Boost-а в котором есть все и сразу, а все остальное похрену, является угребищной точкой зрения. Устаревшей лет 15 назад.
Вроде как Boost-оводы сами дошли до понимания, что зависимость в 71MiB 7z-архива, который распаковывается на SSD-диске порядка 4-х минут -- это какой-то кабздец. И даже попробовали запилить разрезанный на модули Boost, который хостится на github-е.
Да только вот и здесь получилось какая-то непонятная субстанция. Что за субстанция я пока еще не разобрался, но говнецом уже попахивает.
Вот, скажем, захотелось мне поэкспериментировать с Boost.Interprocess. Но не так, чтобы я поставил себе весь Boost. А захотелось попробовать задействовать именно модуль Boost.Interprocess, подтянув из github-а только нужные ему модули. И в общем-то, можно смириться с тем, что для interprocess-а пришлось подтягивать еще и: config, move, assert, static_assert, intrusive, date_time, utility, core, detail. Хер с ним, помойка, где все зависит от всего и есть помойка, к этому за время существования Boost-а уже привыкли.
Внезапно оказалось, что Boost.Interprocess инклюдит файл с именем boost/detail/interlocked.hpp. А самый цимес в том, что внутри модуля Boost.Detail этого файла-то и нет.
В "большом" Boost-е этот заголовочный файл есть. А в разрезанном на модули -- нет. Ну а где этот файл? Как его найти?
Наверное, нужно разбираться с Boostdep. Т.е. нужно взять с github-а проект Boost. Потом скачать с github-а все submodules. Потом собрать Boost.Jam. Потом собрать Boostdep. Потом с помощью Boostdep выяснить, какие же библиотеки нужны для Interprocess. И только после этого я смогу у себя в проекте перечислить только те модули, которые Interprocess-у нужны.
По крайней мере другой цепочки действий я пока выдумать не смог.
Upd. В принципе, Boostdep помог, но не до конца. Так, Boostdep не смог указать, что требуется еще и Boost.Utility из-за того, что где-то загружается boost/operators.hpp. Upd2. и далеко не только это.
Возможно, тем, кто живет с Boost-ом последние 15 лет, непонятно, почему мне Boost-овский подход не нравится и почему хочется чего-то другого. Попытаюсь пояснить. Но не уверен, что мои объяснения многих удовлетворят.
Прежде всего, мне доводится писать кросс-платформенные вещи. Причем под кросс-платформенностью понимается вовсе не возможность работы под разными дистрибутивами Linux-а. Соответственно, установка зависимостей через системный менеджер зависимостей -- это какой-то слабодостижимый идеал. Тем более, что этот идеал даже под Linux-ами далеко не идеален.
Кроме того, не так уж редко случаются ситуации, когда нужно вернуться к работе, выполненной несколько лет назад. Причем по мелочи. Например, проверить поведение кода в каких-то условиях, исправить какую-то мелкую опечатку и т.д. Хочется свести все мероприятия, связанные с этим, к абсолютному минимуму -- без необходимости вручную устанавливать старые зависимости и, тем более, без необходимости переводить старый код на новые версии зависимостей.
Соответственно, очень хочется иметь возможность будучи на любой платформе взять именно то, что тебе нужно без оглядки на то, есть ли в этой ОС менеджер зависимостей или нет, есть ли нужные мне версии в этом менеджере и т.д. Мы для себя эту проблему закрыли через MxxRu::externals. Аналогичным образом она решается и через CMake-овский ExternalProject_Add.
Фокус в том, что на небольших автономных проектах, вроде Catch2/doctest или fmtlib... Или даже на довольно больших зависимостях вроде POCO или ACE -- это работает. А вот с громадной говносборкой под названием Boost... Вот здесь не так все просто.
Добавим сюда тот прискорбный факт, что C++ -- один из редких широкоиспользуемых языков, в которых нет де-факто стандартного менеджера зависимостей. Хотя уже всем понятно, что без этого менеджера дальше жить нельзя. Вот ей Богу, переход с C++ на Rust может быть оправдан уже только потому, что в Rust-е есть Cargo.
Но Boost-у эти тенденции похеру. Ведь это же Boost. Это же звучит гордо. Все же хотят войти в Boost.
А как по мне, так это точка зрения из категории "Мне хорошо, а на остальной мир мне насрать".
Если следовать принципу "критикуешь -- предлагай", то предложение очень простое. Перестаньте принимать новые библиотеки в Boost. Что вошло -- то вошло, пусть развивается там.
Новые же библиотеки должны жить и завоевывать свое место под солнцем самостоятельно. Только это сейчас сможет простимулировать появление де-факто стандартного менеджера зависимостей для C++. Если изрядная часть C++ разработчиков и дальше будет исходить из принципа "поставлю себе Boost, там есть все", то нормального прогресса в менеджерах зависимостей для C++ не будет. ИМХО, конечно.
Если кто-то ценит сам факт включения библиотеки в Boost (хотя если решения по включению принимаются по десяти или менее голосам, то этот факт вряд ли чего-то стоит), то сделайте какую-то меточку Verified by Boost. И перечисляйте на Boost.org названия библиотек, которые эту метку получили. Следите за качеством, делайте какие-то сборки тестовые. Только вот не распространяйте все свое добро в виде одной громадной говносборки.
Ну и дабы два раза не вставать, еще о наболевшем. Так же получилось, что наша небольшая команда занимается C++. Соответственно, приходится следить за тем, куда и как C++ движется (в тему будет недавний текст от Страуструпа -- Remember the Vasa), где и как используется, какие настроения царят в C++ сообществе, как C++ воспринимается вне сообщества (поскольку от этого зависит восстребованность C++ и C++ разработчиков) и т.д., и т.п.
Так вот иногда возникает очень сильное желание завязать с C++ и переключится на какую-то другую технологию (тот же Rust или даже Ada). И не потому, что сам по себе язык плох. Язык, конечно, со своими тараканами, но тут хоть более менее понятно их происхождение и они уже привычны. Больше всего удручают две вещи. Причем чем дальше развивается история, тем больше удручают.
Во-первых, это состояние C++ной экосистемы. Сообщество, в котором де-факто стандартами становятся такие странные инструменты, как CMake и vcpkg, как мне кажется, безнадежно больно.
Во-вторых, количество идиотов, которые используют C++ и производят глючный говнокод просто потому, что у них не хватает мозгов для использования такого специфического инструмента. А так же количество идиотов, которые производят сильный негативный фон вокруг C++, хотя сами, зачастую, вообще не понимают о чем говорят.
В таких условиях, иногда, реально руки опускаются и ты сам для себя не находишь ответа на вопрос: "А нахрена ты вообще делаешь что-то для языка, в котором все настолько плохо?"
Комментариев нет:
Отправить комментарий