local_defines | Список строк; по умолчанию [] Список определений для добавления в командную строку компиляции. Подлежит замене "Make" переменной и токенизации оболочки Bourne. Каждая строка, которая должна состоять из одного токена оболочки Bourne, предваряется -D и добавляется в командную строку компиляции для данного целевого объекта, но не для его зависимостей. |
malloc | Метка; по умолчанию "@bazel_tools//tools/cpp:malloc" Переопределите зависимость по умолчанию от malloc. По умолчанию двоичные файлы C++ связываются с //tools/cpp:malloc, что является пустой библиотекой, поэтому двоичный файл в конечном итоге использует libc malloc. Эта метка должна ссылаться на cc_library. Если компиляция выполняется для правила, не являющегося C++, этот параметр не имеет эффекта. Значение этого атрибута игнорируется, если linkshared=True указан. |
nocopts | Строка; по умолчанию "" Удаляет соответствующие параметры из командной строки компиляции C++. Подлежит замене "Make" переменной. Значение этого атрибута интерпретируется как регулярное выражение. Любые существующие COPTS , соответствующие этому регулярному выражению (включая явно указанные значения в атрибуте правила copts), будут удалены из COPTS для целей компиляции данного правила. Этот атрибут редко нужен. |
stamp | Целое число; по умолчанию -1 Нужно ли кодировать информацию о сборке в двоичный файл. Возможные значения: -
stamp = 1: Всегда ставить метку информации о сборке в двоичный файл, даже в сборках --nostamp. Этот параметр следует избегать, так как он потенциально уничтожает кэширование удаленных двоичных файлов и любых последующих действий, которые зависят от него. -
stamp = 0: Всегда заменять информацию о сборке постоянными значениями. Это обеспечивает хороший кэш результатов сборки. -
stamp = -1: Вставка информации о сборке контролируется флагом --[no]stamp. Отмеченные двоичные файлы не перестраиваются, пока не изменятся их зависимости. |
win_def_file | Метка; по умолчанию None Файл DEF Windows, передаваемый компоновщику. Этот атрибут следует использовать только при платформе Windows в качестве целевой. Он может использоваться для экспорта символов во время компоновки разделяемой библиотеки. |
cc_import
cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)
Правила cc_import позволяют пользователям импортировать предварительно скомпилированные библиотеки C/C++.
Типичные случаи использования:
1. Создание статической библиотеки
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
static_library = "libmylib.a",
# If alwayslink is turned on,
# libmylib.a will be forcely linked into any binary that depends on it.
# alwayslink = 1,
)
2. Создание разделяемой библиотеки (Unix)
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
shared_library = "libmylib.so",
)
3. Создание разделяемой библиотеки с библиотекой интерфейса (Windows)
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
# mylib.lib is an import library for mylib.dll which will be passed to linker
interface_library = "mylib.lib",
# mylib.dll will be available for runtime
shared_library = "mylib.dll",
)
4. Создание разделяемой библиотеки с
system_provided=True (Windows)
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
# mylib.lib is an import library for mylib.dll which will be passed to linker
interface_library = "mylib.lib",
# mylib.dll is provided by system environment, for example it can be found in PATH.
# This indicates that Bazel is not responsible for making mylib.dll available.
system_provided = 1,
)
5. Создание статической или разделяемой библиотеки
В Unix:
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
static_library = "libmylib.a",
shared_library = "libmylib.so",
)
# first will link to libmylib.a
cc_binary(
name = "first",
srcs = ["first.cc"],
deps = [":mylib"],
linkstatic = 1, # default value
)
# second will link to libmylib.so
cc_binary(
name = "second",
srcs = ["second.cc"],
deps = [":mylib"],
linkstatic = 0,
)
В Windows:
cc_import(
name = "mylib",
hdrs = ["mylib.h"],
static_library = "libmylib.lib", # A normal static library
interface_library = "mylib.lib", # An import library for mylib.dll
shared_library = "mylib.dll",
)
# first will link to libmylib.lib
cc_binary(
name = "first",
srcs = ["first.cc"],
deps = [":mylib"],
linkstatic = 1, # default value
)
# second will link to mylib.dll through mylib.lib
cc_binary(
name = "second",
srcs = ["second.cc"],
deps = [":mylib"],
linkstatic = 0,
)
cc_import поддерживает атрибут include. Например:
cc_import(
name = "curl_lib",
hdrs = glob(["vendor/curl/include/curl/*.h"]),
includes = [ "vendor/curl/include" ],
shared_library = "vendor/curl/lib/.libs/libcurl.dylib",
)
Аргументы
| Атрибуты |
name | Имя; необходимо Уникальное имя для данного целевого объекта. |
deps | Список меток; по умолчанию [] Список других библиотек, от которых зависит целевой объект. См. общие комментарии о deps в Типичные атрибуты, определенные большинством правил сборки. |
hdrs | Список меток; по умолчанию [] Список файлов заголовков, опубликованных этой предварительно скомпилированной библиотекой, которые напрямую включаются источниками в зависимых правилах. |
alwayslink | Булево; по умолчанию False Если 1, любой двоичный файл, который зависит (прямо или косвенно) от этой предварительно скомпилированной библиотеки C++, будет подключать все объектные файлы, архивированные в статической библиотеке, даже если некоторые из них не содержат символы, к которым ссылается двоичный файл. Это полезно, если ваш код не явно вызывается кодом в двоичном файле, например, если ваш код регистрируется для получения обратного вызова, предоставляемого какой-либо службой. Если alwayslink не работает с VS 2017 в Windows, это связано с известной проблемой, пожалуйста, обновите свой VS 2017 до последней версии. |
interface_library | Метка; по умолчанию None Единственная библиотека интерфейса для связывания разделяемой библиотеки. Разрешенные типы файлов: .ifso, .tbd, .lib, .so или .dylib |
shared_library | Метка; по умолчанию None Одна предварительно скомпилированная разделяемая библиотека. Bazel гарантирует ее доступность двоичному файлу, который зависит от нее, во время выполнения. Разрешенные типы файлов: .so, .dll или .dylib |
static_library | Метка; по умолчанию None Одна предварительно скомпилированная статическая библиотека. Разрешенные типы файлов: .a, .pic.a или .lib |
system_provided | Булево; по умолчанию False Если 1, указывает, что разделяемая библиотека, необходимая во время выполнения, предоставляется системой. В этом случае следует указать interface_library, а shared_library должно быть пустым. |
cc_library
cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)
Проверка включения заголовков
Все файлы заголовков, используемые в сборке, должны быть объявлены в hdrs или srcs правил cc_*. Это принудительно.
Для правил cc_library, заголовки в hdrs составляют общедоступный интерфейс библиотеки и могут быть напрямую включены как из файлов в hdrs и srcs самой библиотеки, так и из файлов в hdrs и srcs правил cc_*, которые перечисляют библиотеку в их deps. Заголовки в srcs должны включаться только непосредственно из файлов в hdrs и srcs самой библиотеки. При решении, в какую папку (hdrs или srcs) поместить заголовок, необходимо спросить, хотите ли вы, чтобы пользователи этой библиотеки могли напрямую включать его. Это примерно такое же решение, как и между видимостью public и private в языках программирования.
Правила cc_binary и cc_test не имеют экспортированного интерфейса, поэтому у них также нет атрибута hdrs. Все заголовки, относящиеся непосредственно к двоичному файлу или тесту, должны быть перечислены в srcs.
Чтобы проиллюстрировать эти правила, рассмотрите следующий пример.
cc_binary(
name = "foo",
srcs = [
"foo.cc",
"foo.h",
],
deps = [":bar"],
)
cc_library(
name = "bar",
srcs = [
"bar.cc",
"bar-impl.h",
],
hdrs = ["bar.h"],
deps = [":baz"],
)
cc_library(
name = "baz",
srcs = [
"baz.cc",
"baz-impl.h",
],
hdrs = ["baz.h"],
)
Разрешенные прямые включения в этом примере приведены в таблице ниже. Например, foo.cc разрешено напрямую включать foo.h и bar.h, но не baz.h.
| Включающий файл |
Разрешенные включения |
| foo.h |
bar.h |
| foo.cc |
foo.h bar.h |
| bar.h |
bar-impl.h baz.h |
| bar-impl.h |
bar.h baz.h |
| bar.cc |
bar.h bar-impl.h baz.h |
| baz.h |
baz-impl.h |
| baz-impl.h |
baz.h |
| baz.cc |
baz.h baz-impl.h |
Правила проверки включения применяются только к прямым включениям. В приведенном выше примере foo.cc разрешено включать bar.h, которое может включать baz.h, которое, в свою очередь, разрешено включать baz-impl.h. Технически, компиляция файла .cc может транзитивно включать любой файл заголовка в hdrs или srcs в любом cc_library в транзитивном deps замыкании. В этом случае компилятор может прочитать baz.h и baz-impl.h при компиляции foo.cc, но foo.cc не должен содержать #include "baz.h". Чтобы это было разрешено, baz должно быть добавлено в deps foo.
Bazel полагается на поддержку инструментария для соблюдения правил проверки включения. Функция layering_check должна поддерживаться инструментарием и запрашиваться явно, например, через флаг командной строки --features=layering_check или параметр features функции package. Предоставляемые Bazel инструментарии поддерживают эту функцию только с clang на Unix и macOS.
Аргументы
