Bazel WORKSPACE文件编写

WORKSPACE文件主要就是命名workspace以及声明外部的依赖，这就包括外部依赖的获取方式及获取方法。

外部依赖

https://docs.bazel.build/versions/master/external.html
WORKSPACE文件告诉Bazel如何去得到其他的工程源，然后package中的BUILD文件就可以根据WORKSPACE中的外部target名字写依赖关系。

先举个例子来看下在本地的两个工程如何实现依赖关系：
/
  home/
    user/
      project1/
        WORKSPACE
        BUILD
        srcs/
          ...
      project2/
        WORKSPACE
        BUILD
        my-libs/
project1希望能依赖project2/BUILD下的target :foo，需要指明project2可以在/home/user/project2中被找到，而且接下来project1的BUILD就可以写依赖关系：@project2//:foo
WORKSPACE文件允许用户的目标依赖其他文件系统的目标或者从网上下载的目标。
WORKSPACE文件的语法和BUILD文件一致，不过会用到一些特定的内置rule，细节参考下一个章节的内容。

一共有三种外部依赖的主要类型：


  • 依赖于其他Bazel工程
根据这个Bazel工程所处的位置不同，调用不同的内置rule来获得：
git_repository：git仓库
http_archive：网络下载

假如现在有个工程my-project/，需要依赖与另一个工程coworkers-project/。这两个都是Bazel工程，那么需要在my_project/WORKSPACE下添加：
local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
)
然后对于coworker的target //foo:bar就可以在自己的工程中通过@coworkers_project//foo:bar来依赖引用。
  • 依赖于其他非Bazel工程
还有一种情况是另外一个工程不是Bazel工程，那么就需要另外一种方法来添加依赖引用
new_git_repository：git仓库
new_http_archive：网络下载
还是上面那两个工程，不同的是工程coworkers-project/不再是Bazel工程，此时需要在工程上做两个改动：
1、在my_project/WORKSPACE上添加
new_local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
    build_file = "coworker.BUILD",
)
其中build_file属性是规定了一个BUILD文件让bazel来build处理依赖工程
2、添加coworker.BUILD
cc_library(
    name = "some-lib",
    srcs = glob(["**"]),
    visibility = ["//visibility:public"],
)
这样就可以通过@coworkers_project//:some-lib来添加依赖。
  • 依赖于外部包

Maven仓库：Use the rule maven_jar (and optionally the rule maven_server) to download a jar from a Maven repository and make it available as a Java dependency.

获取外部依赖

除了通过bazel build可以自动获取外部依赖之外，还可以通过bazel fetch来获得。

传递依赖

Bazel只会读取自己workspace下面的WORKSPACE依赖，假如我们的工程是A，依赖于一个工程B，在B的工程WORKSPACE中写了依赖C，那么我们需要把B和C都加入到WORKSPACE中。这样会使得WORKSPACE很大，但是至少也避免了对于C的依赖版本不同。
另外可以使用git上一个工程，来根据已有的Maven pom.xml自动产生WORKSPACE文件： Generate external dependencies from Maven projects.

缓存外部依赖

Bazel会缓存外部依赖，并且只有在WORKSPACE文件更改后才再次下载和更新。

存放位置

所有的外部依赖会都下载到一个名为的软连接目录。具体的内容可以通过命令行获得：
ls $(bazel info output_base)/external
另外使用bazel clean不会删除外部依赖，如果想要删除需要使用bazel clean --expunge


Workspace Rules

https://docs.bazel.build/versions/master/be/workspace.html

  • bind
给target命别名，不推荐使用
  • git_repository
git_repository(name, commit, init_submodules, remote, sha256, tag)
这个有很多限制不推荐使用，用http_archive 来代替使得更加鲁棒以及安全性能。
  • http_archive
http_archive(name, sha256, strip_prefix, type, url, urls)
下载一个压缩格式的Bazel仓库，并解压出来，然后绑定使用。
比如：

http_archive(
    name = "my_ssl",
    url = "http://example.com/openssl.zip",
    sha256 = "03a58ac630e59778f328af4bcc4acb4f80208ed4",
)

然后可以通过@my_ssl//package:target来依赖索引
这个Rule有一个属性strip_prefix，用来消除前缀目录。
  • maven_jar
maven_jar(name, artifact, repository, server, sha1)

