Choosing Bazal over a CMake+Gradle combo

[Esben Nielsen]

I am an architect for a old, mono repo code base consisting of Java, C++ and Python. We are looking for a new build system to replace our own homegrown Make/Ant system. For me Bazel is obvious, but the rest of the team knows CMake very well. I am also starting to convince at least one of my coworkers, that it is a fundamentally good build system with easy syntax,  can build both Java and C++, and he also found now, being experimenting, that it is really nice with a build cache.

But he still have some show-stoppers:

1) Lack of IDE integration. CMake and Gradle have a highlevel support in most IDEs.  We are especially looking VsCode, which we have changed to recently as our standeard IDE.

I found bazel - C++ commands database which seems to be a doable way to get a somewhat acceptable support in VsCode, but nothing for import Java classpath.

The best would of course be a plugin in VsCode just handling it...

2) Long startup times. Even though we have only tried to port a small part of our codebase to Bazel, it takes in the order of 1-2 minutes to start the Bazel server. We have 15000 rules already - but mainly by building Boost in a genrule() generating a lot of .hpp files. I also tried the make_foreign_cc package, still it takes a lot of time scanning all those, now foreign, .hpp files from Boost.

But it doesn't sound promissing, that it doesn't scale that well already from the beginning. Are we supposed to make more WORKSPACE files to make it scale or can Bazel scale a lot of code within one big WORKSPACE file?

3) Nobody knows Bazel. Everyone in Java world knows Gradle, everybody in C++ world knows CMake. So there re nobody to ask :-( (and is why,  there is so little 3rd party integration).

Do anyone have any comments on these findings?

/Esben

[re:fi.64]

For #1, there *is* an IntelliJ plugin, though it tends to lag behind official release support a bit. There's also some stopgap hacks here: https://github.com/redhat-developer/vscode-java/issues/909

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/ac2edb0e-2275-42c3-8082-502031fbcf57n%40googlegroups.com.

[James Sharpe]

For #2 I think as you get larger there are JVM flags you can pass to give it more memory to help. Note that initial startup time will be longer than subsequent runs as the server stays persistent.  For building boost you might want to take a look at https://github.com/nelhage/rules_boost. I'd try to avoid using rules_foreign_cc as much as you can as bazel runs a lot more efficiently (at least from a build caching perspective) if it knows the full build graph.

#3 - There's always this mailing list ;) The bazel slack is also a good place to ask, or stack-overflow with the bazel tag. There are also a number of consultancies out there that will help with your migration to bazel if you are having difficulty. Also searching on github with advanced search for the starlark language is a useful way of finding example code / existing build files for different projects.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAO41-mPjAem8mrHXaHekLjhE%2B6Za%3DrpXhGcRDZ%2BF8r4E3qBTeA%40mail.gmail.com.

[Joe Hicks]

Hi there!

I am glad that you are choosing Bazel for your build and acknowledge that there are some gaps.

#1 I am interested in seeing better VSCode integration with Bazel and would love to see the interest from the community. Perhaps IDE choice for integration is a good question for a future survey.

#3 The Bazel Experts page lists a number of 3rd party experts who can help you with Bazel: https://bazel.build/experts.html

Thanks,

Joe 

[Lars Clausen]

Hej Esben[1],

Regarding #2, by "startup" do you mean just starting the server, or doing a full compile? Bazel caches heavily as long as you don't run `bazel clean`, so after one full compile it should be much faster. Bazel does scale, as our use here at Google proves, and generally staying within one WORKSPACE is better. Using many smaller rules is generally a good idea, as that allows Bazel to reason about what needs to be recompiled. The selling point to your coworkers ought to be that you can have a single build system for all your languages instead of multiple.

I'm suspicious of those Boost-generated files, at least the way you describe them. Does the genrule tell Bazel exactly which files are generated, or does it have to scan a directory for outputs after each genrule? 

For Java compilation, make sure to use [persistent workers](https://docs.bazel.build/versions/master/persistent-workers.html), preferably with [multiplex}(https://docs.bazel.build/versions/master/multiplex-worker.html)

-Lars

[1] Er du den Esben jeg kan huske fra DAIMI i 90'erne, eller en doppeltgænger?

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/d26f4abf-f128-435f-9acd-b13b594d0ebcn%40googlegroups.com.