Comments 19
vcpkg и системный пакетный менеджер не конфликтуют?
{
"name": "test",
"version-string": "0.1.0",
"port-version": 0,
"homepage": "",
"description": "",
"dependencies": [
"fmt",
"cli11",
"catch2"
]
}
В этом случае vcpkg автоматом поставит нужные библиотеки с нужным триплетом, при первой конфигурации проекта.
Во-вторых, под виндой делать vcpkg integrate install не всегда желательно, т.к. пути пропишутся для всех msbuild проектов. Лучше уж ручками добавить путь до тулчейна.
В-третьих, зачем CMAKE_CXX_STANDARD глобально выставляется?
А причем здесь CMake, если vcpkg — это пакетный менеджер, и ничего более.
conan — именно что интеграция локального окружения проекта в процесс сборки. И не предполагает использования для релизной продакшен сборки. Скорее, дополняет пробел в автозаполнении сборочного окружения, если пакетов не доступно для целевой платформы.
vcpkg — пакетный менеджер, который или излишен, или не полон. Conan — девелоперское окружение за две команды консоли в любой системе, не сломав систему. CMake — сборка по де-факто соглашениям, без обязаловки.
CMake — гибкая система сборки с сотнями конфигурируемых и установленных по умолчанию во вменяемые значения параметров. Зависимости могут предоставлять CMake конфиги, и тогда find_package() все для нас сделает, и нам не важно — vcpkg пакет, yum, apt, pacman, или -DCMAKE_FOO_ROOT=/usr/local/foo.
А зависимости могут и не предоставлять конфиги, тогда или pkg-config, штатно оборачиваемый CMake модулями, или вручную написанный модуль, подсунутый через CMAKE_MODULE_PATH.
Эмм, не совсем понял чем вам conan в проде не устраивает, не знаю многие ли его используют но он отлично применяется, у align technology даже не плохой доклад был об этом на предыдущей cpp russia
Может подскажите, как можно сказать vcpkg использовать определенный тулчейн?
К примеру, я хочу под Windows получить собранный с помощью clang-cl boost .
Для C++ есть и другой развитый пакетный менджер Conan, но он требует добавления файла conanfile.txt, а vcpkg обходится одним стадартным CMakeLists.txt
На самом деле можно все зависимости держать в CMakeLists.txt:
if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/v0.16.1/conan.cmake"
"${CMAKE_BINARY_DIR}/conan.cmake"
TLS_VERIFY ON)
endif()
include(${CMAKE_BINARY_DIR}/conan.cmake)
conan_cmake_configure(REQUIRES fmt/6.1.2
GENERATORS cmake_find_package)
conan_cmake_autodetect(settings)
conan_cmake_install(PATH_OR_REFERENCE .
BUILD missing
REMOTE conan-center
SETTINGS ${settings})
Ссылка на доки: https://docs.conan.io/en/latest/howtos/vs2017_cmake.html#using-cmake-conan
- Установка зависимостей
Проверить есть ли нужная библиотека
vcpkg search yourdepname
Установить
vcpkg install yourdepname
На самом деле, это ничем от conan не отличается, просто замените vcpkg на conan, и название пакета приведите к формату, который использует conan.
Фишка conan в том, что все зависимости описываются в файле и потом одной командой устанавливаются conan install .
C++ с кроссплатформенностью и зависимостями