1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
---
layout: contribute
title: Generating C++ crosstool with a Skylark Remote Repository
---
# Generating C++ crosstool with a Skylark Remote Repository
__Status:__ implemented
__Author:__ dmarting@google.com
__Reviewers:__ lberki@google.com
## Context
[Skylark](/docs/skylark/index.html) is the
extension language for Bazel and lets Bazel users describe the
build for new languages easily. External users do not create
native rules and we want to avoid them doing so.
[Remote repositories](/docs/external.html)
are a convenient way to specify your third party dependencies
and to fetch them along with the build if you don’t want to
check them in your repository.
[Skylark remote
repositories](/designs/2015/07/02/skylark-remote-repositories.html) is
an ongoing effort to support specifying new remote repositories using
Skylark.
## Why?
Configurability issues are stopping users from compiling and using
Bazel on complex setup. In particular,
[TensorFlow](https://tensorflow.io)’s users runs on
various hardware where gcc is installed on non-standard directory that
needs to change the
[CROSSTOOL](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/tools/cpp/CROSSTOOL)
file (see
[issue #531](https://github.com/bazelbuild/bazel/issues/531)).
This generally requires to change the list of include directories, the
path to gcc and sometimes also the linking option to find the correct
libraries at runtime. Some platform even requires
[special wrappers around gcc](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/tools/cpp/osx_gcc_wrapper.sh).
Java solved the problem by setting a custom repository
([@local_jdk](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/src/main/java/com/google/devtools/build/lib/bazel/rules/java/jdk.WORKSPACE#L3))
where the path is automatically detected using the [location of the JVM
running
Bazel](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/src/main/java/com/google/devtools/build/lib/packages/WorkspaceFactory.java#L414).
But this approach does not scale well with complex language setup like
C++.
We reduced the number of C++ issues the user had with removing all C++
compilation in the bootstrap of Bazel. However, to properly handle
those platform, Bazel needs some level of auto-configuration
([Kythe](https://github.com/google/kythe/blob/a29f0adc6fa11550f66bc2278f17b89b9e02de18/setup_bazel.sh)
and
[Tensorflow](https://github.com/tensorflow/tensorflow/blob/a81c4f9cd01563e97fc6f179e4d70960fc9b02ae/configure)
have their own auto-configuration scripts). This document discuss how
to use a skylark remote repository to implement a simple
auto-configuration for C++ crosstool (step 4 of the roadmap from the
[Skylark remote
repositories](/design/2015/07/02/skylark-remote-repositories.html)
document).
## C++ toolchain detection
Until now here the various issues user have faced using a custom C++
toolchain:
1. C++ compiler is not at the expected location.
2. C++ compiler is `clang` and not `gcc` or behaves differently than
what Bazel C++ rules expect.
3. Libraries are not in the default location.
4. Headers are not in the default location.
5. Path of libraries or headers are outside of the default mounted
paths.
The current fix we propose to the user for the various issue are:
1. Change the tool paths in
[tools/cpp/CROSSTOOL#L87](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/tools/cpp/CROSSTOOL#L87).
2. Add a wrapper like
[tools/cpp/osx\_gcc\_wrapper.sh](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/tools/cpp/osx_gcc_wrapper.sh)
and modify some options from the CROSSTOOL file.
3. Add `-Wl,rpath,` option to the
[linker\_flags](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/tools/cpp/CROSSTOOL#L93).
4. Add the directories to the
[cxx\_builtin\_include\_dirs](https://github.com/bazelbuild/bazel/blob/6b6ff76945c80fb8b11b71d402b5146c85b86859/tools/cpp/CROSSTOOL#L100).
5. Deactivate sandboxing
To address those issues, we propose to add the followings methods to
the repository context object:
1. `which(cmd)` returns the path to the binary designed by `cmd`,
looking for it in the path environment variable (or equivalent).
This will help getting the path to the C++ compiler.
2. `execute([arg0, arg1, ..., argn])` executes a command and returns an
`exec_result` struct containing:
* `stdout` the content of the standard output,
* `stderr` the content of the standard error output, and
* `return_code` the return code of the execution.
Executing `$(CC)` will help detect whether we are using gcc or
clang.
3. An `os` object with an environ map containing the list of
environment variable. The os object will be extended to
contains all OS specific variables (platform name and much more).
4. `execute([..])` from 2 will be used to run [`gcc ...
-v`](http://stackoverflow.com/questions/11946294/dump-include-paths-from-g)
to list the built-in include directories.
To address the issue 5, we can add the list of paths to dependencies to the
[crosstool rule in the BUILD
file](https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain).
## Writing the cpp package
Once we have resolved all the information from the system, we need to
write two or three files:
- The `BUILD` file that will contains the corresponding
`cc_toolchain` rules
- The `CROSSTOOL` file
- Optionally, the wrapper script.
We should extends the context with a `file(path, content)` method, where
path is a path relative to the repository root and content the content
of the file to write.
To ease the writing of crosstool, we should also provide a
`template(path, label, variables)` method which will write the file
pointed by path using the file pointed by label (should be a
FileValue) in which variables have been replaced in the same way that
[template_action](http://bazel.io/docs/skylark/lib/ctx.html#template_action)
works.
## Rollout plan
The implementation plan would be:
1. Implements `which`, `execute`, `os`, `file` and `template`
[__DONE__]
2. Write the `cc_configure` repository rule which does the work. Use
GitHub bugs as inputs on which platform to support. [__DONE__]
3. Advertise the existence of `cc_configure` [__DONE__]
|
