Bazel: compile.sh no longer works standalone after d700dff5152f5b76a50b6839a8ccc8c8c22e1f5d

Created on 27 Nov 2016  路  6Comments  路  Source: bazelbuild/bazel

After d700dff5152f5b76a50b6839a8ccc8c8c22e1f5d
compile.sh fails with
ERROR: Must specify PROTOC if not bootstrapping from the distribution artifact

This is really annoying if you like to checkout and develop with bazel @ HEAD

All 6 comments

On Sun, Nov 27, 2016 at 10:11:31AM -0800, Paul Bethe wrote:

After d700dff5152f5b76a50b6839a8ccc8c8c22e1f5d
compile.sh fails with
ERROR: Must specify PROTOC if not bootstrapping from the distribution artifact

This is working as intended. See https://bazel.build/designs/2016/10/11/distribution-artifact.html
for details.

Short story: to build bazel, run bazel build //src:bazel. To get your
first bazel on your machine, download the dist archive (or source archive
for 0.4.0 and earlier); there you can run compile.sh

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle

@aehlig So is the status of the design doc wrong?

From the doc it is not clear to me what is general mechanism and what some special Bazel repo handling.

@aehlig So is the status of the design doc wrong?

Well, it is partly implemented; we still have architecture-dependent
files in our repository (but not much longer, I hope to finish the
transition today).

From the doc it is not clear to me what is general mechanism and
what some special Bazel repo handling.

The instructions on the webpage have already been updated. In short
you're supposed to build bazel as follows.

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle

Well the thing that is interesting to me is that we have currently (for hermeticity):

@//third_party/bazel <- prebuilt bazel for your platform
@org_bazel// <- Bazel source so we can use the worker protocol

Now the question to me is whether I could use a distribution artifact to do this in a better way.

On Mon, Nov 28, 2016 at 01:48:30AM -0800, Andreas Bergmeier wrote:

Well the thing that is interesting to me is that we have currently (for hermeticity):

@//third_party/bazel <- prebuilt bazel for your platform
@org_bazel// <- Bazel source so we can use the worker protocol

If you already have a bazel binary, you can always bazel build //src:bazel to
get a newer version of bazel. The only use of the distribution artifact is to
get bazel on a machine where you don't have a bazel binary already (e.g., if
porting to a new architecture).

--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle

I see. I was in the lazy habit of 'git pull && ./compile.sh'.

But you are trying to simplify the bootstrap -- which I get.

So 'git pull && ./compile.sh compile which bazel' works as long as you have a pre-existing bazel, and then you suggestion is the key on a new system where you don't have a bazel yet.

Was this page helpful?
0 / 5 - 0 ratings