【问题标题】:Correct way to provide access to third_party libraries in bazelCorrect way to provide access to third_party libraries in bazel
【发布时间】:2022-11-20 10:14:16
【问题描述】:

Take glm as an example. I currently have

new_local_repository(
    name = "glm",
    build_file = "third_party/glm/BUILD",
    path = "third_party/glm/local",
)

in my WORKSPACE file. Here is third_party/glm/BUILD

cc_library(
    name = "glm",
    srcs = ["local/glm/detail/glm.cpp"] + glob([
        "local/glm/**/*.hpp",
        "local/glm/**/*.h",
        "local/glm/**/*.inl",
    ]),
    includes = ["local"],
    visibility = ["//visibility:public"],
)

My goal is to make the details of providing of glm transparent. With the current setup I can

#include "glm/glm.hpp"

from some other file, keeping the include site oblivious to whatever I'm doing with bazel.

Is this a good idea? With this setup if -isystem /usr/include is part of the compile commands, which would be the case unless I'm building with a fully standalone toolchain, "glm/glm.hpp" will silently be found in that directory if something goes wrong with my bazel config. I would personally prefer #include "third_party/glm/glm.hpp", but that would require me to use this name as the top level directory of glm, so that I can then pass

    includes = ["."],

in glm's cc_library. Is there a middle ground here which would let me decide on my directory structure independently and allow me to map it such that the contents of the directory can be resolved through third_party/glm/glm.hpp?

【问题讨论】:

    标签: c++ include bazel bazel-rules bazel-cpp


    【解决方案1】:

    With this setup if -isystem /usr/include is part of the compile commands, which would be the case unless I'm building with a fully standalone toolchain, "glm/glm.hpp" will silently be found in that directory if something goes wrong with my bazel config.

    This is not actually true, Bazel will complain that you have included files that aren't tracked by Bazel. A simple way to confirm this is to remove your dependency declaration for "@glm//:glm". You'll find that it'll produce an error even if you have those headers installed on your system.

    However if you really want to be totally safe you can use the include_prefix with the strip_include_prefix attribute to add the "third_party" to the start of the include path. e.g.

    cc_library(
        name = "glm",
        srcs = ["local/glm/detail/glm.cpp"] + glob([
            "local/glm/**/*.hpp",
            "local/glm/**/*.h",
            "local/glm/**/*.inl",
        ]),
        strip_include_prefix = "local",
        include_prefix = "third_party",
        visibility = ["//visibility:public"],
    )
    

    From the docs for 'include_prefix'

    include_prefix
    String; optional

    The prefix to add to the paths of the headers of this rule. When set, the headers in the hdrs attribute of this rule are accessible at is the value of this attribute prepended to their repository-relative path.

    The prefix in the strip_include_prefix attribute is removed before this prefix is added.

    【讨论】:

      猜你喜欢
      • 2022-12-19
      • 2022-12-02
      • 2022-11-09
      • 2022-12-02
      • 2022-12-02
      • 2022-12-02
      • 2022-12-02
      • 2022-12-27
      • 2019-10-05
      相关资源
      最近更新 更多