版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net/10km/article/details/51832822
CMake意为cross-platform make,可用于管理c/c++工程。CMake解析配置文件CMakeLists.txt生成Makefile,相比直接用Makefile管理工程,CMake更灵活和简单。
测试是代码开发工具箱的核心组成部分。通过使用单元和集成测试进行自动化测试,不仅可以帮助开发者在早期检测功能回归,还可以作为新加入项目的开发者的起点。它可以帮助新开发者提交代码变更,并确保预期的功能得以保留。对于代码的用户来说,自动化测试在验证安装是否保留了代码功能方面至关重要。从一开始就为单元、模块或库使用测试的一个好处是,它可以引导程序员编写更加模块化和不那么复杂的代码结构,采用纯粹的、函数式的风格,最小化并局部化全局变量和全局状态。
CPP已经结课,我提交的项目是Qt的入门项目,局域网聊天室LanChatRoom。
CMake的全称是Cross-platform Make。我第一次参与Linux C++开发时使用的工具是Make,而后开始切换到CMake,一开始以为CMake是和C语言有关,原来开头的C表示它可以跨平台。
首先,不得不承认,cmake很强大,发展了这么多年,整个生态已经相当完善,功能也相当丰富,这点xmake目前是比不了的。
由于macOS下的应用程序结构导致了CEF这样的多进程架构程序在项目结构、运行架构上有很多细节需要关注,这一块的内容比起Windows要复杂的多,所以本文将会聚焦macOS下基于CEF的多进程应用架构的环境配置,并逐一说明了CMake的相关用法和CEF应用配置细节。
CMake是一个主要用于CPP的构建工具。CMake语言是平台无关的中间编译工具。同一个CMake编译规则在不同系统平台构建出不同的可执行构建文件。在Linux产生MakeFile,在Windows平台产生Visual Studio工程等。CMake旨在解决各平台的不同Make工具的产生的差异(比如GNU Make, QT的qmake,微软的nmake, BSD的pmake)。
CMake 详细说明参考官方文档 https://cmake.org/cmake/help/latest/index.html,其中latest为最新版本版本,不同 CMake 版本,API 有差异,请根据当前项目设置的最低版本来参考,高版本 API 在低版本无法使用。3.20之后的文档会标记该 API 的生效版本
尽管 CMake 是跨平台的,在我们的项目中我们努力使源代码能够在不同平台、操作系统和编译器之间移植,但有时源代码并不完全可移植;例如,当使用依赖于供应商的扩展时,我们可能会发现有必要根据平台以略有不同的方式配置和/或构建代码。这对于遗留代码或交叉编译尤其相关,我们将在第十三章,替代生成器和交叉编译中回到这个话题。了解处理器指令集以针对特定目标平台优化性能也是有利的。本章提供了检测此类环境的食谱,并提供了如何实施此类解决方案的建议。
它的语法简洁易上手,对新手友好,即使完全不会 lua 也能够快速入门,并且完全无任何依赖,轻量,跨平台。
本文不是 odb 的教程,只是介绍如何在 WSL2 下使用 cmake 搭建 odb 应用的编译环境。
距离笔者的《使用CEF》系列的第一篇文章居然已经过去两年了,在这么长一段时间里,笔者也写了很多其它的文章,再回看《使用CEF(一)— 起步》编写的内容,文笔稚嫩,内容单薄是显而易见的(主要是教大家按部就班的编译libcef_dll_wrapper库文件)。笔者一直以来的个性就是希望自己学习到的知识,研究出的内容,踩过的坑能够及时的写出来,介绍给更多的小伙伴。
现在我们已经收集了足够的信息,可以开始讨论 CMake 的核心功能:构建项目。在 CMake 中,一个项目包含管理将我们的解决方案带入生活的所有源文件和配置。配置从执行所有检查开始:目标平台是否受支持,是否拥有所有必要的依赖项和工具,以及提供的编译器是否工作并支持所需功能。
你可能会认为,在我们成功将源代码编译成二进制文件之后,作为构建工程师我们的工作就完成了。事实几乎如此——二进制文件包含了 CPU 执行的所有代码,但代码分散在多个文件中,方式非常复杂。链接是一个简化事物并使机器代码整洁、易于消费的过程。
本节将会对文档进行总结和补充。所以建议先浏览一遍文档,或者看完本篇文章再回头看一遍文档。
对于大多数项目,源代码是通过版本控制系统进行跟踪的;它通常作为构建系统的输入,构建系统将其转换为对象、库和可执行文件。在某些情况下,我们使用构建系统在配置或构建步骤中生成源代码。这可以用于根据在配置步骤中收集的信息来微调源代码,或者自动化原本容易出错的重复代码的机械生成。生成源代码的另一个常见用例是记录配置或编译信息以确保可复现性。在本章中,我们将展示使用 CMake 提供的强大工具生成源代码的各种策略。
我们已经掌握了构建专业项目的所有必要知识;我们学习了结构化、构建、依赖管理、测试、分析、安装和打包。是时候将这些学到的技能付诸实践,通过创建一个连贯、专业的项目。
xmake 是一个基于 Lua 的轻量级跨平台构建工具,使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
该系列博客的应用场景是 Android Studio 下 NDK 编程 , 使用 CMake 构建 C/C++ 工程 ;
Hive在UDF中获取sessionId可以直接使用提供的java API,但是该UDF如果移植到Impala中是无法获取到Impala连接的SessionId的,要想获取Impala的SessionId,需要用C++来编写。
首先感谢那位叫“任麒麟”的网友整理的PDF,有心了。 我也忘了哪里下载的,不过确实挺全的。
Note:这篇文章是基于Android Studio 3.01版本的,NDK是R16。
Below is a step-by-step tutorial covering common build system use cases that CMake helps to address. Many of these topics have been introduced in Mastering CMakeas separate issues but seeing how they all work together in an example project can be very helpful. This tutorial can be found in the Tests/Tutorial directory of the CMake source code tree. Each step has its own subdirectory containing a complete copy of the tutorial for that step.
每个项目都必须处理依赖关系,而 CMake 使得在配置项目的系统上查找这些依赖关系变得相对容易。第三章,检测外部库和程序,展示了如何在系统上找到已安装的依赖项,并且到目前为止我们一直使用相同的模式。然而,如果依赖关系未得到满足,我们最多只能导致配置失败并告知用户失败的原因。但是,使用 CMake,我们可以组织项目,以便在系统上找不到依赖项时自动获取和构建它们。本章将介绍和分析ExternalProject.cmake和FetchContent.cmake标准模块以及它们在超级构建模式中的使用。前者允许我们在构建时间获取项目的依赖项,并且长期以来一直是 CMake 的一部分。后者模块是在 CMake 3.11 版本中添加的,允许我们在配置时间获取依赖项。通过超级构建模式,我们可以有效地利用 CMake 作为高级包管理器:在您的项目中,您将以相同的方式处理依赖项,无论它们是否已经在系统上可用,或者它们是否需要从头开始构建。接下来的五个示例将引导您了解该模式,并展示如何使用它来获取和构建几乎任何依赖项。
你或许听过好几种 Make 工具,例如 GNU Make ,QT 的 qmake ,微软的 MS nmake,BSD Make(pmake),Makepp,等等。这些 Make 工具遵循着不同的规范和标准,所执行的 Makefile 格式也千差万别。这样就带来了一个严峻的问题:如果软件想跨平台,必须要保证能够在不同平台编译。而如果使用上面的 Make 工具,就得为每一种标准写一次 Makefile ,这将是一件让人抓狂的工作。
至于 CLion 安装和基础设置,网上教程一大把,而且不是学习重点,根据自己需求配置即可。
我因为主力机是 Mac,所以使用的 IDE 是 CLion,CLion 也是 JetBrain 全家桶的成员之一。使用了 Android Studio 或者 IDEA 的同学可以很方便的切换到这个 IDE 上。此外 CLion 还是一个跨平台的 IDE,也就是说在 Windows Linux 上面也可以使用它。当然 Visual Studio 永远是最强的 IDE(手动狗头)。需要注意的是 CLion 是需要花钱买激活码的,似乎没有免费版开始能免费试用一个月左右的时间,所以激活码的获取途径大家就各显神通吧。
官方地址:https://www.eprosima.com/index.php/company-all/news/146-fast-rtps-is-now-fast-dds
CMake是一个跨平台的建构系统的工具,可以用简单的语句来描述所有平台的安装(编译过程)。他能够输出各种各样的构建文档makefile或者project文件,描述系统建构的过程。还能测试编译器所支持的C++特性,类似UNIX下的automake。只是 CMake 的组态档取名为 CmakeLists.txt。CMake并不直接建构出最终的软件,而是产生标准的建构档(如 Unix的 Makefile或 Windows Visual C++的 projects/workspaces),然后再依一般的构建方式使用。
在前几章中,我们已经展示了如何使用 CMake 配置、构建和测试我们的项目。安装项目是开发者工具箱中同样重要的一部分,本章将展示如何实现这一点。本章的节涵盖了以下图中概述的安装时操作:
使用 {}进行变量的引用。例如:message({Hello_VERSION}), Hello为工程名。CMake提供了很多有用的变量。以下仅列举常用的变量:
接上文:spring整合各种RPC框架(netty、dubbo、dubbox、gRPC、Motan)-续(Motan)
C++ 编译与构建工具主要用于将 C++ 源代码转换为可执行程序。它们可以分为以下几类:
👉导读 作为一个天然跨平台的产品,腾讯会议从第一行代码开始,团队就坚持同源同构的思想,即同一套架构,同一套代码,服务所有场景。过去一年,腾讯会议,迭代优化了 20000 个功能,稳定支持了数亿用户,其客户端仅上层业务逻辑代码就超 100 万行,经过优化,目前在 Windows 平台上的编译时间最快缩短到 10秒,成为行业 C++ 跨平台项目的标杆。本文将详细介绍背后的优化逻辑,希望给业界同行提供参考。 👉看目录,点收藏 1 编译加速有哪些方向? 2 如何优雅的预编译 Module 产物? 2.1 构建
文档在所有软件项目中都是必不可少的:对于用户,解释如何获取和构建代码,并说明如何有效地使用您的代码或库,对于开发者,描述库的内部细节,并帮助其他程序员参与并贡献于您的项目。本章将展示如何使用 CMake 构建代码文档,使用两个流行的框架:Doxygen 和 Sphinx。
大家好我是周旋,欢迎学习【烛照:QT机器视觉软件开发】项目。手把手视频教程已经在网站开始更新:
👉腾小云导读 作为一个天然跨平台的产品,腾讯会议从第一行代码开始,团队就坚持同源同构的思想,即同一套架构,同一套代码,服务所有场景。过去一年,腾讯会议,迭代优化了 20000 个功能,稳定支持了数亿用户,其客户端仅上层业务逻辑代码就超 100 万行,经过优化,目前在 Windows 平台上的编译时间最快缩短到 10秒,成为行业 C++ 跨平台项目的标杆。本文将详细介绍背后的优化逻辑,希望给业界同行提供参考。 👉看目录,点收藏 1 编译加速有哪些方向? 2 如何优雅的预编译 Module 产物? 2.1
当C语言工程很大,源码非常多时,如果还去使用GCC命令编译程序,几乎是不现实的。这时候,可以通过编写shell脚本去执行编译命令,当然这并不是一种好的方式。在Linux上我们可以写shell脚本,在Windows上则可以编写bat脚本
我觉得针对这个问题最简单(但不是最正确的)的回答应该是:“CMake是服务于将源代111码转换成可执行的文件的工具”。
我们知道,cmake提供了install指令可以让我们在项目构建完成后,通过make install命令,或者通过cmake --install . --prefix=<安装目录> 命令的方式来将CMakeLists.txt文件中通过install指令配置的文件安装到目标目录中。
在本书的最后一章中,我们将结合前面章节中讨论的多个不同的构建块,并将其应用于一个实际项目。我们的目标将是逐步展示如何将一个非平凡的项目移植到 CMake,并讨论这样的过程中的步骤。我们将为移植您自己的项目或为遗留代码添加 CMake 支持提供建议,无论是来自 Autotools,来自手工编写的配置脚本和 Makefile,还是来自 Visual Studio 项目文件。
打开debug configuration,增加一个Application,Target选postgres,Executable选择到源码目录的src/backend/postgres,程序参数写 -D 数据目录
CMake 工具能够自动生成 Makefile 文件,减轻手写 Makefile 文件的工作量,同时减少书写 Makefile 文件产生的错误。
windows平台使用MSVC开发的程序,默认会依赖运行时库,因此将程序安装到纯净的电脑环境后,执行程序时会弹窗提示缺少库,如下图。
程序员现在已经使用了CMake和Make了很久。当您加入大公司或开始使用大型代码库开发项目时,您需要处理所有这些构建。你必须看到这些“CMakeLists.txt”文件浮动。你应该在终端上运行“cmake”和“make”命令。很多人只是盲目地按照指示,不是真的关心为什么我们需要以某种方式做事情。这个整个构建过程是什么,为什么它这样构造?CMake和Make之间有什么区别?有关系吗?可以互换吗? 事实证明,它们是完全不同的。了解他们之间的区别是非常重要的,以确保您不会陷入困境。在分析之前,先看看它们是什么。 make 我们设计软件系统的方式是我们首先编写代码,然后编译器编译并创建可执行文件。这些可执行文件是执行实际任务的可执行文件。“Make”是从程序的源文件中控制程序的可执行文件和其他非源文件的生成工具。 “Make”工具需要知道如何构建程序。它了解如何从名为“makefile”的文件构建程序。这个makefile列出了每个非源文件以及如何从其他文件中计算它。编写程序时,应该为其编写一个makefile,以便可以使用“Make”来构建和安装程序。简单的东西!如果您不明白,请再次阅读该段落,因为下一部分重要。 为什么我们需要“Make”? 我们需要“Make”的原因是因为它使最终用户能够构建和安装您的软件包,而无需了解其操作的详细信息。每个项目都有自己的规则和细微差别,每当你有一个新的合作者,它都会变得非常痛苦。这就是我们有这个makefile的原因。构建过程的细节实际上记录在您提供的makefile中。根据哪些源文件已更改,“自动”自动显示需要更新的文件。它还自动确定更新文件的正确顺序,以防一个非源文件依赖于另一个非源文件。 每当我们改变系统的一小部分时,重新编译整个程序将是低效的。因此,如果您更改了一些源文件,然后运行“Make”,它不会重新编译整个事情。它仅更新直接或间接依赖于您更改的源文件的那些非源文件。很整洁!“Make”不限于任何特定语言。对于程序中的每个非源文件,makefile指定了用于计算它的shell命令。这些shell命令可以运行一个编译器来产生一个对象文件,链接器生成一个可执行文件,以便更新一个库,Makeinfo格式化文档等。“Make”不仅限于构建一个包。您还可以使用“Make”来控制安装或卸载软件包,为其生成标签表, CMake的 CMake代表跨平台制作。CMake识别哪个编译器用于给定类型的源。如果您不知道,您不能使用相同的编译器来构建所有不同类型的源。您可以在每次建立项目时手动执行,但这将是乏味和痛苦的。CMake为每种类型的目标调用正确的命令序列。因此,没有明确指定像$(CC)这样的命令。 为了编码真正想要血液细节的垃圾,请继续阅读。如果你不是所有的,你可以跳到下一节。处理包含头文件,库等的所有常见的编译器/链接器标记都被平台独立的和构建系统无关的命令所取代。调试标志包括将变量CMAKE_BUILD_TYPE设置为“调试”,或者在调用程序时将其传递给CMake: cmake -DCMAKE_BUILD_TYPE:STRING =调试。 CMake还提供平台独立包含'-fPIC'标志(通过POSITION_INDEPENDENT_CODE属性)和许多其他。尽管如此,还可以通过CMake以及Makefile(通过使用COMPILE_FLAGS和类似属性)手动实现更为模糊的设置。当然,当第三方库(如OpenGL)以便携式的方式被包含时,CMake真的开始闪耀。 有什么不同? 如果您使用Makefile,即在命令行中键入“make”,则构建过程有一个步骤。对于CMake,有两个步骤:首先,您需要设置构建环境(通过在构建目录中键入cmake <source_dir>或运行某些GUI客户端)。根据您选择的构建系统(例如,在Windows上的Make on * nix,VC ++或MinGW等),这将创建一个makefile或相当的东西。构建系统可以作为参数传递给CMake。但是,CMake根据您的系统配置做出合理的默认选项。其次,您在选定的构建系统中执行实际构建。 我们将在这里跳入GNU构建系统领域。如果你不熟悉,这一段可能看起来像是jibber-jabber给你。好的,现在我给了法定的警告,我们继续吧!我们可以比较CMake和Autotools。当我们这样做时,我们可以看到Make的缺点,它们构成了Autotools创建的原因。我们还可以看到CMake对Make的明显优势。Autoconf解决了一个重要的问题,即可靠地发现系统特定的构建和运行时信息。但这只是便携式软件开发中的一小部分。为此,GNU项目开发了一套集成的实用工具来完成Autoconf开始的工作:GNU构建系统,其最重要的组件是Autoconf,Automake和Libtool。 “做”不能这样做,至少没
它使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
ROS 2项目的目标是继承ROS 1的优点并改进不合适的部分。The goal of the ROS 2 project is to leverage what is great about ROS 1 and improve what isn’t.
领取专属 10元无门槛券
手把手带您无忧上云