Configurability roadmap: discussion

[gregestren]

This is a non-technical issue just meant as a connection point for discussion, thoughts, questions, concerns, etc. about Bazel's configurability & multiplatform work as prioritized in https://www.bazel.build/roadmaps/configuration.html.

It's also a step toward integrating our project workflow deeper into the Bazel community.

My current thinking is to maintain one of these issues and roadmaps for each year. But I'm open to suggestions for other venues like bazel-dev, etc.

I also want to have a dedicated GitHub issue for each individual roadmap item. As of this writing we're
about halfway there. So individual priorities can be discussed on their own threads and this thread can cover big picture stuff.

[gregestren]

FYI, I've been prototyping a different output path scheme for #6526 (this also affects platform-independent Java compilation in #6527).

The idea is to use a scheme that's more correct and scalable than what we have today. i.e. you can do bazel build //foo:all where different rules in //foo auto-configure themselves for different platforms, different custom flags (no need for --whatever_flag at the command line), and so on, and the following two properties hold:

1. it doesn't crash
2. it's usably fast

Neither property is really met by today's path scheme, which is why we limit auto-configuring rules.

At my current pace I'm planning to have some feedback on the viability of my prototype by EOY. I have it working with simple genrules and almost (?) have it working with simple C++ rules. I'd like to scale this up to a "realistic" project. But that quickly gets complicated since most realistic projects have a whole bunch of extra dependencies, cross-language build actions and weird corner cases that defy simple experiments.

Starting 2019 we can focus on getting some path scheme into production (whether this or something more simplistic). So my EOY goal is to have some more data to help guide that decision. And maybe write a big email about it.

This comment should arguably be on #6526. But I wanted to write it here because it enables all the other initiatives on the roadmap and deserves some visibility for that.

[johnynek]

One question I have about this configurability is how it might relate to building with different versions of a compiler that may be slightly incompatible.

e.g. compiler v10 accepts mostly more than v9, but occasionally features are removed so v9 supports some code v10 does not.

In this world, using v10 may mean a different set of external dependencies selected and it may mean that some targets would need select-like systems to select different code for the v9 than v10.

Would this be in scope for this work?

It is highly relevant to scala (2.11, 2.12, 2.13 each have incompatibilities that mean some sources need this treatment to compile on different versions).

Secondly, scala supports multiple backends. The two most popular being jvm and js. Currently the rules_scala do not support js at all, but it would be interesting to think of the best way to support them. Maybe jvm and js are architectures? I don't know.

[katre]

It sounds like jvm and js are different target platforms (building for a browser vs building for a jvm).

The different compiler versions is a little more tricky. Do users want to use both in the same build, or just pick one and stick with it? Can you give examples of the types of things users would need to change when changing from scala 2.12 to 2.13?

[johnynek]

especially for open source libraries, you want to support many versions because your users might be using 2.11, 2.12, or 2.13. So, a library wants to be able to build with different versions with a minimum of fuss.

Second use case is migration: you are migrating your monorepo from 2.12 to 2.13. You want to easily have your CI build both versions so you can try to get both green and then through the switch.

[katre]

Sorry, I wasn't clear about what I was asking. I agree that there is definitely a usecase for this.

What I am curious about: what types of changes would a user be making to their scala_library targets when migrating from one version to the next?