它使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
大家好,我是道哥,今天我为大伙儿解说的技术知识点是:【使用 cmake 来构建跨平台的动态库和应用程序】。
前段时间集成一些公司内组件的时候发现它依赖 nghttp2 。正好之前一直有给我的构建工具(cmake-toolset)里的构建 curl 的流程加 HTTP/2 和 HTTP/3 的计划。 所以这波一次性搞定了。
xmake 是一个基于 Lua 的轻量级跨平台构建工具,使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
年初的时候我们项目组的构建系统( cmake-toolset )里把 protobuf 升级到了 v20/v3.20 版本, gRPC 也升级到了 v1.54 版本。然而这两个版本在Linux的ELF ABI和MacOS的Macho ABI下都出现了一些符号未定义的问题(当然也包含Android和iOS)。 这些问题也不仅限于 protobuf v20/v3.20 和 gRPC v1.54,后续的版本有些修复了,有些没有。在官方完全修复之前,我们自己打了一些patch去修复这些问题。
总第513篇 2022年 第030篇 减小应用安装包的体积,对提升用户体验和下载转化率都大有益处。本文将结合美团平台的实践经验,分享 so 体积优化的思路、收益,以及工程实践中的注意事项。本文将先从 so 文件格式讲起,结合文件格式分析哪些内容可以优化,然后再具体讲解每项优化手段以及注意事项,最后介绍相关的工程实践经验。希望能对从事包体积优化的同学有所帮助或启发。 1. 背景 2. so 文件格式分析 3. so 可优化内容分析 4. 优化方案介绍 4.1 精简动态符号表 4.2 移除无用代码 4.3 优
最近零碎的事太多了,拖了好久没写blog。一些小的碎片话的东西也不值得写,另一方面是这次大幅优化了 atframework 的一些流程细节,特别是针对我们这两年来业务的需求,对 libatbus 进行了一次大重构。这里记录一下重构的内容吧。
在项目开发过程中,避免不了要使用一些开源的三方库,我参加过的一些团队有不同的管理三方库的方式。不同的方式都各有优缺点,我们先列举一下碰到过的管理方式,说一些他们的优缺点,最后再来讨论我们今天介绍的管理方式弥补了哪些缺点。
至于 CLion 安装和基础设置,网上教程一大把,而且不是学习重点,根据自己需求配置即可。
该命令会调用编译器程序g++,让他读取main.cpp中的字符串(称为源码),并根据C++标准生成相应的机器指令码,输出到a.out这个文件中,(称为可执行文件)
在上一篇文章中,分享了一个跨平台的头文件是长成什么样子的,这个头文件对于 windows 平台下更有意义一些,因为要处理库函数的导入和导出声明(dllexport、dllimport)。
tabulate 是一个使用 C++ 17 编写的库,它可以制作表格。使用它,把表格对齐、格式化和着色,不在话下!你甚至可以使用 tabulate,将你的表格导出为 Markdown 代码。下图是一个使用 tabulate 制作的表格输出在命令行的样例:
首先,不得不承认,cmake很强大,发展了这么多年,整个生态已经相当完善,功能也相当丰富,这点xmake目前是比不了的。
对大型项目来说,必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言,依赖管理一直是一个比较头大的问题。 很多老式的系统和工具都会尝试去走相对标准化的安装过程,比如说用 pkg-config 或者用系统自带的包管理工具装在系统默认路径里。 当然这样很不方便,也不容易定制组件。我使用 cmake 比较多,所以一直以来在我的 atframework 项目集中有一个 utility 项目 atframe_utils,里面包含一些常用的构建脚本。 并且在 atsf4g-co 中实现了一些简单的包管理和构建流程。
QBDI全名为QuarkslaB Dynamicbinary Instrumentation,它是一个模块化的跨平台以及跨架构的DBI框架。该工具目前支持Linux、macOS、Android、iOS和Windows操作系统,支持的架构有x86、x86-64、ARM和AArch64架构。QBDI的模块化特征意味着它不需要包含任何首选的注入方法,并且可以结合外部注入工具一起使用。QBDI包含了一个基于LD_PRELOAD的小型Linux以及一个动态可执行的macOS注入器(QBDIPreload),它们是QBDI的Python绑定基础,即pyQBDI。QBDI还整合了Frida,一个动态指令工具集。
填一个之前的坑啊,本篇的姊妹篇——利用Pytorch的C++前端(libtorch)读取预训练权重并进行预测 这篇文章中已经说明了如何在Ubuntu系统中使用libtorch做预测,当初也有朋友问我如何在Windows之下尝试使用libtorch,当时因为时间关系没有去看,后来就给忘了…现在有时间了当然要尝试一下~
内容一览:TVM 共有三种安装方法:从源码安装、使用 Docker 镜像安装和 NNPACK Contrib 安装。本文重点介绍如何通过源码安装 TVM。
本文对CMake中库的打包,安装,导出以及支持find_package,使其能够很简单的应用到其他的项目中进行详细的总结。
OpenVINO是英特尔基于自身现有的硬件平台开发的一种工具套件,主要用于快速开发高性能计算机视觉及深度学习视觉的应用程序和解决方案,从而实现人类视觉模拟、自动语音识别、自然语言处理和推荐系统任务。该工具套件基于最新一代的人工神经网络,包括卷积神经网络、递归网络和基于注意力的网络,可扩展跨英特尔硬件的计算机视觉和非视觉工作负载,从而最大限度地提高性能。基于OpenVINO,可提升应用程序在CPU计算设备上的推理速度。
在上一篇文章中(使用 cmake 来搭建跨平台的应用程序框架:C语言版本),我们以源代码的形式,演示了利用利用 cmake 这个构建工具,来编译跨平台的动态库、静态库和应用程序。
Qt工程管理 个人比较偏爱于使用CMake来管理C++工程,因为只要编写一个CMakeLists.txt文件,就可以在Windows和Mac上生成各自的IDE工程。在Windows上, CMake自然是生成Visual Studio工程文件了(新版Visual Studio貌似能直接倒入CMake工程了);Mac上生成XCode工程即可。开发Qt应用程序的时候,虽然有Qt Creator可以使用,甚至Qt Creator还可以直接导入CMake工程,但是其调试和错误提示功能实在太过寒碜,导致调试过程中各种郁
wasm2c wasm2c —将WebAssembly二进制文件转换为C源代码和标头 wasm2c带有WebAssembly模块,并产生等效的C源代码。 选项如下: 命令 解释 -v - -verbose 多次使用以获取更多信息 - -help 打印帮助信息 -o -- output = FILENAME 生成的C源文件的输出文件,默认情况下使用stdout -- 启用例外 实验性异常处理 - -禁用-可变-全局 导入/导出可变全局变量 - 启用浮点到整数 饱和的浮点到整数运算符 - 启用符号扩展 符
Xmake 是一个基于 Lua 的轻量级跨平台构建工具,关于 Xmake 与构建系统的介绍,我们已经在之前的文章中做了详细的介绍:C/C++ 构建系统,我用 xmake。
https://zetaoyang.github.io/post/2016/11/05/linux-shared-object.html
今天讲的是纯干货,目的就是为了指导Android开发者如何根据JNI Crash日志顺藤摸瓜,最后直捣黄龙定位磨人的JNI Crash。所以废话不多,直接开干吧。
pybind11是一个轻量级的“Header-only”的库,它将C++的类型暴露给Python,反之亦然。主要用于将已经存在的C++代码绑定到Python。pybind11的目标和语法都类似于boost.python库。利用编译时的内省来推断类型信息。
这篇文章是一个尝试,因为写C的时候也有很多,这个头文件,以及各种依赖的库就很烦。 就像这样,写一个简单的二叉树 头文件报错的话,会提示使用这个安装 就尝试的使用一下,万一好香呢 我本来是想直接的安装
相比于传统行业,互联网浪潮中MySQL一直是数据库的主力军,无论是曾经的SUN,还是现在的Oracle,虽然可能商业策略不同,但发展方向还是平稳向前的,因此说自己不会MySQL,还真有些不好意思了。
工具概述 Clairvoyance是一款功能强大的Windows进程内存地址空间可视化工具,它可以针对一个Windows 64位内核中运行的整个64位进程地址空间(用户和内核)创建一个丰富多彩的页面保护可视化界面。 该工具利用hilbert空间填充曲线将一维空间即地址空间转化为二维可视化界面。上图中的每个彩色像素表示虚拟内存中4KB页的页保护(UserRead、UserReadWrite等)。 地址空间是通过从使用WindDbg生成的内核崩溃转储中手动解析与进程相关联的四级页表层次结构来直接计算的。 最后
CMake 详细说明参考官方文档 https://cmake.org/cmake/help/latest/index.html,其中latest为最新版本版本,不同 CMake 版本,API 有差异,请根据当前项目设置的最低版本来参考,高版本 API 在低版本无法使用。3.20之后的文档会标记该 API 的生效版本
Clangen使用 ClangSharp解析头文件来完成一些中间代码的生成(如Rpc的注册代码, 桩代码, C++类导出到Lua的代码等). 而ClangSharp本身依赖了llvm, 以及自己的一个libClangSharp的库, windows和linux下需要编译一下llvm和这个库, 一般来说系统没变的情况下, 直接使用已经编译好的libclang.so/dll即可, 但有些时候遇到需要升级llvm到高版本的情况, 比如说我们之前碰到的情况 , llvm9在linux下运行速度异常(Windows下10S的流程, 在linux下处理同样的任务要快3分钟, 最后发现可能之前编译使用的是debug版本), 我们需要编译LLVM, 并且编译依赖llvm的libClangSharp, 官方文件比较简单, 而且配置项有一些问题, 可能导致不能正常编译, 所以这里记录下过程方便后续有相关需求的时候可以参照处理.
这种要求对于 Linux 系列的平台来说,还是比较好处理的,大部分情况下只需要换一个交叉编译工具链即可,涉及到硬件平台相关部分再嵌入几个内联汇编。
这篇文章主要是视频教程的辅助文档,把其中的一些重要的内容放在这里,强化一下印象,更好的理解教程内容。
B(l)utter是一款针对Flutter移动端应用程序的逆向工程分析工具,当前版本的B(l)utter仅支持Android libapp.so(ARM64),可以帮助广大研究人员对基于Flutter开发的移动端应用程序进行逆向工程分析。
https://www.toutiao.com/i6920405760988201479/
本文档旨在收集对C++最佳实践所进行的协作性讨论,是《Effective C++》(Meyers) 和《C++ Coding Standards》(Alexandrescu, Sutter) 等书籍的补充。在讨论如何确保整体代码质量的同时,补充了一些没有讨论到的较低级别的细节,并提供了具体的风格建议。
之前分享过一篇关于 cmake 的入门文章:《使用 cmake 来搭建跨平台的应用程序框架:C语言版本》,那篇文章重点是描述如何利用 cmake 来编译或者构建跨平台的工程,并没有涉及到团队协作开发方面的内容。
curl是一个成熟的HTTP client库,现在windows平台下可以使用cmake在命令行完成编译。
如果你是在自己的电脑上运行客户端,可能会受到UWP的回路限制,无法连接上自己的服务器,此时需要管理员身份运行cmd,并执行以下指令
5. 选择启动项 : 点击绿色的小三角按钮 “选择启动项” , 选择上面生成的解决方案 “001_CMake_1.exe” 选项 , 如下图示 ;
CMake是一个跨平台的安装编译工具,可以用简单的语句来描述所有平台的安装编译过程。
前不久,微软正式发布了 Visual Studio 2022,Visual Studio 2022 的主要功能包括:
如今开源生态甚好,享受着便利的同时自然也要承担一些烦恼,每一个开发人员都遇到过各种各样的库的问题,通常都跟版本有关,软硬件的都有,今天有三来随便聊聊怎么应对,仅仅只是个人习惯。
你或许听过好几种 Make 工具,例如 GNU Make ,QT 的 qmake ,微软的 MS nmake,BSD Make(pmake),Makepp,等等。这些 Make 工具遵循着不同的规范和标准,所执行的 Makefile 格式也千差万别。这样就带来了一个严峻的问题:如果软件想跨平台,必须要保证能够在不同平台编译。而如果使用上面的 Make 工具,就得为每一种标准写一次 Makefile ,这将是一件让人抓狂的工作。
最近一直在研究cmake构建项目,之前接触cmake的时候就感觉不太喜欢cmake,觉得它太乱了,产生了太多的中间文件,产生的项目文件也不是特别友好,在windows下,生成的项目文件经常需要修改,而在linux和常规的makefile风格也打不一致,文件太多,不方便学习研究。
领取专属 10元无门槛券
手把手带您无忧上云