Unable to run bazel scala without having a long protobuffer compilation

[a4z]

trafficstars

#1254 makes it sound as there is no problem, or it is solved.

But a simple scala hello world compiles protobuf and that happens not only once, I am on a new project, and it happens every now and then when I change something workspaec / build files. Or, when changing from one notebook to an other, what happens also oftne.

And on CI, the same project that builds with sbt in 2 minutes requires via bazel 8 minutes!

So I wonder what I can do to eliminate the protobuf compilation, I often change from on note

If there is a solution in to this problem it would be nice finding it in the README. I tried now what I could find in various issues, but nothing works for me.

[gergelyfabian]

Do you have e.g. remote cache or disk cache enabled? Normally protobuf should be compiled only once. The reason why you may not have access to that is that some of the inputs changed (e.g. something from the WORKSPACE file) or you do not have access to the cache (changed branches, or you are building on a different computer, or in a new CI build that runs in docker, not having access to any - remote - cache).

[gergelyfabian]

As a first step , try building twice on the same machine, ensure you have disk cache enabled, change some file in your scala module, rebuild, and then protobuf should not be recompiled.

[a4z]

Yes, especially at the begin of a project WORSPACE can change relatively often, when kind of new to bazel in general and very new to bazel scala in special, and need to try out various things. For such a user (like me) protobuf compiles again, and again, .... It's super frustrating, this user experience is a horror. Why does this dependency even exist? At the begin I thought I did something wrong.

And as mentioned, in a CI, there might be no cache, not everyone has a remote cache configured or the possibility to have one. Why protobuf for compiling a scala hello world, that seems to be kind of broken. What is it good for, it must be there for accident or some kind of hack?

[a4z]

an other frustrating use case:

I have a small project that works fine on Linux, on OSX my test fails because of such a problem Exception in thread "main" java.io.FileNotFoundException: some/file.txt (Operation not permitted) some/file.txt is in the sandbox and ls shows it, the path is ok and it is readable.

so I test if it helps setting a different --output_base , ... guess what happens and what I see again ..... and make me getting my feedback i minutes instead of seconds

[simuons]

Hi @a4z,

could you share your workspace setup? Issue you mentioned uses prebuilt protoc which comes from rules_proto (downloads binary instead of compiling it). Ordering is important. Maybe something else declares @com_google_protobuf//:protoc which points to sources. Try moving rules_proto_dependencies() from rules_proto up in your workspace.

[a4z]

Here my fork/branch of the project I try to add bazel support https://github.com/a4z/djinni-generator/tree/bazel

you can also see the build times problem on first use https://github.com/a4z/djinni-generator/actions/runs/1378317215 I added bazel_osx, the bazel linux build is older and has a cache if the cache is there, it's fast, if not .... a first impression for new users is not as good as it could be

I will have to make some changes in the future on the WORKSPACE file to nicely make that reusable for other projects, so it would be nice if this rebuild would not happen (even getting the single files from disk cache takes time)

and the overall question for me is, why is that needed at all. Why will I have to infect other projects with that problem that will not be scala projects , because consumers will be java/kotlin/objective-c/swift android/ios projects