C++ 编译与构建工具主要用于将 C++ 源代码转换为可执行程序。它们可以分为以下几类:
为了实现如标题所述的将多个静态库合并为一个动态库,内置的 Bazel 规则是没有这个功能的,Bazel C/C++ 相关的内置规则有:
在当今的软件开发世界中,构建工具的选择对于提高开发效率、维护代码质量以及提升团队协作能力都至关重要。谷歌作为全球技术巨头,为了解决大规模代码构建和测试的挑战,开发了一款名为Bazel的构建工具。Bazel具有强大的功能和灵活性,已成为开源社区中的明星工具。本文将深入探讨谷歌的Bazel构建工具及其在软件开发中的应用。
本篇文章通过https://github.com/bazelbuild/examples/tree/main/cpp-tutorial里面的例子,来简单介绍下bazel构建的基础知识,方便后续查找和学习。
Bazel 支持很多内置的规则,语言相关规则有 Shell、Objective-C、C++ 和 Java,比如 sh_binary、cc_binary、cc_import、cc_library、java_binary、java_import等。但是 Go 编译内置规则没有支持,不过好在 Bazel 支持规则扩展,可以自定义 Go 相关规则,包括可以实现如 go_binary、go_library、go_test等规则。而 `rules_go`[1] 就是 Bazel 官方维护的 Go Bazel 开源扩展规则。`gazelle`[2] 这个项目可以将 Go 项目转为 Bazel 方式构建,包括生成 BUILD.bazel 文件,根据 go.mod 文件自动生成下载依赖模块规则 go_repository。这里简单介绍下 rules_go 和 gazelle 相关内容,更多可以参考官方相关文档。
Bazel是一个类似于Make的编译工具,是Google为其内部软件开发的特点量身定制的工具,如今Google使用它来构建内部大多数的软件。(怪不得看起来很像Android.bp语法 O(∩_∩)O)
我们之前的文章里经常使用常规规则(regular rules)函数 rule() 来创建自定义规则,但是这些规则都有一个问题:他们依赖于主机系统上安装的各种工具。这样就会出现一个问题,即构建是不可复制的,如果同一项目上的两个开发人员安装了不同版本的 Go SDK,则他们将构建不同的二进制文件。它还会中断远程执行,即主机的工具链可能在执行平台上不可用。而 repository_rule() 就可以解决这个问题。
Istio由控制面和数据面组成。其中Envoy是Istio在数据面缺省使用的转发代理,Istio利用Envoy的四层和七层代理功能对网格中微服务之间的调用流量进行转发。今天我们来分析一下Istio 使用到的Envoy构建流程。
本文是何晓杰的译文 Soong 是原基于 make 的构建系统的替代品。它使用 Android.bp 来取代 Android.mk,并使用类似于 JSON 的格式来描述一个模块的构建方案。 Android.bp 文件格式 Android.bp 的设计非常简单,没有条件判断或控制流语句。在 Go 语言中编写的构建逻辑没有任何复杂度。Android.bp 的语法和语义可能也类似于 Bazel BUILD 文件。 模块 模块在 Android.bp 文件中以一个模块类型开始,后面跟着一组
作者 | Motiejus Jakštys 译者 | 平川 策划 | 罗燕珊 本文最初发布于 Motiejus Jakštys 的个人博客。 免责声明:我在 Uber 工作,我的一部分职责是将 zig cc 引入公司。但这篇文章是我的观点,与 Uber 无关。 我日前在 Zig 的一场交流会上作了题为“Uber 引入 Zig”的 演讲。本文从技术和社交两方面简单介绍了“Uber 是如何使用 Zig 的”,而主要的篇幅是介绍“我把 Zig 带到 Uber 的经验”。 本文要点: Uber 使用
之前分析过 Android 系统中的进程间通信逆向,即基于 Binder 拓展的以及 AIDL 描述的 IPC。了解 Android 系统的话应该知道在 8.0 之后,/dev/binder 拓展多出了两个域,分别是 /dev/hwbinder 和 /dev/vndbinder 。其中 hwbinder 主要用于 HIDL 接口的通信,而 vndbinder 则是专注于 vendor 进程之间的 AIDL 通信。
本文会讲述 Bazel 自定义工具链的两种方式,Platform 和 Non-Platform 方式。会存在这两种方式的原因是 Bazel 的历史问题。例如,C++ 相关规则使用 --cpu 和 --crosstool_top 来设置一个构建目标 CPU 和 C++ 工具链,这样就可以实现选择不同的工具链构建 C++ 项目。但是这都不能正确地表达出“平台”特征。使用这种方式不可避免地导致出现了笨拙且不准确的构建 APIs。这其中导致了对 Java 工具链基本没有涉及,Java 工具链就发展了他们自己的独立接口 --java_toolchain。因此非平台方式(Non-Platform)的自定义工具链实现并没有统一的 APIs 来规范不同语言的跨平台构建。而 Bazel 的目标是在大型、混合语言、多平台项目中脱颖而出。这就要求对这些概念有更原则的支持,包括清晰的 APIs,这些 API 绑定而不是分散语言和项目。这就是新平台(platform)和工具链(toolchain) APIs 所实现的内容。
genrule 的 参数 分为:sources,a tool(例如一个内置命令,一个shell脚本),一条命令,outputs
Makefile 是一个用于构建和管理项目的工具,特别适用于 C/C++ 项目。它定义了项目中各个文件之间的依赖关系,并指定了如何编译和链接这些文件。以下是一个简单的 Makefile 文件的示例,以及对其中关键部分的详细解释:
systemServer进程会在ZygoteInit中进行创建,而ZygoteInit是Zygote进程启动的。
你或许听过好几种 Make 工具,例如 GNU Make ,QT 的 qmake ,微软的 MS nmake,BSD Make(pmake),Makepp,等等。这些 Make 工具遵循着不同的规范和标准,所执行的 Makefile 格式也千差万别。这样就带来了一个严峻的问题:如果软件想跨平台,必须要保证能够在不同平台编译。而如果使用上面的 Make 工具,就得为每一种标准写一次 Makefile ,这将是一件让人抓狂的工作。
当C语言工程很大,源码非常多时,如果还去使用GCC命令编译程序,几乎是不现实的。这时候,可以通过编写shell脚本去执行编译命令,当然这并不是一种好的方式。在Linux上我们可以写shell脚本,在Windows上则可以编写bat脚本
本文示例可见:https://github.com/ikuokuo/start-cpp20
根据cmake编写命令(CMakeLists.txt),生成对应的makefile文件(Makefile)。
2021 年 11 月,我们决定评估 arm64 架构在 Uber 的可行性。我们的大多数服务是用 Go 或 Java 编写的,但我们的构建系统只能编译成 x86_64。现在,得益于开源合作,Uber 拥有了一个独立于系统的构建工具链,可以无缝地支持多种架构。我们使用这个工具链来引导 arm64 主机。本文将分享我们是如何着手去做这件事情的,以及我们早期的想法、遇到的问题、达成的一些成就和未来的方向。
Android.bp是用来替换Android.mk的配置文件,它使用Blueprint框架来解析。Blueprint是生成、解析Android.bp的工具,是Soong的一部分。Soong则是专为Android编译而设计的工具,Blueprint只是解析文件的形式,而Soong则解释内容的含义,最终转换成Ninja文件。
如果我们是在Linux下开发,那Makefile肯定要知道,不懂Makefile,面对较大的工程项目的时候就会比较麻烦,懂得利用开发工具将会大大提高我们的开发效率,也可以说Makefile是必须掌握的一项技能。
不同编程语言编写的应用,在它运行的状态下,会有不同的运行机制,有的是以二进制的方式运行的,有运行在编程语言的虚拟机之上。而构建所做的事情呢,就是将那些我们写给人类看的代码,转换为机器/程序能看懂的代码。所以,构建的本质就是翻译(~~复读机~~)。
Makefile由一系列规则组成。每个规则包括一个目标(target)、一个或多个依赖(dependencies)和一组命令(commands)。目标是我们想要生成的文件,依赖是生成目标所需要的文件,命令是生成目标的具体步骤。
Makefile是一个规定了怎么去编译和链接程序的脚本文件,在执行make命令时会执行该文件,window环境下的IDE,如visual studio已经集成了该功能,不需要关心程序的编译规则,在linux下做C/C++开发时经常用到,会写Makefile是程序员的必备技能。说到这里首先要知道一个工具make。
Mach-O(Mach Object)是 macOS、iOS、iPadOS 存储程序和库的文件格式。对应系统通过应用二进制接口(application binary interface,缩写为ABI) 来运行该格式的文件。
本篇文章主要描述CMake的基本用法。在之前的文件中我对Makefile,Autotools这两个构建工具。相关文章如下:
简单地说,我们在PC机上编译程序时,这些程序是在PC机上运行的。我们想让一个程序在ARM板子上运行,怎么办?
阅读笔者的其他文章,我们了解了编译过程中的预处理、词法分析、语法分析、编译、链接等步骤。经常和编译型语言打交道的开发者对于可执行文件的编译过程肯定不陌生。我们用 Xcode 构建一个程序的过程中,会把源文件 (.m 和 .h) 文件转换为一个可执行文件。这个可执行文件中包含的字节码将会被 CPU (iOS 设备中的 ARM 处理器或 Mac 上的 Intel 处理器) 执行。
原生的应用程序比转换的应用程序运行效率更高,因为编译器能够针对目标架构来优化代码。如果一个应用程序只支持 x86_64 架构,那必须在 Apple 芯片上的 Rosetta 转换下运行。通用二进制文件本身就可以在 Apple 芯片和基于 Intel 的 Mac 机上运行,因为它包含了两种架构的可执行代码。
主要区别就下面的生成{templator}的不同,后者进入仓库的tools/manifest-templator/目录后执行go build生成可执行文件然后复制到{templator}路径。
DLL劫持是一种用于执行恶意有效负载的流行技术,这篇文章列出了将近300个可执行文件,它们容易受到Windows 10(1909)上相对路径DLL劫持的攻击,并展示了如何使用几行VBScript绕过UAC可以以提升的特权执行某些DLL劫持。
本附录显示了如何在 OpenCV 应用中设置 Pygame 库以及如何使用 Pygame 进行窗口管理。 此外,附录还概述了 Pygame 的其他功能以及一些学习 Pygame 的资源。
Makefile 是一种特别设计用来帮助项目的构建管理的文件。它定义了编译器和IDE工程管理系统自动执行的命令集合,主要用于自动化编译,减轻重复性任务的负担。Makefile 文件中包含了一系列的规则来指导如何产生目标文件,这些规则包含目标、依赖和命令:
写本文的起因是我想让分布式 PyTorch 程序更快的在 Facebook 的集群上启动。探索过程很有趣。也展示了工业机器学习需要的知识体系。
前面章节我们了解了ELF文件的头部结构,这次我们深入了解另一个非常重要的数据结构,那就是程序表头。操作系统严重依赖该结构来加载ELF文件或是实现动态链接。程序表头反映的是当ELF加载到内存后所形成的“视图”或结构,也就是说ELF文件存在硬盘上或者被加载到内存,它展现出来的形态不一致。
Linux and Unix are very popular with programmers, not just due to the overwhelming array of tools and environments available but also because the system is exceptionally well documented and transparent. On a Linux machine, you don’t have to be a programmer to take advantage of development tools, but when working with the system, you should know something about programming tools because they play a larger role in managing Unix systems than in other operating systems. At the very least, you should be able to identify development utilities and have some idea of how to run them.
要解决上述的问题,我们需要一个构建脚本/工具来自动化的在开发、持续集成、预发布阶段提供下列功能:
CMake是一个跨平台的安装编译工具,可以用简单的语句来描述所有平台的安装编译过程。
Xcode 15 之后可以进一步合并动静态库(mergeable libraries),根据需要设置 Build Settings —> Create Merged Binary 对应的值即可。
首先感谢那位叫“任麒麟”的网友整理的PDF,有心了。 我也忘了哪里下载的,不过确实挺全的。
至于 CLion 安装和基础设置,网上教程一大把,而且不是学习重点,根据自己需求配置即可。
近期的 protobuf v22和 gRPC v1.55 版本在构建流程层面引入了一些比较大的变化。 最初我关注到这个问题是在我参与的一个社区项目 opentelemetry-cpp 的issue中( https://github.com/open-telemetry/opentelemetry-cpp/issues/2095 )。 直到后来,我们在自己的构建系统 cmake-toolset 对 protobuf 和 gRPC 也进行了升级。所以顺带给社区的项目也提交了一些相关的Patch,在这里分享一下可能其他同学也会碰到。
CMake的全称是Cross-platform Make。我第一次参与Linux C++开发时使用的工具是Make,而后开始切换到CMake,一开始以为CMake是和C语言有关,原来开头的C表示它可以跨平台。
1、安装编译软件,编译后生成shc文件就是命令程序yum install glibc-devel gcc c++ -ycd /usr/srcwget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.9.tgztar xzf shc-3.8.9.tgzcd shc-3.8.9/make查看帮助手册[root@localhost shc-3.8.9]# ./shc -helpshc Version 3.8.9, Generic Script Compiler
在 iOS 和 macOS 开发中, Swift 包现在变得越来越重要。Apple 已经努力推动桥接那些缝隙,并且修复那些阻碍开发者的问题,例如阻碍开发者将他们的库和依赖由其他诸如 Carthage[1] 或 CocoaPods[2] 依赖管理工具迁移到 Swift 包依赖管理工具的问题,例如没有能力添加构建步骤的问题。这对任何依赖一些代码生成的库来说都是破坏者,比如,协议和 Swift 生成。
经过长时间学习和研究linux GNU make工程管理器 ,现在把学习心得与大家分享一下,希望本文能教会您一些有用的东西。
在编译一个大型项目的时候,往往有很多目标文件、库文件、头文件以及最终的可执行文件。不同的文件之间存在依赖关系(dependency)。比如当我们使用下面命令编译时: $gcc -c -o test.o
从CDSW1.1.0开始支持GPU,具体可以参考Fayson之前的文章《如何在CDSW中使用GPU运行深度学习》,从最新的CDSW支持GPU的网站上我们可以查到相应的Nvidia Drive版本,CUDA版本以及TensorFlow版本,如下:
领取专属 10元无门槛券
手把手带您无忧上云