C++ platformization and Android/iOS transitions and config_settings

[Lukács T. Berki]

Hey there,

Continuing our discussion, about platformizing C++ rules, now that I think we have a solution for Go, the next is Android and iOS.

My understanding is that there are the following problems (please check if I'm right!):

1. Android and iOS configuration transitions tweak the legacy flags (--cpu, --crosstool_top, --compiler and the like)
2. We currently don't have official platform specifications for Android (and probably for iOS)
3. We currently don't define the NDK toolchains (iOS, I have no clue)
4. We currently don't have the relevant flags, specifically, a platform-based alternative for --ios_multi_pcu and --fat_apk_cpu and the incompatible flag disabling the legacy behavior

The current official workaround is to have a platform mappings file that maps back and forth between the legacy flags and platforms, thereby making it possible for the toolchain resolution to have some platform that could be used for matching toolchains. However, one still needs to define the Android platforms and toolchains for this to work.

So in an ideal world, we'd (solution A):

1. Define the Android and iOS toolchains and platforms
2. Change the Android and iOS config transitions to transition by platforms and put that behind an incompatible flag
3. Flip the flag in Bazel 1.0

However, (1) and probably (2) would need to be done before 1.0 is cut, which is within a week. So if we want to do the ideal solution, it's pretty much a fire drlll and/or postponing 0.29 .

Alternatively, we could increase success by lowering expectations and instead of "C++ code is platformized" we could decree "non-mobile C++ code is platformized". To that end, we either (solution B):

1. Define the Android and iOS toolchains and platforms
2. Implement an official platform mapping file that could transform the --cpu/--crosstool_top/--compiler options into platform constraints 
3. Probably put the functional change in (2) behind some sort of flag because it looks scary

Or (solution C) we change the Android and iOS configuration transitions to disable the "look up C++ toolchain by platforms" flag.

Given that solution B isn't much less work than solution A (in particular, we wouldn't spare ourselves the work defining mobile toolchains and platforms) we should either go with (A) or (C).

My heart is at (A) because, well, that's what "C++ rules are nicely platformized" means. Unfortunately, I don't see how we could do that without a fire drill and pushing 1.0 back.

WDYT?

--

Lukács T. Berki | Software Engineer | lbe...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado | Registergericht und -nummer: Hamburg, HRB 86891

[Dmitry Lomov]

Mind you, 1.0 is not within a week. But everything incompatible need to be in 0.29

--

Google Germany GmbH

Erika-Mann-Straße 33, 80636 München, Germany

[Lukács T. Berki]

I know. But all the incompatible flags need to be and we either add Android/iOS ones (which means submitting them within a week) or piggyback upon the existing one (which is questionable practice)

[Dmitry Lomov]

what are the consequences of

> Or (solution C) we change the Android and iOS configuration transitions to disable the "look up C++ toolchain by platforms" flag.

[Lukács T. Berki]

Not completely migrating the C++ rules to toolchain-based lookup, which is what we wanted to do.

At least that, but Peter might know a flaw or two in this plan I'm not aware of.

[John Cater]

It should in theory work to disable toolchain resolution in the transitions, but it means keeping around a lot of code we don't otherwise need. Also host/exec transitions from the android/apple configs might end up being confused about how to find a cc toolchain (and the need to re-enable toolchain resolution).

--
You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CAOu%2B0LUWHyQLHmH6SmhU0sq5qhQwb6%2BOFbZwSJ8FHvd%3DLdv38Q%40mail.gmail.com.

[Lukács T. Berki]

Yeah, I'm not exactly enthusiastic about that option, either.

To be clear, when you say "keeping a lot of code around", do you mean the legacy C++ toolchain selection machinery?

[John Cater]

That's correct.

[Lukács T. Berki]

After some pondering, I would like to flip the "C++ toolchains are resolved by platforms" flag for all builds, including Android and C++. This, however, will probably cause delays since it entails the following:

1. Define Android and iOS platforms and toolchains
2. Update the Android and iOS configuration transitions to transition using platforms instead of the legacy flags and create an incompatible flag for it
3. Make downstream projects green (including updating their config_setting statements that use --cpu/--crosstool_top/--compiler)
4. Flip the flag

1-2 need to happen before 0.29, 3-4 need to happen before 1.0. 1-2 also need to be scheduled and time is already tight, so I'd expect around two weeks of delay for 0.29 in that case (but Pedro should know better how realistic that estimate is)

What do you think? (I'm expecting an explicit opinion from Dmitry, Peter and Pedro)

[Lukács T. Berki]

I'll try to executively summarize the previous executive summary :)

First we have to decide if we want to ship C++ platforms in 1.0 or not. If not, we are done. If yes, we have to flip at least the flag that turns it on by default on the target and host platforms.

Then for each of Android and iOS we have the following options:

1. We do not do anything. Then they will be broken unless the user supplies a platform mapping file.
   
   
2. We turn off platform-based toolchain resolution for them. The cost is that this would mean that we can't remove the legacy toolchain-based selection mechanism, some complexity in the code, some complexity in user-visible behavior and that we haven't shipped the "fully platformize Bazel" goal. We may need to delay 0.29 and 1.0 by a few weeks for this.
   
   
3. We turn on platform-based toolchain resolution for them but keep the legacy transitions. This will make them require a platform mapping file like (1) and it requires that we define mobile platforms and constraints.
   
   
4. We fully platformize them. This requires that we define mobile platforms and constraints and changes to the code. We could piggyback on the existing flag so no incompatible flags will be needed or add another incompatible flag for this (which would need to be there in 0.29). We'd need either a domain expert or a can-be-deployed-anywhere Rambo for this and this would entail a delay to 0.29 and 1.0.

I prefer (4) because that's what "platformize Bazel" means. (3) is definitely out because it's almost as expensive and (4). (2) would be sad, but workable. (1) would be even more sad, but that's the only option if you don't want to delay 1.0 .

If you wish, I can also collate the advantages and disadvantages of each approach in a nice chart with bright colors ;)

