Ответы пользователя по тегу Сборка проектов
  • Какую build system для C++ стоит изучать в 2023?

    Второй вопрос: минусы cmake

    Чёрт ногу сломит. Но что поделаешь, сегодня это считай стандарт.

    Точее сказать - пользоваться можно, и даже с удовольствием, но до сих пор новичкам приходится выискивать туториалы по тому как делать "правильно" и "современно". В официальных доках сложно (если вообще возможно) найти best practices, поэтому появляются такие проекты и учебники, как An Introduction to Modern CMake. Ещё полезно чейнджлоги смотреть, а то ещё два года пройдёт, пока узнаешь о появлении новых команд для работы с публичными хедерами библиотек.

    Можно ещё Meson глянуть, перспективная штука. Тот же Conan активно вкладывается в её поддержку.
    Ответ написан
    Комментировать
  • Как включить в статическую библиотеку все зависимости из других стат.библиотек в CMake проекте?

    Nipheris
    @Nipheris Куратор тега C++
    Господи, что ж тут за костыли насоветовали))

    Этого хотелось бы избежать, то есть нужно, чтобы все зависимости от boost были уже включены в mylib.

    Как верно отметил jcmvbkbc , обычно одна стат. библиотека не тащит в себе другую. Более того, такая возможность - включить одну стат. библиотеку в состав другой - мало где существует, я знаю про поддержку такой фичи только в Visual Studio. Ну т.е. это нечто из ряда вон выходящее, а не привычный workflow. По-нормальному вы должны указывать при линковке стат. библиотеки все её зависимости. Следовательно, вопрос в том, как эту информацию о транзитивных зависимостях статической библиотеки передавать и использовать при линковке с ней.

    pkg-config в общем вполне нормальное решение, но это уже не совсем "в рамках CMake".
    В рамках CMake всё делается с помощью target_link_libraries и экспорта симейк-конфига в паре с файлом симейковских таргетов. Например, вот такой незамысловатый скрипт:
    cmake_minimum_required(VERSION 3.5)
    find_package(Boost COMPONENTS system filesystem thread REQUIRED)
    add_library (mylib mysource.cpp)
    target_link_libraries(mylib
    	PRIVATE
    		Boost::system
    		Boost::filesystem
    		Boost::thread
    )
    
    install(TARGETS mylib EXPORT mylib_export)
    export(EXPORT mylib_export FILE cmake/mylib-targets.cmake)

    сгенерирует в поддиректории cmake в директории сборки файл mylib-targets.cmake, где помимо прочего будет следующая любопытная информация:
    # Create imported target mylib
    add_library(mylib STATIC IMPORTED)
    
    set_target_properties(mylib PROPERTIES
      INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:Boost::system>;\$<LINK_ONLY:Boost::filesystem>;\$<LINK_ONLY:Boost::thread>"
    )


    Таким образом, Симейк сообщает потребителям библиотеки mylib, что при линковке с ней нужно ещё добавить бустовские таргеты. Причём благодаря LINK_ONLY это коснётся только процесса линковки, в целом зависимость от библиотек буста будет приватной, как и указано в скрипте. Если поменять PRIVATE на PUBLIC и сделать тем самым зависимость от буста публичной, то LINK_ONLY уйдёт и будет обычное перечисление интерфейсных зависимостей таргета:
    # Create imported target mylib
    add_library(mylib STATIC IMPORTED)
    
    set_target_properties(mylib PROPERTIES
      INTERFACE_LINK_LIBRARIES "Boost::system;Boost::filesystem;Boost::thread"
    )


    Вам остаётся лишь добавить генерацию и установку тривиального конфига (где будет только find_package для буста и инклуд сгенерированного mylib-targets.cmake) и в потребителях делать find_package(mylib). Всё это кроссплатформенно и является стандартной практикой, не делайте лишних извращений со слиянием статических библиотек.
    Ответ написан
    Комментировать
  • Сборка проекта из рабочей копии и из архива - best practices?

    Передавать эту информацию через переменную окружения? И подставлять вручную/иными способами при сборке вне СКВ?

    Считаю, что номер ревизии (т.е. хэш коммита/имя тэга и пр.) должны извлекаться не сборочным скриптом, а передаваться через окружение. Большинство CI-серверов имеют хорошо документированные переменные окружения, которые задаются перед началом сборки. Эти же переменные окружения можно задать и вручную.
    Ответ написан
    Комментировать
  • Как исправить ошибку windowsSDKdir при сборке проекта в yeoman genrator?

    Собирать надо из командной строки "Developer Command Prompt", а не из обычной. Девелоперская консоль добавляет в PATH пути к тулчейну. Очевидно, сейчас msbuild никак не может найти CL.exe.

    Разберитесь сначала с этим, а потом посмотрим, надо ли вам WindowsSDKDir.
    Ответ написан
    1 комментарий