彩票走势图

CLion是一款专为开发C及C++所设计的跨平台IDE。它是以IntelliJ为基础设计的，包含了许多智能功能来提高开发人员的生产力。这种强大的IDE帮助开发人员在Linux、OS X和Windows上来开发C/C++，同时它还使用智能编辑器来提高代码质量、自动代码重构并且深度整合CMake编译系统，从而提高开发人员的工作效率。

点击下载CLion最新版本2019.3.4

CLion中项目模型的演变

如您所知，CLion中的所有工作都是在项目上下文中完成的。项目是编码帮助，批量重构，编码样式一致性和其他智能功能的基础。为了了解项目模型，CLion不仅收集项目文件列表，还收集编译标志，标头搜索路径和特定于项目模型的变量。IDE可以创建聚合这些参数的多个解析配置，您可以在必要时在编辑器中进行切换。

5年前，CLion在仅CMake的项目中启动，我们在博客中分享了做出该决定的理由。从那时起，CMake在C ++社区中稳定增长，并最终超过Visual Studio，成为C ++开发中最受欢迎的项目模型/构建系统。

但是，在C ++世界中，没有单一的标准项目模型。有Makefile项目，qmake，msbuild，Bazel，Scons等。Makefile项目位于前三名中，在OSS和嵌入式项目中很受欢迎，并且广泛用于跨平台C ++开发，这使它们成为添加到CLion的最佳人选。

在支持Makefile项目的过程中，我们采取了以下步骤：

• 在CLion中打开一个文件夹。在没有项目模型的情况下，CLion在非常基本的级别上对待所有代码，并且无法提供任何智能的编码帮助（例如转到符号或重构）。
• 编译数据库支持。这是一种真正通用的项目格式，可以从任何项目模型（包括任何自定义模型）生成。CLion为此类项目提供了完整的编码帮助，通常这是在CLion中打开任意项目的最简单方法。
• 支持自定义构建目标和自定义运行/调试配置。我们添加了此内容是为了丰富编译数据库或基于文件夹的项目的经验，因为CLion可以使用build / clean命令，并且可以运行和调试此类应用程序。

现在，可以使用“自定义构建目标”在CLion中构建，运行和调试任何项目（包括基于Makefile的项目），但它需要准确的手动设置。CMake项目的经验要好得多– CLion自动检测可用的目标来构建，以及可执行文件来运行/调试。我们也倾向于为基于Makefile的项目提供这种体验，但是，这需要大量的启发和调整。同时，您可以使用现有的Makefile插件来运行make目标（请注意，它不允许运行或调试可执行文件，为此您仍应使用“自定义构建目标”）。

这使我们进入了工作流程，用户可以在 File Watchers和编译数据库的帮助下处理 Makefile项目。主要的痛点是您必须安装工具才能从Makefile中提取编译数据库。但是，工作流是通用的，并且可以在本机不支持的任何项目模型（例如build2或其他模型）上顺利运行，如本视频中的Phil Nash所示。

支持Makefile项目：操作方法

现代C ++工具在IDE中没有统一的方式来处理Makefile项目。我们已经确定了几种方法（可在其他IDE和编辑器中使用），概述如下：

选项1：编译器包装

有一个名为scan-build的工具，可以通过在构建过程中拦截编译器调用来帮助您获取编译数据库。第一种方法使用类似的概念– IDE用包装器（使用CC和CXX环境变量，也通过PATH）替换实际的编译器，该包装器将记录编译命令，然后调用实际的编译器。

这种方法的主要好处是它不仅适用于Makefile项目，而且适用于任何构建系统。但是，这需要完整的构建，这可能会花费很长时间，并且可能无法在运行IDE的计算机上执行。

选项2：LD_PRELOAD

这种方法还从当前的工具Bear中获取了想法，该工具类似于选项1。简而言之，在类Unix系统上，可以设置LD_PRELOAD环境变量并指定一个动态库。在执行任何构建过程之前加载。这将允许拦截对编译器的任何调用。

这种方法对构建过程的干扰较小，这对某些脆弱的配置很重要。但这是特定于Unix的（也可在macOS上使用，但需要一些特殊权限）。

选项3：解析Make的输出

Make命令在其工作期间会打印出许多有用的输出，可以将其收集并重用于获取有关项目的信息。这个想法是第三种方法的基础。还有一个有用的--just-print选项，它有助于避免在项目重新加载期间实际构建项目，因此与常规的Make调用相比，可以获得更好的性能。

这种方法看起来不错，因为它不会影响构建过程，并且使我们可以比完整项目构建更快地收集信息。这也是一个“便携式”选项，因为理论上IDE可以从记录在另一台计算机上的Make输出开始。因此，尽管这种方法无法扩展到其他构建系统，但在我们看来，它似乎是我们早期研究的首选解决方案。

支持Makefile项目：CLion的原型

正如我们上面提到的，我们决定采用解析Make输出的方法，而不是通过将用于拦截编译器调用的工具带到用户环境来使用针对Makefile项目的编译数据库来自动化解决方法。在这条路线上，我们必须处理许多有趣的子任务：将编译命令与其他shell命令区分开；了解工作目录及其混乱的输出；以及许多其他需要实现特定启发式的事情。但毕竟，我们已经将其钉牢，并在CLion中获得了Makefile项目分析器的有效原型：

可能出现的问题

这是真正令人兴奋的地方！对大量Makefile项目的内部测试为我们提供了有关如何调整启发式方法的许多提示。让我们仔细看一下算法细节，以了解可能出了什么问题。

CLion运行Make，读取其输出，然后尝试解析它，以提取编译命令和工作目录。Entering/Leaving directory <dir>输出中的消息标识我们当前所在的工作目录。此信息是了解实际正在构建哪个源文件所必需的，因为通常相对于工作目录指定文件名。在某些项目中，这些消息也被替换为cd <directory> && gcc <file>。准确地提取此信息是算法的关键部分。

在这里很容易失败，因为有很多使Make静音的技巧。让我们更深入地了解“制作”选项！GNU Make的默认行为是打印目录。Makefile可以通过使用.SILENT伪指令来抑制它，但是调用Make with --print-directories会覆盖它。但是，Makefile可以通过设置来覆盖它GNUMAKEFLAGS=--no-print-directory，而在GNUMAKEFLAGS=--print-directory调用Make时，可以通过将其作为命令行选项传递来覆盖它。

在目录内部，输出消息被视为潜在的编译命令。CLion尝试解析它们，寻找已知的编译器及其标志。在失败的情况下，该行被视为只是一个文本字符串，因此将被跳过。有趣的是，有一些包装程序（如libtool）会隐藏编译标志并干扰Make的输出，从而使我们当前的方法失败。Shell和链接命令也会产生干扰，但是可以教导算法准确地跳过它们。

=====================================================

温馨提示：疫情期间返岗上班需戴口罩、勤洗手、常通风，做好防护措施！

想要购买Clion正版授权的朋友可以。

更多精彩内容，敬请关注下方的微信公众号，及时获取产品最新资讯▼▼▼