英文:
One Bazel project produces binary and static library files, another similar project only produces binary files
问题
我试图学习Bazel,因此我一直在使用它构建非常简单的项目,以了解它的工作原理和工具的一些细节。
目前,我有一个项目(称为Enigma),它构建了一个依赖我编写的一些库的main.cpp
文件(我以这种方式编写它来更好地理解Bazel规则,在这个特定项目中,拥有这些库并不是很有意义,但我偏离了主题)。当我运行构建时,我可以检查我的bazel-bin
目录,找到:
- 由我的
cc_binary
规则生成的二进制文件 - 由我实现的
cc_library
规则之一生成的静态库(*.a)文件
这对我来说是有道理的。我启动了一个新项目,LinkedList
,我希望它只是一个库。经过一些故障排除和研究,我决定我需要一个规则,依赖于cc_library
规则,以便Bazel实际构建它,所以我创建了另一个main.cpp
。当我运行构建时,我只从我的cc_binary
规则获得一个二进制文件,但没有从我的cc_library
规则获得*.a文件。我检查了我拥有的BUILD
文件,并没有找到明显不同的地方。两个项目的WORKSPACE
文件都是空的,而且两个项目都没有.bazelrc
文件。
以下是Enigma项目的BUILD
文件内容(在bazel-bin
目录中生成libsignal_converter.a
):
load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_library")
cc_binary(
name = "enigma",
srcs = ["main.cpp"],
deps = [":rotor", ":plugboard"]
)
cc_library(
name = "signal_converter",
srcs = ["signal_converter.cpp"],
hdrs = ["signal_converter.h"],
includes = ["."]
)
cc_library(
name = "plugboard",
hdrs = ["plugboard.h"],
includes = ["."],
deps = [":signal_converter"]
)
cc_library(
name = "rotor",
hdrs = ["rotor.h"],
includes = ["."],
deps = [":signal_converter"]
)
以下是Enigma项目的bazel-bin
目录内容:
_objs
enigma
enigma-2.params
enigma.cppmap
enigma.runfiles
enigma.runfiles_manifest
libsignal_converter.a
libsignal_converter.a-2.params
plugboard.cppmap
rotor.cppmap
signal_converter.cppmap
tests.cppmap
以下是LinkedList项目的BUILD
文件内容,它只生成一个二进制文件:
load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_library")
cc_binary(
name = "dummymain",
srcs = ["main.cpp"],
deps = [":linkedlist"]
)
cc_library(
name = "linkedlist",
hdrs = ["node.h", "linked_list.h"]
)
以下是LinkedList项目的bazel-bin
目录内容:
_objs
dummymain
dummymain-2.params
dummymain.cppmap
dummymain.runfiles
dummymain.runfiles_manifest
linkedlist.cppmap
为了确保,我确保在main.cpp
文件中包含我的库并初始化了每个类的一个实例。我得到了典型的“未使用变量”警告,但除此之外它构建和运行得如预期。
我的问题是,为什么我的Enigma项目生成*.a文件,但我的LinkedList项目没有?
如何配置我的构建以生成*.a(或*.so)库文件,无论是否有一个依赖于它们的cc_binary
规则?
我尝试过的方法:
起初,我的LinkedList项目的BUILD
文件只包含一个cc_library
规则。我认为Bazel没有构建该目标(尽管我运行了bazel build //src:linkedlist
),因为没有其他规则依赖于它,而且它是一个库目标(尽管我觉得我关于这个假设是错误的)。为了解决这个问题,我创建了一个main.cpp
文件,并陪伴它一个cc_binary
规则。这似乎触发了linkedlist
目标的构建,但我仍然没有在bazel-bin
中看到任何库文件。我本来期望它生成一个静态链接的二进制文件以及静态库(*.a)文件,但我只得到了二进制文件。
英文:
I am attempting to learn Bazel so I've been using it to build very simple projects in order to understand how it works and some of the ins and outs of the tool.
Currently, I have 1 project (called Enigma) that builds a main.cpp
file that relies on a couple of libraries I wrote (I wrote it this way to understand the Bazel rules better, in this particular project it doesn't really make sense to have these libraries, but I digress). When I run the build, I can check my bazel-bin
directory and find:
- a binary file produced by my
cc_binary
rule - a static library (*.a) file for one of the
cc_library
rules I implemented
This makes sense to me. I started a new project, LinkedList
that I wanted to build just as a library. From some troubleshooting and research, I decided I needed a rule that depends on that cc_library
rule in order for Bazel to actually build it, so I created another main.cpp
. When I run the build, I only get a binary from my cc_binary
rule, but no *.a files from my cc_library
rule. I've examined both the BUILD
files I have and cannot find anything glaringly different about them. Both projects' WORKSPACE
files are empty and neither project has a .bazelrc
file.
Here are the contents of my Enigma BUILD
file (which produces libsignal_converter.a
in the bazel-bin
directory):
load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_library")
cc_binary(
name = "enigma",
srcs = [ "main.cpp" ],
deps = [ ":rotor", ":plugboard" ]
)
cc_library(
name = "signal_converter",
srcs = [ "signal_converter.cpp" ],
hdrs = [ "signal_converter.h" ],
includes = [ "." ]
)
cc_library(
name = "plugboard",
hdrs = [ "plugboard.h" ],
includes = [ "." ],
deps = [ ":signal_converter" ]
)
cc_library(
name = "rotor",
hdrs = [ "rotor.h" ],
includes = [ "." ],
deps = [ ":signal_converter" ]
)
Here are the contents of the bazel-bin
directory of the Enigma project:
_objs
enigma
enigma-2.params
enigma.cppmap
enigma.runfiles
enigma.runfiles_manifest
libsignal_converter.a
libsignal_converter.a-2.params
plugboard.cppmap
rotor.cppmap
signal_converter.cppmap
tests.cppmap
Here is the contents of my LinkedList BUILD
file, which only produces a binary:
load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_library")
cc_binary(
name = "dummymain",
srcs = [ "main.cpp" ],
deps = [ ":linkedlist" ]
)
cc_library(
name = "linkedlist",
hdrs = [ "node.h", "linked_list.h" ]
)
And here are the contents of the bazel-bin
directory of the LinkedList project:
_objs
dummymain
dummymain-2.params
dummymain.cppmap
dummymain.runfiles
dummymain.runfiles_manifest
linkedlist.cppmap
Just in case, I made sure to include my libraries in the main.cpp
file and initialize an instance of each class. I get the typical "unused variable" warning, but aside from that it builds and runs as expected.
My question is why does my Enigma project produce *.a files but my LinkedList project does not?
How can I configure my build such that it produces *.a (or *.so) library files with or without a cc_binary
rule that depends on them?
What I've tried:
At first, my LinkedList project BUILD
file only contained a cc_library
rule. I believe that Bazel was not building that target (despite me running bazel build //src:linkedlist
) because no other rules depended on it and it was a library target (although I feel like I am wrong about that assumption). To remedy that, I created a main.cpp
file with a cc_binary
rule to accompany it. This seems to trigger a build of the linkedlist
target, but I still do not see any library files in my bazel-bin
. I would have expected it to produce a statically linked binary as well as the static library (*.a) files but all I get is the binary file.
答案1
得分: 0
"plugboard", "rotor", 和 "linkedlist" 目标只包含头文件。这些库中没有直接编译的文件。因此,Bazel 抑制了为这些库创建静态存档文件。
英文:
The "plugboard"
, "rotor"
, and "linkedlist"
targets contain only header files. There are no files directly compiled in those libraries. Therefore, Bazel suppresses the creation of static archives for those libraries.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论