[hanwenn]

I work on Bazel.

Bazel also builds other languages, such as C++ and Objective-C.

We do invoke the Java compiler through a wrapper of our own. We think we can make that work as a daemon process to benefit from a hot JVM, but haven't gotten round to that.

[moondowner]

Any plans on supporting Windows? That will definitely increase the adoption of Bazel.

[hanwenn]

http://bazel.io/docs/FAQ.html - "What about Windows?

We have experimented with a Windows port using MinGW/MSYS, but have no plans to invest in this port right now. Due to its Unix heritage, porting Bazel is significant work. For example, Bazel uses symlinks extensively, which has varying levels of support across Windows versions."

In other words: it's a lot of work, and frankly, our team doesn't know enough about windows to be very good at porting it. We would welcome contributions to make it work on Windows, of course.

[MrBuddyCasino]

That would be great. I'm not a Windows user, but having Windows support is a pre-requisite for adoption in many corporate environments, and proper symlinks are available since Windows Vista.

[moondowner]

Thanks for the feedback! Hopefully the community will contribute..

[pron]

Do you also use timestamps like sjavac or some other mechanism, like hashing?

[hanwenn]

Bazel uses checksums to determine if builds are up-to-date, but shortcuts the checksumming if metadata (timestamp, filesize) have not changed between builds.

[pron]

Your FAQ says this:

Bazel configuration files are much more structured than Gradle's, letting Bazel understand exactly what each action does. This allows for more parallelism and better reproducibility.

Could you please elaborate on that (i.e. with regards to both parallelism and reproducibility)?

[hanwenn]

I'm not a Gradle expert, so take this with a grain of salt.

Gradle a single-threaded execution in some parts (I believe it may be configuration?), because the build-rules are written in a full blown language with access to the filesystem, and internal parts of Gradle.

In Bazel, rules have to declare inputs and outputs, and this can be enforced with sandboxing. This allows to predict that two rules do not interfere with each other, so we know we can run them in parallel. Our extension language disallows direct access to the file system, and also forbids access to other sources of non-determinism, such as hash tables and the clock.

[pron]

Ah, OK. BTW, while Gradle doesn't enforce it, even tasks that directly touch the filesystem may (and should) declare their inputs (that can be files or other tasks) and outputs[1] so that their freshness can be evaluated. All default tasks (like compilation), do that out of the box.

[1]: 15.9 in https://www.gradle.org/docs/current/userguide/more_about_tas...

[cromwellian]

I wonder if this could be taken even further, like using inotify-like change detection on custom srcfs/objfs like filesystems so that you filter down the number of files you need to rehash.