How could I use flare in my own project? about flare HOT 9 OPEN

LFS bandwidth quota for our GitHub account has been reached. I just got notified about the situation several hours ago.

All repositories with LFS enabled under Tencent are suffering from this for the moment.

I believe our colleagues are working on this, though ETA not available for the moment, unfortunately.

from flare.

The issue w.r.t. LFS bandwidth quota has been fixed.

from flare.

Now, you can use flare as a dependency within a bazel project, see also https://github.com/Tencent/flare/blob/master/bazel/support/REAMD.md#using-flare-as-a-dependency

from flare.

I usually import flare as a submodule and symlink proj_root/flare to proj_root/path/to/flare-submodule/flare.

BLADE_ROOT / thirdparty can be provided either with a different (but compatible) version, or symlink to corresponding file in proj_root/path/to/flare-submodule/.

See Tencent/yadcc for example.

The trick here is blade will ignore a folder once it sees BLADE_ROOT (e.g., everything in proj_root/path/to/flare-submodule). Alternatively, you can add a file named .bladeskip in directory you want blade to ignore to achieve the same result.

With the sub-module directory ignored by blade, importing flare can be implemented by symlink-ing flare in sub-module directory to the root of the project.

from flare.

git clone https://github.com/Tencent/yadcc --recurse-submodules

would failed with the following error

Cloning into 'yadcc'...
remote: Enumerating objects: 294, done.
remote: Counting objects: 100% (294/294), done.
remote: Compressing objects: 100% (176/176), done.
remote: Total 294 (delta 68), reused 267 (delta 53), pack-reused 0
Receiving objects: 100% (294/294), 256.35 KiB | 1001.00 KiB/s, done.
Resolving deltas: 100% (68/68), done.
Submodule 'build/external/flare' (https://github.com/Tencent/flare.git) registered for path 'build/external/flare'
Cloning into '/root/git/yadcc/build/external/flare'...
remote: Enumerating objects: 3245, done.
remote: Counting objects: 100% (341/341), done.
remote: Compressing objects: 100% (282/282), done.
remote: Total 3245 (delta 118), reused 79 (delta 59), pack-reused 2904
Receiving objects: 100% (3245/3245), 16.66 MiB | 15.29 MiB/s, done.
Resolving deltas: 100% (1324/1324), done.
Downloading thirdparty/benchmark/benchmark-1.5.3.tar.gz (164 KB)
Error downloading object: thirdparty/benchmark/benchmark-1.5.3.tar.gz (e4fbb85): Smudge error: Error downloading thirdparty/benchmark/benchmark-1.5.3.tar.gz (e4fbb85eec69e6668ad397ec71a3a3ab165903abe98a8327db920b94508f720e): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

Errors logged to /root/git/yadcc/.git/modules/build/external/flare/lfs/logs/20210729T130030.744745693.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: thirdparty/benchmark/benchmark-1.5.3.tar.gz: smudge filter lfs failed
Unable to checkout 'd41ae2e5fdec1db1ed54f5cf6c829097a96a4541' in submodule path 'build/external/flare'

from flare.

After clone yadcc, we can see that

BLADE_ROOT -> build/external/flare/BLADE_ROOT
flare -> build/external/flare/flare/
thirdparty/* -> ../build/external/flare/thirdparty/*
build/blade/* -> ../external/flare/build/*

There are so many symlinks, it is not convenient to the outside users.

And I have preinstalled libs including(#benchmark, #benchmark, #tcmalloc, #gtest, #glog, #gflags, #protobuf etc.)
If BLADE_ROOT have to be compatibile, do I need to switch to those libs in flare/thirdparty?
To be honest, some libs in flare/thirdparty are too old, for example, protobuf 3.4.1 is released in 2017, the lastest version 3.17.3 is released last month.

from flare.

Well it’s symlinked that way just for convenience, you don’t have to symlink that way (nor use the same version). So long as a API-compatible version of each dependencies can be found under thirdparty/, Flare should build without problem.

Internally, for the most of the dependencies, we’re using a different version from the one provided in this repository. This is mostly for historic reasons, though.

So no, you don’t have to switch the dependencies to the specific versions Flare is using. If you provide a different version under thirdparty/, Flare will be built against the one you provided, and the one shipped with Flare is silently ignored.

Btw, I intentionally stripped all thirdparty/ prefix when including headers in source files. This was done as the first step to support other building systems as well as pre-installed libraries (those installed to /usr). Due to other difficulties (e.g. alternative to resource_library functionality of blade), I didn’t make much progress here for a while.

from flare.

Looking forward to the completion of the last point you mentioned.

from flare.

This issue comes again. 2022-6-22 16:44:05

===================================================

Downloading thirdparty/benchmark/benchmark-1.5.3.tar.gz (164 KB)
Error downloading object: thirdparty/benchmark/benchmark-1.5.3.tar.gz (e4fbb85): Smudge error: Error downloading thirdparty/benchmark/benchmark-1.5.3.tar.gz (e4fbb85eec69e6668ad397ec71a3a3ab165903abe98a8327db920b94508f720e): batch response: Post https://github.com/Tencent/flare.git/info/lfs/objects/batch: proxyconnect tcp: dial tcp: lookup socks5 on 192.168.2.15:53: server misbehaving

Errors logged to /home/mxnavi-sys/davidwang/yadcc/.git/modules/build/external/flare/lfs/logs/20220622T162855.613239384.log
Use git lfs logs last to view the log.
error: 外部过滤器 'git-lfs filter-process' 失败
fatal: thirdparty/benchmark/benchmark-1.5.3.tar.gz：smudge 过滤器 lfs 失败
无法在子模组路径 'build/external/flare' 中检出 '7a69d23947e6d4871b55b6ccb4ef0ca98bdb1025'

from flare.