在 VSCode 上部署 CMake + conan2

发布时间:2024年01月19日

之前也配过几次了,但配一次忘一次。xmake 之类的工具现在更方便,写个玩具什么的心智负担很低,但仍然有很多时候不得不去用 cmake,就需要配置这些玩意。

网上有相当数量的教程都是那几篇抄来抄去的,而且都是 conan1 的配置,conan2 的使用和以前区别还是很大的。每一次都不得不去翻不算太详细官方文档,索性在此记录一下怎么配置好了。

想流畅阅读本文,需要熟悉 vscode 的使用,和 cmake 最最基本的用法。

0x00 安装 conan

conan 是包管理器,让项目使用一些库更方便,不用自己手动管理,同时还提供可直接运行的二进制文件方便使用。很多语言都有类似的东西,python 的 pip、rust 的 cargo、js 的 npm/yarn/pnpm 等。C++ 并没有能独自撑起一片天的包管理器,但 vcpkg 和 conan 总的来说都还算不错的选择。conan 使用 python 编写,安装可以用 python 的 pip.

pip install conan

我个人可能愿意去使用 pipx 安装这种东西,命令都是大同小异的。

验证安装:

conan --version

conan version

正常打印版本号就是安装好了。

0x01 插件安装与 CMake 工程创建

插件安装

更习惯在 vscode 上码字,所以本文用 vscode 演示。需要安装三个插件:

  • clangd
  • CMake Tools
  • CMake

clangd
CMake Tools
CMake

个人更偏好 clangd 的代码补全,如果没配置过 clangd,使用微软的 C/C++ 插件也没关系的。

C/C++ Extension

CMake 工程创建

本文的重点是 conan 不是 cmake,多的就不说了。新建一个崭新的 CMake 工程,这里唯一要注意的是我手动在项目根目录创建了 conanfile.txt ,大家也手动创建一个空文件就好了。

项目目录

这里给出该工程的 CMakeLists.txt 内容,移除了对本教程的无关内容,让大家对这个项目都配置了啥有个大概印象。

cmake_minimum_required(VERSION 3.24.0)
project(xcamke VERSION 1.0.0 LANGUAGES C CXX)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

aux_source_directory(src source_files)
add_executable(${PROJECT_NAME} ${source_files})
target_include_directories(${PROJECT_NAME} PRIVATE include)

set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
include(CPack)

0x02 conan 配置

默认配置不一定适合你,需要了解怎么配置。

新建默认配置文件

打开终端,输入

conan profile detect --force

创建配置文件,它是根据当前设备信息进行的推断。

profile detect

最后一行输出是配置文件的路径,如果使用较新的终端,使用 ctrl + 左键即可快速跳转,不支持这个的终端老老实实复制路径打开文件。

配置文件创建一次后不要再重复创建了,否则后续操作中修改的配置会被再次覆盖

新建的配置内容大概是这样的:

[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.version=193
os=Windows

MSVC 挺好的,但正如我前文所说,我个人更倾向于使用的 lsp 是 clangd,它分析工程依赖于 compile_commands.json 文件,而 cmake 对于 msvc 工具链生成该文件的支持非常不好(这一点不如 xmake 等工具),所以我会演示如何更换编译器。

修改部分配置

不同编译器的写法是不同的,clang 的写法和 msvc 很相似。我安装的 clang 17 支持设置 C++23. 所以这里我修改了编译器、编译器版本、C++ 标准,请根据自己安装的编译器的版本按需配置。

[settings]
arch=x86_64
build_type=Release
compiler=clang
compiler.cppstd=23
compiler.version=17
os=Windows

gcc 的写法与前两个有所不同,这里演示 GCC 13,同样是支持设置 std=c++23 的编译器。

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=23
compiler.libcxx=libstdc++
compiler.version=13
os=Windows

实际上这部分我压根没查文档,gcc 是我根据报错信息一点点试出来的。不得不说 conan 的报错信息很有人文关怀,写得很详细。

0x03 安装包依赖

终于到安装包的时候了。打开 conanfile.txt,添加依赖。写法非常简单,但网上很多教程给到的写法已经过时了,并不适用于 conan2.

以安装 fmt 为例。首先我们在终端输入 conan search fmt 查看 fmt 库的可用版本,既然是教程演示,就用当前最新的 10.2.1 好了。将下列内容写入 conanfile.txt:

[requires]
fmt/10.2.1

[generators]
CMakeDeps
CMakeToolchain

是不是有点 cargo 的味儿了。(本人对 cargo 和 conan 谁早谁晚并不知情,请不要借此触发语言圣战)

写好依赖后,如果 cmake 已经自动为你生成了 build 文件夹,请删除。就绪后,输入

conan install . --output-folder=build --build=missing

会读取当前目录下的 conanfile.txt 并安装依赖包,并将相关文件输出到 build 目录下。安装时命令行输出还有用,暂时不要关掉。

等待读条完毕,当你难蚌笑意地导库写 int 🍜 时,等待你的却是…

package not found

明明过程中没有任何错误产生,为什么这依赖装了和没装一样呢?稍微思考一下,你 conan 有包了,关我 cmake 什么事呢?有好康的(包)不告诉我,我自然不知道你发育正不正常(生成 compile_commands.json)啊。

0x04 与 CMake 对接

这也是 conan2 相比 conan1 改动很大的地方。如果你的 vscode 在这过程中都没有重新启动过,那么可以看到状态栏左下角的工具包依然维持刚打开时的状态,或者已经是“未指定”了。

默认工具包

此时单击它,会让你重新指定工具包,却没有了之前的那些编译器,而是剩下了一个 ‘conan-release’ config.(如果找不到,请检查项目根目录是否生成 CMakeUserPresets.json 文件。如果有,重新加载 vscode 窗口;如果没有,删除 build 目录重新安装依赖)选择它,再次配置 cmake.

conan-release config

打开 CMakeLists.txt 文件,找到之前安装包的时候产生的命令行输出,添加 find_package(fmt REQUIRED) 一行。并在 add_executable 的后面添加 target_link_libraries(${PROJECT_NAME} fmt::fmt)

cmake 改

至于为什么 find_package 时要写 fmt,target_link_libraries 时却要写 fmt::fmt 呢?其实人家 conan 都告诉你了,打开我之前说过还有用的命令行输出:

命令行输出

最后几行告诉了你,find 和 link 时该怎么做。你可以看到我还偷偷安装了 glfw,而根据输出可以看到 glfw 在 find 时 需要写 glfw3,link 时需要写 glfw. 不同库写起来都不一样,多看输出,不要去猜测。

既然都说到这份上了,就提一嘴安装多个包具体改哪。其实也很简单,就以再增加一个 glfw 为例。

首先 conan search glfw 查版本,修改 conanfile.txt:

[requires]
fmt/10.2.1
glfw/3.3.8

[generators]
CMakeDeps
CMakeToolchain

终端输入

conan install . --output-folder=build --build=missing

安装新的依赖。根据命令行输出内容,打开 CMakeLists.txt,告诉 cmake 要找包、要链接包(绿色下划线部分为新增内容):

添加包

保存后默认会自动 configure. 这时再打开源文件,一切都好了起来。

check

result

可以看到结果也正常输出了。

0x05 开香槟 🍾

该说的都说完了。硬让我评价一下 conan 的话,那就是这东西哪都好,就是包太少了。看官网有 1600+ 的包,实际用起来仍然有很多方面覆盖不到。不过最常用的肯定是够吃了,偶尔用一下的偏门包就 git + mv 吧。

文章来源:https://blog.csdn.net/qq_39007641/article/details/135680399
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。