Неделя началась с нескольких постов про Conan. Логично было бы ее таким же образом и завершить. Тем более, что пару наших проектов как-то под Conan опакетить удалось.
Итак, поделюсь своими ощущениями от знакомства с двумя менеджерами зависимостей для C++. Это vcpkg от Microsoft-а и Conan, который сейчас находится под крылом JFrog. При этом сам я не пользуюсь в своих проектах ни одним, ни другим. И исхожу из своего опыта создания и сопровождения пакетов для этих менеджеров.
Начну, пожалуй, с vcpkg.
На мой взгляд, vcpkg посимпатичнее. Проще в освоении. Наверное, где-то логичнее. Но у vcpkg есть три серьезные родовые травмы. И, как по мне, дальнейшие перспективы vcpkg зависят того, сможет ли Microsoft их преодолеть. И если сможет, то когда и как.
Во-первых, в vcpkg сейчас нет версионности для библиотек. Т.е. если мы выпустили новую версию своего SObjectizer-а и залили новую версию в vcpkg, то у всех SObjectizer будет именно последней версии. Даже если кому-то это не нужно.
Способ борьбы с этой проблемой пока рекомендуется довольно странный (по крайней мере насколько мне известно). Мол, нужно сделать свой клон vcpkg, в котором зафиксировать нужные версии зависимостей. Что, имхо, неработоспособно, если вам нужно держать не 2-3 версии какой-то зависимости, а хотя бы 5-7, не говоря уже про 10 и более. А когда вы сопровождаете продукт с несколькими версиями и ветками развития, то версий зависимостей у вас может быть много.
Во-вторых, в vcpkg, насколько я знаю, нет автоматического разруливания зависимостей для зависимостей. Так, если вам нужен наш so_5_extra, который зависит от Asio и SObjectizer-а, то вам нужно будет вручную поставить и so_5_extra, и Asio, и SObjectizer. Хоть это и не сложно, но нужно не забыть все сделать ручками. И тут мы еще раз пересекаемся с первой проблемой -- отсутствием версионности. А что, если вы взяли so_5_extra, которая еще не была адаптирована к самой свежей версии Asio? Ведь Asio обновляется в vcpkg независимо от so_5_extra.
В-третьих, обновлении версии в vcpkg происходит не мгновенно и не от вас скорость обновления зависит. Вы делаете новую версию своей библиотеки, делаете Pull Request в vcpkg и... И ждете пока ваш PR примут. Это может занять и несколько часов. И неделю.
Причем меня, как поставщика библиотек, третья проблема раздражает больше всего.
Но вот что в vcpkg безусловно сделано правильно, так это интеграция с системой сборки. Хоть я очень сильно не люблю CMake, но один стандарт, пусть даже такой ущербный, как CMake, лучше, чем полное отсутствие стандарта. В результате вы просто ставите себе библиотеку через vcpkg и используете ее затем привычным для CMake образом. Не нужно никаких дополнительных телодвижений. Опять же, если вы поставляете библиотеку в vcpkg и у вашей библиотеки нормальная поддержка CMake, то вставить библиотеку в vcpkg нет проблем.
Теперь о Conan.
У Conan-а, к счастью, нет вышеперечисленных родовых травм vcpkg. Т.е. есть версионность, есть разруливание зависимостей для зависимостей, есть возможность самому публиковать обновления пакетов.
Но, с другой стороны, Conan напоминает сам C++: гибкий и мощный. Но ценой за это его сложность.
Т.е. если вы раньше с Conan не работали и захотели его освоить по его же штатной документации, то в процессе изучения вас, как и меня, может ждать несколько удивительных открытий и Вау-моментов. Поэтому, возможно, если вам нужно написать Conan-пакет для своей библиотеки, то лучше найти что-то похожее в Conan-е и попробовать разобраться с чужим conanfile.py, попутно заглядывая в документацию. По крайней мере мне чтение чужих conanfile.py помогло. Хотя до этого я несколько раз основные разделы документации проштудировал, но понимания не достиг.
Что мне больше всего не нравится в Conan, так это то, что он отвязан от системы сборки. Поэтому, даже если вы работаете с CMake, и тянете из Conan-а библиотеки, которые имеют CMake-файлы, то вы сперва должны подтащить зависимости для своего проекта (через conan install). А затем еще и должны выполнить конфигурирование CMake для своего проекта. А если, например, вам нужны зависимости как в Release-сборке, так и в Debug, то эти операции вы будете делать дважды. А если вам нужны зависимости под несколько компиляторов (или версий компиляторов), то и еще несколько раз. Лично мне это не нравится, я натыкался на то, что conan install ставит нужные мне зависимости в нужном мне 64-х битовом режиме, а CMake затем пытается конфигурироваться в 32-х битовом. Это мой косяк, но vcpkg от таких косяков защищает.
В общем, для Conan-а я вижу хорошую нишу применения во внутрикорпоративных разработках, заточенных под небольшое количество платформ и средств разработки. Вы поднимаете собственный Conan-сервер, заливаете туда все нужные вам зависимости (как внешние, так и свои). А потом в своих проектах таскаете это добро оттуда. Причем, поскольку у вас, скорее всего, будет всего одна целевая ОС и всего один основной компилятор, то шансов накосячить у вас будет немного. Особенно, если вы один раз напишите какой-то набор вспомогательных инструментов для ваших разработчиков и заставите их этими инструментами пользоваться. Тогда conan install и CMake можно запускать одной командой и всю механику можно спрятать под капот.
Но вот для таких разработчиков библиотек, как я, Conan какой-то сильно замороченный.
Какой вывод?
Наш MxxRu::externals круче всех! Нет счастья в жизни :(
Мне нравится простота и понятность, которую дает vcpkg. Но ему нужно избавиться от своих родовых травм.
От Conan-а у меня остались не самые хорошие впечатления. Хотя он работает и не имеет проблем, присущих vcpkg. При этом, как я уже говорил несколько дней назад, есть у меня впечатление, что разработчики Conan не столько решают проблемы C++ программистов, сколько привлекают потенциальных пользователей к сервисам JFrog.
Имхо, для того, чтобы в C++ появилась нормальная система управления зависимостей нужно либо довести до ума vcpkg, либо же упростить Conan (и завязать Conan на CMake). А пока у нас есть два конкурирующих продукта, ни один из которых мне не нравится. Но которые нужно будет поддерживать.
PS. Если кому-то интересно, что у нас получилось с Conan-ом, то текущие результаты лежат здесь. Надеюсь, что на следующей неделе добавится и RESTinio.
Комментариев нет:
Отправить комментарий