有人能编译成功吗？ about flare HOT 26 CLOSED

git reset --hard; git clean -xdf .试试

从错误提示上来看这个目录下面好像不是flare的东西，里面提到的项目、glob之类的在flare的代码库都没出现过。

CMAKE BUILD卡住一段时间是正常的，这儿内部在编译使用cmake构建的目标。整个cmake过程对blade是不透明的所以进度不会有变化，取决于机器配置每个基于cmake的目标通常需要几分钟的水平。

from flare.

仔细看了下，里面出现的错误都是../../BUILD下面的外部文件，可以检查下本地的副本是不是有什么针对上级目录的符号链接之类的。

from flare.

仔细看了下，里面出现的错误都是../../BUILD下面的外部文件，可以检查下本地的副本是不是有什么针对上级目录的符号链接之类的。

没有。

from flare.

仔细看了下，里面出现的错误都是../../BUILD下面的外部文件，可以检查下本地的副本是不是有什么针对上级目录的符号链接之类的。

没有。

起个干净的容器在容器里面编试试。

from flare.

仔细看了下，里面出现的错误都是../../BUILD下面的外部文件，可以检查下本地的副本是不是有什么针对上级目录的符号链接之类的。

没有。

起个干净的容器在容器里面编试试。

你们教程写的是 blade build ... 没问题么
最后为什么是三个点

from flare.

我知道了。我这里是用的zsh。zsh里面三个点是有特殊含义的。切换到bash，可以编译。就是比较慢。我再等等看。

from flare.

仔细看了下，里面出现的错误都是../../BUILD下面的外部文件，可以检查下本地的副本是不是有什么针对上级目录的符号链接之类的。

没有。

起个干净的容器在容器里面编试试。

你们教程写的是 blade build ... 没问题么
最后为什么是三个点

三个点没问题，表示递归扫描所有目标。我们内部的CI也是blade test ...

from flare.

我知道了。我这里是用的zsh。zsh里面三个点是有特殊含义的。切换到bash，可以编译。就是比较慢。我再等等看。

from flare.

一直卡在这，这个是要下载么，还是什么。

from flare.

configure + make，thirdparty下面的依赖大多这样，一条命令实际上要编译很多东西，可以另开一个终端执行top观察系统有没有活动

from flare.

那这也太慢了。。编译brpc都没这么慢

from flare.

brpc的第三方库依赖是通过系统包管理工具安装的，不涉及编译

from flare.

磁盘被干满了。我理解我不需要把每个依赖库的源码下载下来编译把。。只要有so和头文件就行。而且有一些库我已经有了，另外你们这个依赖也太多了吧。你们在鹅厂内部都是用集群编译的吧……
感觉不够亲民，构建方式不优化，感觉flare很难推广啊。

from flare.

后续如果支持cmake的话可以用自行准备的依赖。

代码库自带依赖的话如果直接存二进制有abi问题（跨编译器版本、跨isa）。

如果支持bazel情况和blade类似。

from flare.

不需要开源项目的代码库提供二进制，使用者就自己准备就行。
奇怪的是你们这个没brpc复杂，依赖的东西却不少。应该有很多不是必须的吧…但是开源的时候没剔除干净？

from flare.

后续如果支持cmake可以自行准备依赖。blade及可能会支持的bazel均使用源码构建。

取决于“必须”怎么定义，flare有很多非“必须”的rpc的功能（一个足够精简的版本应该一个epoll就够了）以及非rpc功能（flare包含必要的基础库等，参考Tencent/yadcc的使用），这些也会引入自己的依赖。我可以确认目前没有未被引用的第三方库。

from flare.

我观察了一下，用我们内部的gcc8.2（有部分patch，但是应该对最终结果大小影响不大）编译的时候，编译大概需要7G的磁盘空间。这主要应当是调试符号占用空间。

如果磁盘空间不足的话，可以用blade build ... --no-debug-info，可以降低至大概2G。

第三方库的jemalloc主要是rpc/builtin/jemalloc_profiler_http_handler.cc在用，似乎可以用weak symbol消除这个依赖（同时移除example/rpc/je_server），后续我会在看看这个问题。xxhash目前只被BloomFilter依赖，倒是可以换成std::hash但是这个无论是对编译耗时或者最终大小应该都没什么帮助。

整体来说thirdparty对空间占用贡献不大，目前我观察大概build64_release/thirdparty大概850M，在第三方库上面做文章收益不会太大。

from flare.

别变成下一个tars。貌似腾讯的trpc也快开源了。也是基于同一个fiber吧。

from flare.

这边编译还有什么问题吗？没有的话我先close了。

from flare.

先别关。还没编译成功，两千多个编译目标。经常中途中断，我要重新执行blade。 等编译完再说吧。另外问一下你们这个不会往系统路径里安装吧。只是装到thirdparty吧？

from flare.

每次编译到gflags都失败… 我自己之前手工编译过gflags，没问题。这里不知道咋回事

from flare.

最后复制到~/.cmake/packages/...的行为不符合预期，可能跟cmake版本有关。

3.14及之前版本的cmake默认会往package registry安装信息。3.15及之后的cmake默认不会有这种行为。

稍后我会更新编译脚本对3.14及之前版本做兼容。

--

edit: gflags似乎需要它特有的参数来屏蔽这一行为，会在#31一并处理。

from flare.

给~/.cmake下面安装package元数据的问题应该解决了。

from flare.

我是cmake3.19，不过你更新完，确实可以继续编译了，又过了几个小时，刚刚编译完成了…可以close了。

from flare.

应该是 #31 里面-DREGISTER_XXX=OFF的效果。

没有细看原因，不过gflags好像会忽略cmake的默认行为（无论版本）始终往~/.cmake/packages/...写。之前在你的机器上可能是权限之类的原因导致的失败。

几个小时有点离谱了，可能有其他什么地方的影响，我这儿的一些数据：

• GitHub的Actions提供的2C的不知道是虚拟机还是Docker应该是30分钟左右编译完；
• 我们内部的10C（2.5GHz CSL）的虚拟机大概是接近9分钟；
• 16C的Docker（2.6GHz Zen2）大概是5分钟多点。

from flare.

如果还有什么问题的话随时打开。

from flare.