Peter is also worried about everyone having to replace their legacy select() statements with platform-based ones. I'm a bit more optimistic about this, but that's mostly based on feelings and not data.

[Dmitry Lomov]

Do I understand correctly that: (1) means that:

(a)  everyone who uses Android and iOS rules will need to write a platform mapping file

(b) Android and iOS rules *can* be platformized and still work with Bazel 1.0

(c) (a) and (b) hold hypothetically but we have not verified that

If (a) and (b) then (1) is an ok state for 1.0, but we need to address (c) urgently (i.e. someone needs to write a platform mapping file, flip the flag and test; and have a platformization *prototype* for Android)

Makes sense?

Dmitry

[Lukács T. Berki]

On Thu, Jul 25, 2019 at 3:45 PM Dmitry Lomov <dsl...@google.com> wrote:

Do I understand correctly that: (1) means that:

(a)  everyone who uses Android and iOS rules will need to write a platform mapping file

Yes, in theory, but I haven't tried. Peter probably has.

 

(b) Android and iOS rules *can* be platformized and still work with Bazel 1.0

In theory. This depends on how their code is split between Starlark and Java and whether the necessary split configuration transition can be implemented in Starlark. In theory, it should work, but when I tried to do something similar, I ran into some rough edges.

(c) (a) and (b) hold hypothetically but we have not verified that

Correct.

 

If (a) and (b) then (1) is an ok state for 1.0, but we need to address (c) urgently (i.e. someone needs to write a platform mapping file, flip the flag and test; and have a platformization *prototype* for Android)

Makes sense?

This means demoting Android and iOS to the status of second-class citizens because they won't work out of the box with Bazel 1.0. If that's OK, it's not up to me to decide.

[Lukács T. Berki]

[Dmitry Lomov]

On Thu, Jul 25, 2019 at 4:27 PM Lukács T. Berki <lbe...@google.com> wrote:

On Thu, Jul 25, 2019 at 3:51 PM Lukács T. Berki <lbe...@google.com> wrote:

On Thu, Jul 25, 2019 at 3:45 PM Dmitry Lomov <dsl...@google.com> wrote:

Do I understand correctly that: (1) means that:

(a)  everyone who uses Android and iOS rules will need to write a platform mapping file

Yes, in theory, but I haven't tried. Peter probably has.

 

(b) Android and iOS rules *can* be platformized and still work with Bazel 1.0

In theory. This depends on how their code is split between Starlark and Java and whether the necessary split configuration transition can be implemented in Starlark. In theory, it should work, but when I tried to do something similar, I ran into some rough edges.

(c) (a) and (b) hold hypothetically but we have not verified that

Correct.

 

If (a) and (b) then (1) is an ok state for 1.0, but we need to address (c) urgently (i.e. someone needs to write a platform mapping file, flip the flag and test; and have a platformization *prototype* for Android)

Makes sense?

This means demoting Android and iOS to the status of second-class citizens because they won't work out of the box with Bazel 1.0. If that's OK, it's not up to me to decide.

Well they will if users add a platform mapping file - which is not ideal, but Android and iOS rules can then be *made* to work with Bazel 1.0 without delaying it.

What we urgently need is to address uncertainty as expressed in (c) above.

[Pedro Liberal Fernandez]

1-2 need to happen before 0.29, 3-4 need to happen before 1.0. 1-2 also need to be scheduled and time is already tight, so I'd expect around two weeks of delay for 0.29 in that case (but Pedro should know better how realistic that estimate is)

I'm catching up with everything related to platforms but thanks to the excellent documentation I think I can more or less answer this.

My understanding is that to be in an acceptable state for 1.0, it would be enough to create a mappings file for Android and iOS. We would also need to write toolchain() and platform() rules.

Writing toolchain() rules may be more or less straightforward just by looking at the existing cc_toolchain() rules. I don't know from which concept of the legacy way of doing toolchains we could derive meaningful platforms. As far as I can see, nothing similar existed before so we would have to come up with them. Now for Android, what makes sense here? OS and CPU? Also Android version? Something else that a domain expert would think it's important?

Do we also know how well mapping files work? The integration test seems to cover everything pretty well but IIUC mapping files have never been used before.

To answer the question whether 2 weeks is reasonable, I would say it depends on whose two weeks. I feel like it might be reasonable if the most knowledgeable person in the team for Android and iOS is on it full time and approving the design doc to agree on sensible platforms doesn't take too long.