从Maven下载jar并且可以被使用
举例：
Suppose that the current repostory contains a java_library target that needs to depend on Guava. Using Maven, this dependency would be defined in the pom.xml file as:
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>18.0</version>
</dependency>
With Bazel, add the following lines to the WORKSPACE file:
maven_jar(
    name = "com_google_guava_guava",
    artifact = "com.google.guava:guava:18.0",
    sha1 = "cce0823396aa693798f8882e64213b1772032b09",
)
Targets can specify @com_google_guava_guava//jar as a dependency to depend on this jar.
属性介绍：
name：rule的唯一名字
artifact： <groupId>:<artifactId>:<version>
repository：下载jar的Maven仓库url，默认是central.maven.org
server：使用的maven_server，这个属性和repository配置一个就好

  • maven_server

maven_server(name, settings_file, url)
定义怎么链接到Maven仓库。
举例使用：
maven_jar(
    name = "junit",
    artifact = "junit:junit-dep:4.10",
    server = "my_server",
)

maven_server(
    name = "my_server",
    url = "http://intranet.mycorp.net",
)
另外需要注意的是，如果把maven_server的name值设置为"default"，那么在maven_jar中即使不指定server也会默认使用这个default的仓库。




评论

发表评论

此博客中的热门博文

Bazel的概念和技术

这个文章应该是要长期不定时更新的，因为涉及到的很多概念的理解，技术的理解，这些内容仅通过初次接触Bazel是远远不到位的，甚至不能保证下面缩写内容的正确性。 从整体上来看Bazel的实际对项目的控制和管理是长这个模样的： 1、Bazel对于源码的组织在一个文件夹之下称之为 workspace （这个文件夹下面包含一个WORKSPACE文件） 2、源码文件被一系列的分层结构的 package 所组织 3、每一个package就是一个包含一系列相关的源码文件以及一个BUILD文件 4、BUILD文件指示了如何从源码中输出build结果 开始一些干货： Workspace 其实workspace就是一个文件夹。这个文件夹下面包含一个 WORKSPACE文件，以及一系列的源码文件，这些源码被package组织起来，也就是在各个package中存在的BUILD文件。 而且随着在workspace中进行bazel build这样的操作（可以不在workspace root目录下build），会在workspace的root目录下面产生诸如：bazel-bin  bazel-genfiles  bazel-java-tutorial  bazel-out  bazel-testlogs这样的输出文件夹（软连接） 当然简单的项目中WORKSPACE文件可以是空文件，但是对于正常的工程来说，这里面要写一些整个工程的 外部依赖 及其书写rules： Workspace Rules ，这两块内容会在下一篇博文中介绍。 Package 在workspace中，代码是被一个个的package所管理，每个带BUILD文件的文件夹就是一个package，这里面包括了自己的源码文件以及规定了内外依赖关系。 package将自己所在的目录下面所有包括子文件夹下面的文件都视为属于自己package的。除非子文件夹下面有存在BUILD文件，那么这个子文件夹就是一个新的package。 Target package是一个容器，那么这个容器里面所包含的元素就是target。大部分的target都属于这两个最主要的类型：files和rules。还有一种target叫package groups。 对于file类型的target，主要
阅读全文

Bazel BUILD文件的编写

除了公共部分BUILD文件可以使用的规则外，还有一些与语言相关的build rule https://docs.bazel.build/versions/master/be/overview.html 这里根据不同的语言，来写整理。 Java Bin rules java_binary java_binary( name ,  deps ,  srcs ,  data ,  resources ,  args ,  classpath_resources ,  compatible_with ,  create_executable ,  deploy_manifest_lines ,  deprecation ,  distribs ,  features ,  javacopts ,  jvm_flags ,  launcher ,  licenses ,  main_class ,  output_licenses ,  plugins ,  resource_jars ,  resource_strip_prefix ,  restricted_to ,  runtime_deps ,  stamp ,  tags ,  testonly ,  toolchains ,  use_testrunner ,  visibility ) build一个java的jar文件，并且套上一个shell的脚本来辅助运行。 隐式的输出target： name.jar name-src.jar name_deploy.jar：这个比较特殊，必须显式的build才会生成，比如 bazel build //package:target_deploy.jar name_deploy-src.jar Lib rules java_import java_import( name ,  deps ,  data ,  compatible_with ,  constraints ,  deprecation ,  distribs ,  exports ,  features ,  jars ,  licenses ,  neverlink ,  proguard_specs ,  restricted_to
阅读全文