IT先森

LLVM 成长之后已成为众多编译工具及低级工具技术的统称，使得这个名字变得更不贴切，所以开发者决定放弃这个缩写的涵义，现在 LLVM 已独立成为一个品牌，适用于 LLVM 下的所有项目，包括 LLVM 中介码、LLVM 除错工具、LLVM cpp 标准库等。对于一个比较大的第三方库，其头文件和库文件的数量是比较多的，如果我们一个个手动地写，那将是相当的麻烦的。事实上，pkg-config只是一个工具，所以不是你安装了一个第三方库，pkg-config就能知道第三方库的头文件和库文件的位置的。

鉴于无法测试列表项的添加引入，可以这样使用：设置一个文件或标志的主列表，然后根据各种条件删除不适用于当前版本的文件或标志。构建应该做的大多数事情通常都可以在不这样做的情况下来完成，如果你觉得有必要，这可能表明你在元构建中做了太多的工作。一个值可以是一个域。当最终在命令中使用源路径时，它们会转换为对应于操作系统的（OS-appropriate）路径，这些路径是绝对的或相对于构建目录（运行命令的位置）的路径。这意味着，例如，当您定义target目标时，您在块内执行的任何操作都不会“泄漏”到文件的其余部分。

为了提高OpenHarmony下移植vivante gpu的成功率，先得把准备工作做足了，这样后续就好搞了。所以本文档的核心工作介绍GN构建工具在OpenHarmony中的常见使用方法，指导三方库由cmake或者其它的脚本构建到GN构建的转换！好了今天的博客OpenHarmony下gn相关使用就到这里了。当使用GN进行相关的构建时，需要了解如何指定动态库、静态库和可执行文件的构建规则。在GN中，可以使用executable模板来指定可执行文件的构建规则。3.4 GN在OpenHarmony上的扩展。

好了，感慨也发完了，是时候切入正题了。各位读友，千万不要喷我，因为我这也是第一次深入到OpenHarmony显示这块的源码逻辑，为啥我深入到了这块，因为入职了一家原厂。是的，这是因为无论是渲染的图层还是合成之后的图层它们都是通过SurfaceBuffer来进行存储指向的。有的只有是兄弟就砍一刀。其中，我们引用上述封装好的dump函数时候，我们在对应的BUILD.gn中必须，引入如下的库和头文件，如下。然后将获取到的地址中的内容，以一定的格式进行存储，通常是GRB888格式(也可以进行相关的封装)

没有关系，因为你看到了这篇，从此可以为你打开新世界的大门，增加一种调试手段，那就是OpenHarmony下打印C/C++调用堆栈。OpenHarmony值路漫漫吾将上下而求索，总之，各位，青山不改绿水长流先到这里了！这里的BUILD.gn必须是你需要跟踪堆栈的文件所对应的BUILD.gn中，而不是随便一个。这里的BUILD.gn必须是你需要跟踪堆栈的文件所对应的BUILD.gn中，而不是随便一个。这里的BUILD.gn必须是你需要跟踪堆栈的文件所对应的BUILD.gn中，而不是随便一个。

OpenHarmony送显流程分析OpenHarmony送显流程分析引言本文档主要记录OpenHarmony在渲染完成之后如何进行合成和送显流程的。这个过程牵涉的代码很多，而且流程也是比较繁琐的。所以我一定要坚持下来。千万不能半途而废，也不要想着一口气吃出一个胖子，路漫漫其修远兮吾将上下而求索！一. 应用端发送NextVSnc请求，服务端响应还记得那年大明湖畔的夏雨荷吗！

从bootamition出发分析OpenHarmony下Gralloc buffer管理机制从bootamition出发分析OpenHarmony下Gralloc buffer管理机制引言这个文档主要记录从bootamition角度出发，分析OpenHarmony下对gralloc buffer的管理！由于OpenHarmony图形子系统过于复杂，且个人由于能力有限，这里我仅从gralloc buffer出发，从整体上对Gralloc buffer进行梳理！虽然过程会很艰辛，但是我一定要坚持下来。

  博客沉寂很久，肯定不是干坏事被抓吃公交粮食去了！而是最近忙着给OpenHarmony鸿蒙适配GPU渲染加速。尼玛，其中的各种坑啊，填了一个又一个，其中最最拖延了开发进度的事情就是给鸿蒙适配我司的GPU的时候，无法使用鸿蒙自身的hilog调试！不能查看调试相关打印信息，你说这个还能继续下去吗。辛亏最最后想到了一种间接的调试小技巧，通过函数回调OpenHarmony鸿蒙进行相关打印。  当你在一个操作系统上移植第三方库时候，由于种种原因第三方库无法直接使用操作系统的debug接口，那么真的没有办法了吗，这里