Через FetchContent — это ужасно. Минут пять CMake качает буст и генерит сборочные скрипты, и так каждый раз при изменении CMakeLists.txt (а он часто меняется). При этом в каждом сгенеренном CMake build каталоге лежит копия буста (1.5Гб), т.ё, если я собираю MSVC x86/x64 — это уже 10 минут и 3 гига на один проект
Собрать буст при помощи CMake — что-то не пошло.
Раньше под MSVC/.vcxproj я делал так: собрал бутстрап, собрал буст под MSVC, сделал переменную окружения BOOST_ROOT, сделал boost.props, где настраиваются Include/Library пути на базе BOOST_ROOT, и одной строчкой boost.props подключаю в проект, и всё.
только вчера хотел сказать что марти открыл для себя буст
теперь будет месяц буста на ктыве от марте
что, где, когда
я понимаю, что марти так устроены, что сами они никогда ни в чем разбираться не будут
они перекладут это на плечи других
поэтому для марти придумали и создали https://discourse.cmake.org/
спамь там
если не обучен мануал к cmake читать
Здравствуйте, reversecode, Вы писали:
R>марти, покажи в сообщении выше хотя бы один отсыл к политике
Ты меня принимаешь за марти, он тебя хорошо макал в политике, да и я этим не брезгую. И вместо того, чтобы ответить по существу, или просто пройти мимо, ты начинаешь тут устраивать помойку
2) Девелоперский буст содержит CMakeLists.txt и вроде как заточен под CMake, но CMake официально пока не поддерживается.
3) Релизный архив буста имеет другую структуру и там нет CMakeLists.txt и прочего симейкнутого, он собирается классически через bootstrap и bjam/b2
Итак, мои варианты:
Вариант первый, простой, для использования хидер-онли библиотек.
Качаем официальный архив, например, https://archives.boost.io/release/1.85.0/source/boost_1_85_0.zip.
Распаковываем, например, в D:\boost
Делаем переменную окружения BOOST_ROOT=D:\boost
В своём CMakeLists.txt делаем так:
Вариант второй, жирный.
Boost выкачивается и конфигурируется каждый раз при перегенерации сборочных скриптов, и в каждом конфиге занимает полтора гига и минут пять времени (на шустрой машине может наверное и за пару минут управится).
Таким образом, если я хочу собирать MSVC x86/x64 и MinGW x86/x64 — это занимает 20 минут времени и 6 гигов места на проект на диске.
Зато в этом варианте вроде как можно любые бустовые либы использовать, но мне пока не надо.
В своём CMakeLists.txt делаем так:
include(FetchContent)
FetchContent_Declare(
Boost
URL https://github.com/boostorg/boost/releases/download/boost-1.84.0/boost-1.84.0.tar.xz
URL_MD5 893b5203b862eb9bbd08553e24ff146a
DOWNLOAD_EXTRACT_TIMESTAMP ON
)
FetchContent_MakeAvailable(Boost)
По FetchContent_Declare.
Рецепт брал тут — https://github.com/boostorg/cmake?tab=readme-ov-file#using-boost-with-fetchcontent
Тут буст предпоследний.
URL_MD5 — не обязательно, и можно записать по-другому, как "URL_HASH MD5:893b5203b862eb9bbd08553e24ff146a"
Можно через WGET (или как удобнее) скачать архив, и положить локально, и подсовывать путь вместо URL. Хз сколько времени экономит, этот XZ всего 90 метров, но похоже, там есть всё что надо, и можно жить без сети.
У меня так работает
FetchContent_Declare(
Boost
URL D:/boost-1.84.0.tar.xz
DOWNLOAD_EXTRACT_TIMESTAMP ON
)
В этом варианте вроде как можно юзать любую бустовую либу, но я не проверял.
Моя проверка была минимальной, соберётся или нет:
#include <boost/container/static_vector.hpp>
Третий вариант: собрать девелоперский вариант буста с симейком, сделать install и типа всё будет шоколадно. У меня не получилось, в итоге накопал первые два.
Здравствуйте, andrey.desman, Вы писали:
П>>Комментарии, предложения, замечания — приветствуются.
AD>А момент про EXCLUDE_FROM_ALL и BOOST_INCLUDE_LIBRARIES в доке пропустил?
Особо не углублялся, мне заработало и ладно. Есть настроение — можешь раскрыть
Здравствуйте, пффф, Вы писали:
AD>>А момент про EXCLUDE_FROM_ALL и BOOST_INCLUDE_LIBRARIES в доке пропустил? П>Особо не углублялся, мне заработало и ладно. Есть настроение — можешь раскрыть
Наверное, это из мэйкфайлов пошло. make, если ему не указать явный таргет, собирает первый таргет в мейкфайле. Обычно это таргет all, который зависит от всего. То есть, чтобы собрать всё.
В cmake есть что-то похожее. Отсутствие таргета в командной строке — это таргет all. Когда в cmake ты делаешь add_subdirectory, то все таргеты из этой сабдиректори добавляются в список таргета all, и они будут безусловно собираться, используешь ты их или нет.
EXCLUDE_FROM_ALL явно говорит не добавлять все под-таргеты таргету all, так что будет собираться только то, на что есть явная зависимость. Например,
Здравствуйте, andrey.desman, Вы писали:
П>>Особо не углублялся, мне заработало и ладно. Есть настроение — можешь раскрыть
AD>Наверное, это из мэйкфайлов пошло. make, если ему не указать явный таргет, собирает первый таргет в мейкфайле. Обычно это таргет all, который зависит от всего. То есть, чтобы собрать всё. AD>В cmake есть что-то похожее. Отсутствие таргета в командной строке — это таргет all. Когда в cmake ты делаешь add_subdirectory, то все таргеты из этой сабдиректори добавляются в список таргета all, и они будут безусловно собираться, используешь ты их или нет. AD>EXCLUDE_FROM_ALL явно говорит не добавлять все под-таргеты таргету all, так что будет собираться только то, на что есть явная зависимость. Например, AD>
AD>Тогда cmake соберет только filesystem и regex.
AD>Каким образом и на что влияет BOOST_INCLUDE_LIBRARIES я хз, не пользовался.
Ну, у меня не того масштаба проекты пока, чтоб это играло какую-то роль, и я пока использую хидер-онли вариант, там ничего лишнего не собирается, потому и не ковырял
AD>Когда в cmake ты делаешь add_subdirectory, то все таргеты из этой сабдиректори добавляются в список таргета all, и они будут безусловно собираться, используешь ты их или нет.
Вот по этому — не уверен. Я делаю для каждого таргета отдельно
Здравствуйте, пффф, Вы писали:
П>Ну, у меня не того масштаба проекты пока, чтоб это играло какую-то роль, и я пока использую хидер-онли вариант, там ничего лишнего не собирается, потому и не ковырял
А,типа find_package на несобранный и не проинсталленый boost. Ну, может и сработать, хз.
Я про вариант add_subdirectory (который у тебя Жырный). В жырном варианте можно ограничить список собираемого.
Здравствуйте, andrey.desman, Вы писали:
П>>Ну, у меня не того масштаба проекты пока, чтоб это играло какую-то роль, и я пока использую хидер-онли вариант, там ничего лишнего не собирается, потому и не ковырял
AD>А,типа find_package на несобранный и не проинсталленый boost. Ну, может и сработать, хз. AD>Я про вариант add_subdirectory (который у тебя Жырный). В жырном варианте можно ограничить список собираемого.
В жирном варианте сам симейк у меня пять минут пыхтит, так что я один раз собрал, проверил, что работает, и забыл
Да, add_subdirectory не нужен был, собралось и без этого. И в VSCode+CMakeTools там был список бустовых либ.
Здравствуйте, andrey.desman, Вы писали:
П>>Ну, у меня не того масштаба проекты пока, чтоб это играло какую-то роль, и я пока использую хидер-онли вариант, там ничего лишнего не собирается, потому и не ковырял
AD>А,типа find_package на несобранный и не проинсталленый boost. Ну, может и сработать, хз. AD>Я про вариант add_subdirectory (который у тебя Жырный). В жырном варианте можно ограничить список собираемого.
Да, в жЫрном варианте ничего лишнего тоже вроде не собиралась, компиляция проскочила так же быстро, как и в обезжиренном варианте
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, _NN_, Вы писали:
П>>>У кого-то есть рецепты получше?
_NN>>Использование vcpkg с кешированием не подойдёт случайно ?
П>Может и подойдёт, если ты поподробнее расскажешь об этом способе
А что там рассказывать. Ставишь vcpkg, делаешь vcpkg install boost:x64-windows. Когда дёргаешь cmake для проекта — добавляешь тулчейн из vcpkg (всё по туториалу, который краткий и простой). В самом проекте тупо find_package
П>>Может и подойдёт, если ты поподробнее расскажешь об этом способе
SaZ>А что там рассказывать. Ставишь vcpkg, делаешь vcpkg install boost:x64-windows.
А если надо собирать и x86? И "boost:x64-windows" — это для вижуалки или MinGW? Какая версия?
А одновременно еще arm-none-eabi можно собрать?
SaZ>Когда дёргаешь cmake для проекта — добавляешь тулчейн из vcpkg (всё по туториалу, который краткий и простой). В самом проекте тупо find_package
А если уже есть свой тулчейн файл, два тулчейн файла можно задавать? В настройках VSCode CMake:Tools для кита вроде только один файл можно задать
Здравствуйте, пффф, Вы писали:
П>...
П>А если надо собирать и x86? И "boost:x64-windows" — это для вижуалки или MinGW? Какая версия? П>А одновременно еще arm-none-eabi можно собрать?
Можно собирать сразу под несколько компиляторов. Там есть триплеты для mingw. Главное не бояться минимально почитать документацию. Представь, что нет интернета/гугла/стэковерфлоу/рсдн, но есть репозиторий vcpkg склонированный с гитхаба. Как в старые добрые времена. Там всё достаточно хорошо разложено.
Эх, совсем у людей любознательность пропала. Если совсем лень даже минимально напрячься, то можно спросить чатгпт, он объяснит.
SaZ>>Когда дёргаешь cmake для проекта — добавляешь тулчейн из vcpkg (всё по туториалу, который краткий и простой). В самом проекте тупо find_package
П>А если уже есть свой тулчейн файл, два тулчейн файла можно задавать? В настройках VSCode CMake:Tools для кита вроде только один файл можно задать
Можно через соответствующую переменную для cmake — VCPKG_CHAINLOAD_TOOLCHAIN_FILE
Здравствуйте, SaZ, Вы писали:
SaZ>Эх, совсем у людей любознательность пропала. Если совсем лень даже минимально напрячься, то можно спросить чатгпт, он объяснит.
Если честно, люди уже просто задолбались изучать новое
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, SaZ, Вы писали:
SaZ>>Эх, совсем у людей любознательность пропала. Если совсем лень даже минимально напрячься, то можно спросить чатгпт, он объяснит.
П>Если честно, люди уже просто задолбались изучать новое
Так можно с амишей брать пример =)
Там нового — кот наплакал. Но зато более-менее нормальный менеджер пакетов в плюсах появился. А не то что всякие эти конанопитоны.
SaZ>Так можно с амишей брать пример =) SaZ>Там нового — кот наплакал. Но зато более-менее нормальный менеджер пакетов в плюсах появился. А не то что всякие эти конанопитоны.
vcpkg? Он, кроме винды, где-то есть? Нормальный? Не помрёт?
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, _NN_, Вы писали:
П>>>У кого-то есть рецепты получше?
_NN>>Использование vcpkg с кешированием не подойдёт случайно ?
П>Может и подойдёт, если ты поподробнее расскажешь об этом способе
Ну например можно так:
Нам нужен сам vcpkg:
git clone https://github.com/microsoft/vcpkg
Подключаем его в проектный project_root_dir/CMakeLists.txt:
С vcpkg возможно вам больше подойдёт свой триплет вместо своего тулчейна.
Использовать триплет также просто через переменную "VCPKG_TARGET_TRIPLET": "x64-windows-static-mycustomtriplet".
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, SaZ, Вы писали:
SaZ>>Так можно с амишей брать пример =) SaZ>>Там нового — кот наплакал. Но зато более-менее нормальный менеджер пакетов в плюсах появился. А не то что всякие эти конанопитоны.
П>vcpkg? Он, кроме винды, где-то есть? Нормальный? Не помрёт?
Ну Майкрософт это не Гугл. Общедоступные проекты обычно внезапно не убивает. Плюс это таки опенсорс.
Нормальный. Субъективно лучше конана. И нет зависимости от питона.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, пффф, Вы писали:
П>>Здравствуйте, SaZ, Вы писали:
SaZ>>>Так можно с амишей брать пример =) SaZ>>>Там нового — кот наплакал. Но зато более-менее нормальный менеджер пакетов в плюсах появился. А не то что всякие эти конанопитоны.
П>>vcpkg? Он, кроме винды, где-то есть? Нормальный? Не помрёт?
SaZ>Ну Майкрософт это не Гугл. Общедоступные проекты обычно внезапно не убивает. Плюс это таки опенсорс. SaZ>Нормальный. Субъективно лучше конана. И нет зависимости от питона.
Не помрёт. У нас в Микрософт все проекты переводят с Conan на vcpkg.
Здравствуйте, пффф, Вы писали:
П>vcpkg? Он, кроме винды, где-то есть? Нормальный? Не помрёт?
CMake + vcpkg, собираем под Вин, мак, разные линухи, разное голое железо. Десятки разных зависимостей и кодо-генерация.
Пока не используем только для очень больших вещей типа Qt.
