vscode开发环境搭建的思考
前言
一开始学习编程时,我先是用的dev,后来跟着教程配置过vscode的C语言环境,后面又折腾了qt,pycharm等,但都没有深入理解编译原理和配置过程中的各种细节,导致对编译原理的理解一直停留在表面,最近配置vscode的mdk环境时梳理了一下,在此记录。
最简开发过程
必要
- 编辑:编写代码,保存为.c文件
- 编译:使用编译器编译代码,生成可执行文件
- 运行:运行可执行文件,得到结果
非必要
我们学习时好像还有别的东西存在
比如:
- 语言服务:提供语法高亮,语法检查,这些是不必要但能极大提高开发效率的东西,这些功能是编辑器提供的,和编译原理无关。
- 工程管理器:比如make,cmake等,这些工具用于组织和管理编译过程(编译依赖、生成过程等),但它们本身不是编译器。它们负责调用编译器,而不是参与编译细节。
- 代码浏览工具(Code Browsing):包括代码跳转(跳到定义、引用)、结构树视图等,帮助开发者快速定位代码位置和理解项目结构。
- 其他各种插件
开发工具:以编辑器为核心
-
编辑器:vscode,sublime等,编辑器本身主要提供基本的文本编辑功能,其他功能如编译、调试、代码补全等需要通过插件实现。
-
编译器:gcc,clang,msvc等,提供编译功能
-
工程管理器(构建工具):make,cmake等文件越来越多的时候,需要工程管理器来管理文件依赖关系,编译顺序等。
-
语言服务器(LSP):语法检查自动补全
-
browser:文件查找,跳转
现代ide多是以编辑器为核心,编译器和工程管理器作为插件来实现的,现在还有很多用户自行配置的插件
下面以vscode为例,梳理一下配置过程(因为vscode本体是很存粹的编辑器,编译器和其他辅助功能都要自己配置,因此以它为例)
语言服务器
|
|
|
编译器------语言插件------编辑器------其他插件...
|
|
|
工程管理器
语言服务器:编辑器会调用语言服务器(LSP),语言服务器会调用编译器,语言服务器会提供语法高亮,语法检查,代码补全等功能。
编译器:提供编译功能,vsc插件并不提供编译功能,插件只是调用编译器。
工程管理器(构建工具):方便多文件编译,自动生成编译命令,自动编译,自动运行等。
配置过程
主要是配置各个插件,对于c/c++只需安装好c/c++插件即可,同时电脑上要有c/c++编译器,比如gcc,clang,mingw等。
此时编辑器还不知道编译器在哪个位置,
有两种办法让编辑器找到编译器:
- 在插件设置里配置编译器路径(CompilerPath)
- 在环境变量里配置编译器路径
配置梳理
在IDE的编译器配置过程中,有两种方法需要了解(单纯使用只需要配置一种):
-
编译器路径(Compiler Path):编译器的具体位置通常需要手动添加到编辑器插件的设置中。这种方式明确指定了编译器的路径,确保编辑器能直接找到并调用编译器。
-
环境变量(Environment Variable):环境变量 PATH 是一个系统级设置,它包含了多个路径,系统会按顺序在这些路径中寻找可执行文件。当编译器的路径被添加到 PATH 中时,编辑器无需额外配置就能通过命令行找到并使用编译器。
从编译器路径找编译器:
如果在插件中明确指定了编译器路径(例如 CompilerPath 设置),编辑器就会按照该路径调用编译器。它不会依赖系统的环境变量,而是直接使用配置中提供的路径。
其调用的命令类似于
D:\\1_me\\ComputerStudy\\mingw\\mingw64\\bin\\g++.exe -g main.cpp -o main.exe
从环境变量找编译器:
如果没有在插件中指定编译器路径,系统会依赖 PATH 环境变量进行搜索。系统会按顺序遍历 PATH 中的每个路径,直到找到匹配的编译器可执行文件为止。
其调用的命令类似于
g++.exe -g main.cpp -o main.exe
需要注意的是,系统按照 PATH 中的路径顺序进行搜索,因此 PATH 中路径的顺序会影响哪个编译器被优先调用。如果有多个编译器,确保所需编译器的路径排在前面
在命令行中调用可执行文件时,Windows 通常允许省略 .exe 扩展名。
linux里也有环境变量,在.bashrc,.bash_profile等文件里添加,找不到命令会逐个去这些文件里找。
魔乐社区(Modelers.cn) 是一个中立、公益的人工智能社区,提供人工智能工具、模型、数据的托管、展示与应用协同服务,为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作,由全产业链共同建设、共同运营、共同享有,推动国产AI生态繁荣发展。
更多推荐


所有评论(0)