ровно то о чем я и говорю. нельзя просто взять и сделать CXX build и получить готовый бинарь.
Если не пытаться перехитрить коллег, то вполне можно заставить проект собраться простым человеческим cmake --build --preset dev, даже если у него килотонны зависимостей.
Если вам нужно поддерживать работу только на одном дистрибутиве линукса или можно забить на то, что на разных дистрибутивах будут использоваться разные версии зависимостей, то можно и системным пакетным менеджером отделаться.
У меня такой роскоши нет, нужно чтобы приложение работало и на пачке линуксов разной степени свежести, и на винде, и чтобы не нужно было держать в голове причуды разных версий зависимостей. Тут vcpkg очень сильно помогает, т.к. по сути это просто набор тех же самых скриптов сборки, которые пришлось бы писать и поддерживать самостоятельно (что исходя из опыта может быть очень нетривиально). Бонусом он открывает путь к новым платформам, потому что достаточно написать один тулчейн для cmake’а и большинство зависимости собирётся без лишних интервенций.
Как только userver выложили в опенсорс было желание написать под него порт для vcpkg, но на тот момент сложилось впечатление, что система сборки была написана под внутреннюю кухню - одна платформа, вроде бы некоторые зависимости нужно было выкорчёвывать, install step не описан (могу ошибаться). Надо как-нибудь на досуге попробовать совершить второй заход. С добавлением/обновлением портов в vcpkg опыт положительный.
Задача OpenSSL - опубликовать релиз и иметь инструкцию по сборке, с ней они справились. Как подключить в ваш проект - это ваша головная боль, OpenSSL не должен пытаться усидеть на как минимум четырёх стульях: CMake, meson, bazel и autotools.
Патч != система сборки. Рецепт != система сборки. Даже при наличии CMakeLists.txt нужен рецепт. Патчи существуют в т.ч. для того, чтобы подогнать установку под свои представления о прекрасном (installation layout, протягивание флаги компиляции и т.п.) Ну и роль MS во всём этом скорее проревьювить изменения и нажать кнопку merge, сами правки вносят обычные люди и те самые компании, о которых вы не знаете.
Если не пытаться перехитрить коллег, то вполне можно заставить проект собраться простым человеческим
cmake --build --preset dev, даже если у него килотонны зависимостей.Походу https://izzys.casa/2024/11/on-safe-cxx/ :D
Если вам нужно поддерживать работу только на одном дистрибутиве линукса или можно забить на то, что на разных дистрибутивах будут использоваться разные версии зависимостей, то можно и системным пакетным менеджером отделаться.
У меня такой роскоши нет, нужно чтобы приложение работало и на пачке линуксов разной степени свежести, и на винде, и чтобы не нужно было держать в голове причуды разных версий зависимостей. Тут vcpkg очень сильно помогает, т.к. по сути это просто набор тех же самых скриптов сборки, которые пришлось бы писать и поддерживать самостоятельно (что исходя из опыта может быть очень нетривиально). Бонусом он открывает путь к новым платформам, потому что достаточно написать один тулчейн для cmake’а и большинство зависимости собирётся без лишних интервенций.
Что не так с vcpkg и кроссплатформой?
Какой-то вынос мозга если честно. Почему так?
Зачем в данном случае нужна эта прослойка с
std::optional, если всё равно копируем значение?cache.lookup(key, 42)было бы ещё проще.Если ли какие-нибудь замеры скорости компиляции?
Чё-то я пока не представляю, как можно добиться анализа инклюдов без compile_commands.json. Возможно, об этом стоило написать в статье.
Как только userver выложили в опенсорс было желание написать под него порт для vcpkg, но на тот момент сложилось впечатление, что система сборки была написана под внутреннюю кухню - одна платформа, вроде бы некоторые зависимости нужно было выкорчёвывать, install step не описан (могу ошибаться). Надо как-нибудь на досуге попробовать совершить второй заход. С добавлением/обновлением портов в vcpkg опыт положительный.
https://www.codingfont.com/
Хорошая статья, спасибо.
Немного в шоке от того, что долистав до конца увидел у этой статьи всего один плюс.
🤭
В chromite недавно завезли поддержку расширений. Первым делом порезал всю "не рекламу" на Хабре.
Что? Строка со счётчиком ссылок в стандартном C++? Знакомьтесь: std::runtime_error.
Вы что, cout не заметили? /s
Они и open source релизы делают, правда с задержкой в год. 31 октября вышла версия 5.15.18.
Игнорировать атрибуции - не по-джентльменски.
Задача OpenSSL - опубликовать релиз и иметь инструкцию по сборке, с ней они справились. Как подключить в ваш проект - это ваша головная боль, OpenSSL не должен пытаться усидеть на как минимум четырёх стульях: CMake, meson, bazel и autotools.
Патч != система сборки. Рецепт != система сборки. Даже при наличии CMakeLists.txt нужен рецепт.
Патчи существуют в т.ч. для того, чтобы подогнать установку под свои представления о прекрасном (installation layout, протягивание флаги компиляции и т.п.)
Ну и роль MS во всём этом скорее проревьювить изменения и нажать кнопку merge, сами правки вносят обычные люди и те самые компании, о которых вы не знаете.
Эмм... А обновляться оно само будет?
Можете не представлять, а увидеть воочию: https://github.com/microsoft/vcpkg/commits/master/ports/openssl
Согласен, поменять номер версии и хэш архива с исходниками - это очень сложно.