Android rules and --compiler flag interactions

[Austin Schuh]

I've got a repo where I build everything with both GCC and Clang.  I'm doing that by specifying the --compiler=gcc and --compiler=clang flags.

Unfortunately, this interacts pretty poorly with the android ndk rules.  I get a pretty hard build failure.  Up until now, I had NDK support disabled.  I'm currently running all our tests by doing a 'bazel test --cpu=k8 --compiler=gcc //...', and a 'bazel test --cpu=armhf-debian --compiler=gcc //...' to test the two architectures I am supporting.

The failure I get with NDK support enabled is:

$ bazel build --cpu=k8 --compiler=gcc //...

ERROR: No toolchain found for --cpu='armeabi-v7a' --compiler='gcc'. Valid toolchains are: [...

What is the suggested way to do this?  Is there a --android-compiler='gcc-4.9' type flag that I can pass in when building to force it unconditionally?  Could I generate a CROSSTOOL file to replace the default one so that I can pick a default 'gcc' and 'clang' compiler?

Thanks,

  Austin

[Alex Humesky]

Lukacs or Ulf may have a better answer, and we are working on our integration with the NDK, but as a workaround you might be able to arrange your code to have android in one spot and the rest in another, so that you can do something like "bazel build --fat_apk_cpu=armeabi-v7a,arm64-v8,<etc> //android/...".

If you want to take a look, the android crosstools are generated here:

https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/android/ndkcrosstools/AndroidNdkCrosstools.java

And if it's not already the case, we should probably make it so that you can supply your own crosstool file without the android_ndk_repository overwritting it.

--
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/CABsbf%3DF%2BwBMWa2R9btSy6hdpyFKQFdCxzTSv1zjy0QQqX3DOnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Lukács T. Berki]

Yes, our C++ toolchain selection process leaves something to be desired..

I was wondering if it makes sense to add a --android_compiler command line option that would act like --compiler, but for the Android toolchain. It's only a short term hack, because then there is a case to be made for a --android_ version of every command line option, though.

Greg has plans for something better, but they'll take some time to mature. 

Ulf, WDYT about --android_compiler? On the implementation side, it's on the order of minutes, but it's another piece of cruft we'd have to deal with in the long term.

--

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

Google Germany GmbH | Maximillianstr. 11-15 | 80539 München | Germany | Geschäftsführer: Graham Law, Christine Elizabeth Flores | Registergericht und -nummer: Hamburg, HRB 86891

[Austin Schuh]

Can you point me to where to make the change?  I don't mind making the change locally until there is a better solution.

Austin

[Austin Schuh]

Turns out it was pretty easy to get pretty close, but I now see a bigger issue.

ERROR: Multiple toolchains found for --cpu='armeabi-v7a' --compiler='gcc-4.9': [ --cpu='armeabi-v7a' --compiler='gcc-4.9' --glibc='local', --cpu='armeabi-v7a' --compiler='gcc-4.9' --glibc='local', --cpu='armeabi-v7a' --compiler='gcc-4.9' --glibc='local', --cpu='armeabi-v7a' --compiler='gcc-4.9' --glibc='local', --cpu='armeabi-v7a' --compiler='gcc-4.9' --glibc='local', --cpu='armeabi-v7a' --compiler='gcc-4.9' --glibc='local',].

It looks like the reason this works normally is that the default is specified in the CROSSTOOL file by the identifier.  What is the correct behavior here?

Austin

(Diff that I used is attached)

diff --git a/src/main/java/com/google/devtools/build/lib/rules/android/AndroidConfiguration.java b/src/main/java/com/google/devtools/build/lib/rules/android/AndroidConfiguration.java

index bffa529..2afe922 100644

--- a/src/main/java/com/google/devtools/build/lib/rules/android/AndroidConfiguration.java

+++ b/src/main/java/com/google/devtools/build/lib/rules/android/AndroidConfiguration.java

@@ -104,6 +104,12 @@ public class AndroidConfiguration extends BuildConfiguration.Fragment {

         help = "The Android target CPU.")

     public String cpu;

 

+    @Option(name = "android_compiler",

+        defaultValue = "null",

+        category = "semantics",

+        help = "The Android target compiler.")

+    public String cppCompiler;

