undefined | Better HN

0 pointsjeffbee1y ago0 comments

This is likely because you are running it in some random PWD that doesn't represent a bazel workspace. When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.

Running bazel outside of a bazel workspace is not a major use-case that needs to be fixed.

0 comments

thayne1y ago

> When running in a workspace the bazel daemon persists. Inside my workspace the bazelisk --help invocation needs just 30ms real time.

It still has a slow startup time, bazel just works around that by using a persistent daemon, so that it is relatively fast after as long as the daemon is running.

sunshowers1y ago

That's good to know, thank you!

Do you encounter cache invalidation bugs with daemonization often? I've had pretty bad experiences with daemonized dev tools in the past.

jrockway1y ago

Bazel prints a message when you invalidate the in-memory cache in a perhaps accidental way; you can supply it with a flag to make this an error and skip the cache invalidation.

If you try to run two Bazel invocations in parallel in the same workspace, one waits for the other to be done.

jeffbeeOP1y ago

I assumed they meant an error of improperly using cached results. I am sure bazel has its flaws but it assiduously avoids that.

2 more replies

j / k navigate · click thread line to collapse