Conan 2.0 版本已经发布很久了,配套的 cmake-conan 工具也同时得到了更新,在原有 Conan 1.x 版本上增强了功能,对开源项目和公司内部已有的 CMake 项目非常友好,接入简单。本文主要介绍 cmake-conan 的应用场景以及交叉编译的实战。
上一篇博客《conan入门(七):将自己的项目生成conan包》中我们以jsonlib为例说明了如何将自己的模块封装成conan提供给第三方使用。
上一篇博客《conan入门(八):交叉编译自己的conan包项目》中我们以jsonlib为例说明了如何将交叉编译自己封装成conan的模块。但是使用的DS-5 ARM的交叉编译器(arm-linux-gnueabihf)并不常见,也不方便读者实际操作。
之前我写过的两篇博客《conan入门(十):Windows下Android NDK交叉编译Boost》,.《conan入门(十一):Linux下Android NDK交叉编译Boost》中介绍了在Linux和Windows下NDK交叉编译boost的过程
在上一篇博客《conan入门(四):conan 引用第三方库示例》中我们以cJSON为例说明了如何在项目中引用一个conan 包。那是比较简单的一种编译本机目标代码的应用场景(编译环境是Windows,目标代码也是Windows平台)。在物联应用的大背景下,C/C++开发中跨平台交叉编译的应用是非常广泛的。在使用conan来管理C/C++包(制品库)的环境下,如何实现对交叉编译的支持呢?因为我的工作涉及不少嵌入式平台的开发,conan对交叉编译的支持是我最关心的部分。
上一篇博客《conan入门(九):NDK交叉编译自己的conan包项目塈profile的定义》中我们以jsonlib为例说明了如何NDK交叉编译自己封装成conan的模块及定义profile简化编译的方式。
xmake 是一个基于 Lua 的轻量级跨平台构建工具,使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
CMake 详细说明参考官方文档 https://cmake.org/cmake/help/latest/index.html,其中latest为最新版本版本,不同 CMake 版本,API 有差异,请根据当前项目设置的最低版本来参考,高版本 API 在低版本无法使用。3.20之后的文档会标记该 API 的生效版本
上一篇博客《conan入门(十六):profile template功能实现不同平台下profile的统一》以Android NDK交叉编译为例介绍了jinja模板在conan profile中的应用。如果针对不同的Android目标平台(armv7,armv8,x86,x86_64)都要维护一个profile也是挺麻烦的。本文在此基础上,更进一步改进将android NDK 对不同平台armv7,armv8,x86,x86_64交叉编译的profile基本于同一个模板统一实现
它使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
今天在Windows平台如下正常执行conan NDK交叉编译Boost库时报了个错
它的语法简洁易上手,对新手友好,即使完全不会 lua 也能够快速入门,并且完全无任何依赖,轻量,跨平台。
疫情期间,宅家两月,对xmake内部做了不少的重构来改进,并且新增了不少实用的新特性,欢迎来体验。
最近工作的一个单片机项目项目,用了一款不知名的芯片,坑爹的开发商提供的编译器中有C++编译器,但是不能正常工作。好在我们的项目是纯C项目不需要C++编译器,只要在项目的cmake脚本中project命令指定为Cproject($NAME LANGUAGE C),这个坑就暂且绕过。
在我的之前关于conan系列博客中,已经介绍过如何引用Conan中央仓库(conan-center)预定义的第三库(《conan入门(五):conan 交叉编译引用第三方库示例》),以及如何将自己的项目封装为Conan包以供第三方引用(《conan入门(七):将自己的项目生成conan包》)。
对大型项目来说,必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言,依赖管理一直是一个比较头大的问题。 很多老式的系统和工具都会尝试去走相对标准化的安装过程,比如说用 pkg-config 或者用系统自带的包管理工具装在系统默认路径里。 当然这样很不方便,也不容易定制组件。我使用 cmake 比较多,所以一直以来在我的 atframework 项目集中有一个 utility 项目 atframe_utils,里面包含一些常用的构建脚本。 并且在 atsf4g-co 中实现了一些简单的包管理和构建流程。
我们经常需要从现有二进制文件创建包,比如第三方或供应商提供的C/C++库(只有include和lib),或在引入conan管理包之前手工编译编译好C/C++库。在这种情况下,我们并不需要conan从源代码编译,费时费事或根本不可能。所以以下情况我们可以考虑直接将本地已经编译好的二进制文件生成conan包:
XMake是一个基于Lua的轻量级跨平台自动构建工具,支持在各种主流平台上构建项目。
现在我们已经收集了足够的信息,可以开始讨论 CMake 的核心功能:构建项目。在 CMake 中,一个项目包含管理将我们的解决方案带入生活的所有源文件和配置。配置从执行所有检查开始:目标平台是否受支持,是否拥有所有必要的依赖项和工具,以及提供的编译器是否工作并支持所需功能。
这个版本重点对其他语言的支持做了一些改进,比如新增了fortran的编译支持,zig语言的实验性支持,另外对golang/dlang增加了第三方依赖包支持以及交叉编译支持。
文档在所有软件项目中都是必不可少的:对于用户,解释如何获取和构建代码,并说明如何有效地使用您的代码或库,对于开发者,描述库的内部细节,并帮助其他程序员参与并贡献于您的项目。本章将展示如何使用 CMake 构建代码文档,使用两个流行的框架:Doxygen 和 Sphinx。
Xmake 是一个基于 Lua 的轻量级跨平台构建工具,关于 Xmake 与构建系统的介绍,我们已经在之前的文章中做了详细的介绍:C/C++ 构建系统,我用 xmake。
Makefile使用一种基于Tab键的语法,而CMake使用基于C的语法。这意味着CMake更加易读、易于维护,特别是对于大型项目而言。CMake的语法更加清晰,具有结构化的特点,易于开发人员阅读和理解,同时也更容易维护。相比之下,Makefile的语法相对较为简单,但也更加难以维护。
RTMP 协议 : RTMP 协议是基于 TCP 协议的实时消息传输协议 ( Real Time Messaging Protocol ) ;
包管理器可以帮助你更方便地安装依赖关系,并决定所安装的版本,提高你的开发幸福感。许多语言都有自己的包管理器,像 Node.js 的 npm/yarn、Rust 的 Cargo、Python 的 pip 等等。当然,C/C++ 也有它自己的包管理器!下面我们就来感受下这些库的魅力和特点吧~
打造顶级软件并非易事。开发者在网上研究这一主题时,常常遇到的问题是如何判断哪些建议是更新的,哪些方法已经被更 fresh、更好的实践所超越。与此同时,大多数资源对这个过程的解释是混乱的,没有适当的背景、上下文和结构。
交叉编译算是每个嵌入式开发者都会经历的一道坎吧,通俗的描述就是搭建Arm板代码编译环境,让代码能够在Arm板子上跑起来。常用到的编译工具为Makefile和CMake,本篇记录下CMake的常用技巧。
Neuron 是一款开源的轻量级工业协议网关软件,支持数十种工业协议的一站式设备连接、数据接入、MQTT 协议转换,为工业设备赋予工业 4.0 时代关键的物联网连接能力。
如果你有定义himix200的工具链文件也可以使用CMAKE_TOOLCHAIN_FILE指定工具链文件来完成交叉编译 参见 https://gitee.com/l0km/faceapi/blob/master/faceapi-rpc-cpp/dependencies/cmake/arm-himix200-linux.toolchain.cmake
1 . 编译 FFMPEG 函数库 : 【Android FFMPEG 开发】FFMPEG 交叉编译配置 ( 下载 | 配置脚本 | 输出路径 | 函数库配置 | 程序配置 | 组件配置 | 编码解码配置 | 交叉编译配置 | 最终脚本 )
上一篇博客《conan入门(十):Windows下Android NDK交叉编译Boost》中已经说明了Windows下Android NDK交叉编译Boost的全过程。
编译链接时 , 将整个库文件打包到可执行文件中 , 造成可执行文件较大 , 但运行时不需要库文件 ;
本文介绍了如何将OpenCV库移植到ARM平台上,包括编译工具链、依赖库、配置方法以及运行时注意事项。
交叉编译脚本参考 : 之前已经做过两个函数库的交叉编译脚本 , FFMPEG 和 x264 开源库 , 而且都是使用 configure 生成 Makefile 文件 ;
看提示应该是在编译boost的依赖库libiconv/1.16报的错,在linux下交叉编译并不会报这个错误,
① H.264 标准 : H.264 是视频编码标准 , 由 ITU 和 MPEG 制订 ;
参考 【Android 安装包优化】使用 lib7zr.so 动态库处理压缩文件 ( 修改 7zr 交叉编译脚本 Android.mk | 交叉编译 lib7zr.so 动态库 ) 博客中的 p7zip 源码 , D:\develop\7zip\p7zip_16.02\CPP\ANDROID\7zr\jni\Android.mk 中的 -I 引入头文件参数中 , 涉及的头文件目录 ;
创建 Qt 工程时,我们通常使用 Qt 提供的 Online installer 安装 Qt Creator 和 Qt 库来创建、编译、发布 Qt 项目,这对开发环境和 CI Agent 环境有较强的要求,一旦环境安装不对或者安装时缺少了一些组件,可能导致无法编译出产物。最近一段时间,Qt 也拥抱 Conan,使我们可以通过 Conan 管理 Qt 库,这样我们就可以真正实现一套 CMake 脚本来管理和发布 Qt 的应用了。以下我们将演示如何通过 CMake + Conan 来组织 Qt 工程和实现程序的发布流程。
Keil MDK是非常常用的单片机开发集成环境,Keil公司2005年由ARM公司收购,现在是ARM主要的嵌入系统开发平台(ARM的另一个开发环境ds-5早在九年前就停止更新了)。 Keil虽然是个集成开发环境,但Keil本身其实是由μVision IDE和arm编译器构成。cmake虽然目前不支持生成μVision的工程文件,但cmake完全可以使用MDK中提供的arm编译器来实现独立于μVision的交叉编译(说到底μVision只是一个为开发者提供易用的GUI界面,真正干活儿的还是编译器)。 cmake实现交叉编译最重要的就是正确的定义编译工具链(toolchain),本文以Nationstech.N32G45X(国民技术)平台为例说明如何在定义cmake交叉编译工具链来实现使用MDK的armcc编译器执行单片系统的交叉编译。
在之前的一系列博客中使用 lib7zr.so 动态库处理压缩文件 , 本篇博客中使用静态库处理压缩文件 , 仅做参考 ;
程序员现在已经使用了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。 “做”不能这样做,至少没
实际项目中写的应用层代码为了保证可靠性,需要编写一定的测试用例,进行单元测试。 这里以GoogleTest为例 ,在嵌入式平台上(Amlogic A113x 平台)实现应用层代码的测试。
本文从一个示例开始:我们将创建一个使用cJSON应用程序来说明如何基于CMake 作为构建系统使用Conan无平台差异的引入依赖库。
最近有个科研课题需要在树莓派上做一系列验证,但是实验的程序是依赖OpenCV库的(最重要我们修改了库源码),而在树莓派上编译OpenCV源码很费时间,因此我只好使用交叉编译的方法来编译源程序。刚开始我们觉着网上材料大片,这部分的问题应该不大。可到操刀干活的时候,我才发现网上很多方法不仅繁琐,而且有的甚至还不是那么一回事,没看到一篇完全适合我的情况的。于是,我花了一天半左右的时间,整理这些材料并结合一点TRIZ原理,完成了这项任务。现在分享一下我的方案总结,不过我的方案不尽完善,欢迎大家指点修正,帮助后人节省时间。
领取专属 10元无门槛券
手把手带您无忧上云