+

     @Option(name = "strict_android_deps",

         allowMultiple = false,

         defaultValue = "default",

@@ -253,6 +259,7 @@ public class AndroidConfiguration extends BuildConfiguration.Fragment {

   private final StrictDepsMode strictDeps;

   private final boolean legacyNativeSupport;

   private final String cpu;

+  private final String cppCompiler;

   private final boolean incrementalNativeLibs;

   private final boolean fatApk;

   private final ConfigurationDistinguisher configurationDistinguisher;

@@ -267,6 +274,7 @@ public class AndroidConfiguration extends BuildConfiguration.Fragment {

     this.strictDeps = options.strictDeps;

     this.legacyNativeSupport = options.legacyNativeSupport;

     this.cpu = options.cpu;

+    this.cppCompiler = options.cppCompiler;

     this.fatApk = !options.realFatApkCpus().isEmpty();

     this.configurationDistinguisher = options.configurationDistinguisher;

     this.proguard = options.proguard;

@@ -279,6 +287,10 @@ public class AndroidConfiguration extends BuildConfiguration.Fragment {

     return cpu;

   }

 

+  public String getCppCompiler() {

+    return cppCompiler;

+  }

+

   public Label getSdk() {

     return sdk;

   }

diff --git a/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java b/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java

index 7928a1b..f3b48ed 100644

--- a/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java

+++ b/src/main/java/com/google/devtools/build/lib/rules/android/AndroidRuleClasses.java

@@ -222,6 +222,7 @@ public final class AndroidRuleClasses {

         // TODO(bazel-team): --android_cpu doesn't follow --cpu right now; it should.

         splitOptions.get(AndroidConfiguration.Options.class).cpu = cpu;

         splitOptions.get(BuildConfiguration.Options.class).cpu = cpu;

+        splitOptions.get(CppOptions.class).cppCompiler = androidOptions.cppCompiler;

         setCrosstoolToAndroid(splitOptions, buildOptions);

         result.add(splitOptions);

       }

[Alex Humesky]

At least part of this is because the NDK crosstool generator incorrectly creates a toolchain for each STL implementation in the NDK, which we're working on fixing. If all you need is gnulibstdc++ try deleting these lines:

https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/android/ndkcrosstools/AndroidNdkCrosstools.java#L154-L166

[Onath Claridge]

How do you disable NDK support? We're running into the same problem in upgrading to a newer Bazel version, but we definitely don't need android rules.

Thanks,

Onath

[Alex Humesky]

If you have no android rules in your project then bazel shouldn't be trying to use anything in the Android SDK or NDK. Can you give some more detail about what problems you're seeing?

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/8be05b59-e87d-483b-8f9f-7f43035b920e%40googlegroups.com.

[Onath Claridge]

With a sample target "vis", I'm running

    bazel build --crosstool_top '//lib/bazel:toolchain' --compiler clang vis,

where //lib/bazel:toolchain is my locally defined toolchain. I get back

    ERROR: No toolchain found for --cpu='armeabi-v7a' --compiler='clang'. Valid toolchains are: [...]

It builds fine (but with gcc) if I omit "--compiler clang".

My clang build was working back at Bazel version 0844112500.

[Onath Claridge]

BTW, "Valid toolchains are: [...]" was a truncation; it does in fact list a bunch of toolchains. :)

[Alex Humesky]

So just to confirm, you have no android rules in your project? (eg android_binary, android_library)

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAGuDmtHrFpJnQThavDjQ8jv_iEfM9V8jaggR5wKKgDC%2B7091TQ%40mail.gmail.com.

[Alex Humesky]

This is probably coming from here:

https://github.com/bazelbuild/bazel/blob/d3ec8ff875f8ac591c8c814b75f156cc077c2709/src/main/java/com/google/devtools/build/lib/Constants.java#L38

As a workaround, you can add a dummy android toolchain to your crosstool, as we have here:

https://github.com/bazelbuild/bazel/blob/d3ec8ff875f8ac591c8c814b75f156cc077c2709/tools/cpp/CROSSTOOL#L64-L95

[Erik Gilling]

Hi, I'm working with Onath on this.  The workaround does not seem to have any effect.  Additionally, the list of "Valid toolchains" does not bear any resemblance to our CROSSTOOL file.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAAvaYBkZgJfaEVDbbEe4UjSMz0gnKFGW2C1MBWiWxTReV_BXGA%40mail.gmail.com.

[Onath Claridge]

I got it to work by also specifying --android_crosstool_top.

To confirm, we aren't using any android rules.

[Alex Humesky]

Great, glad you got it to work

[Onath Claridge]

Another workaround, in place of the dummy toolchain, is to specify --fat_apk_cpu=k8, and point --android_crosstool_top to the same place our existing k8/clang toolchain is defined.

Needless to say, it would be nice if Bazel didn't make us do this. :)

[Lukács T. Berki]

@Austin: I think the best approach is to adopt your change that adds --android_compiler. This combined with Alex's change that fixes the duplication above should make your use case work.

@Onath: If we had --android_compiler, specifying --android_compiler would also make your use case work, although it's more than a little strange that you have to specify an Android-related command line option even though you you don't care about Android at all. Ideally, we'd omit Android stuff in this case (Greg is working on it), but it'll take a good while.

In the meantime, how about making --compiler not influence the Android compiler at all? Conveniently, that's what Austin's CL does (as far as I understand) and since it only affects builds using the --fat_apk_cpu command line option, we should be able to adopt it internally at Google, too, without much trouble.

Google Germany GmbH | Maximillianstr. 11-15 | 80539 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891

[Austin Schuh]

Lukács,

Works for me.  We've adopted my change at my work and it seems to be working well.  Do you need me to send something out to gerrit, or is the posted diff enough for you to work off of?

As far as I can tell, my patch makes --compiler not influence Android.  That was originally an unintended side effect, but I'm not sure it is a bad thing.

I'm really looking forwards to proper configuration support.  That should help here and in a lot of other cases that I run into often.

Austin

[Lukács T. Berki]

You're awake! :) If you'd like to be credited with the change, send out a Gerrit code review request and sign the Contributor License Agreement (http://bazel.io/contributing.html). Otherwise, I'll just send out the change myself (say, around EOD Europe)

[Austin Schuh]

I was checking email before going to bed, so I wasn't awake for much longer ;)  I'll try to send something out in the next couple of hours.

Austin

[Lukács T. Berki]

OK :) I didn't get around doing this today, so I'll wait for your change :)

[Austin Schuh]

https://bazel-review.googlesource.com/2112

Austin

[Lukács T. Berki]

Your CL has been pushed to Github:

https://github.com/bazelbuild/bazel/commit/fe24ff7f66f33eb84ba78b5068fe0fde685f0d6a

Thanks for the help :)