What is the added advantage of using Bazel over Gradle? [closed]





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







10















I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:




Experimental Bazel Support



Some of these samples can be built with Bazel on Linux. These samples contain a BUILD.bazel file, which is similar to a build.gradle file. The external dependencies are defined in the top level WORKSPACE file.



This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.




Then,




  • What is the added advantage of using Bazel over the existing Gradle?

  • Is it really good to have TWO build tools for Android?

  • Does it mean that Android developers will probably need to learn this new build tool in future?




Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.



Update #2: Updated with google code labs for bazel android introduction.










share|improve this question















closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.














  • 2





    Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…

    – Jignesh Patel
    Jan 3 at 6:13













  • Does Google has a road map of migrate Android development from Gradle to Bazel?

    – shizhen
    Jan 4 at 1:53











  • @shizhen No, but there are codelabs for you to try it out.

    – Jin
    Jan 9 at 17:30


















10















I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:




Experimental Bazel Support



Some of these samples can be built with Bazel on Linux. These samples contain a BUILD.bazel file, which is similar to a build.gradle file. The external dependencies are defined in the top level WORKSPACE file.



This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.




Then,




  • What is the added advantage of using Bazel over the existing Gradle?

  • Is it really good to have TWO build tools for Android?

  • Does it mean that Android developers will probably need to learn this new build tool in future?




Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.



Update #2: Updated with google code labs for bazel android introduction.










share|improve this question















closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.














  • 2





    Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…

    – Jignesh Patel
    Jan 3 at 6:13













  • Does Google has a road map of migrate Android development from Gradle to Bazel?

    – shizhen
    Jan 4 at 1:53











  • @shizhen No, but there are codelabs for you to try it out.

    – Jin
    Jan 9 at 17:30














10












10








10


6






I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:




Experimental Bazel Support



Some of these samples can be built with Bazel on Linux. These samples contain a BUILD.bazel file, which is similar to a build.gradle file. The external dependencies are defined in the top level WORKSPACE file.



This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.




Then,




  • What is the added advantage of using Bazel over the existing Gradle?

  • Is it really good to have TWO build tools for Android?

  • Does it mean that Android developers will probably need to learn this new build tool in future?




Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.



Update #2: Updated with google code labs for bazel android introduction.










share|improve this question
















I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:




Experimental Bazel Support



Some of these samples can be built with Bazel on Linux. These samples contain a BUILD.bazel file, which is similar to a build.gradle file. The external dependencies are defined in the top level WORKSPACE file.



This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.




Then,




  • What is the added advantage of using Bazel over the existing Gradle?

  • Is it really good to have TWO build tools for Android?

  • Does it mean that Android developers will probably need to learn this new build tool in future?




Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.



Update #2: Updated with google code labs for bazel android introduction.







android gradle android-gradle android-testing bazel






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 22 at 8:16







shizhen

















asked Jan 3 at 5:08









shizhenshizhen

4,13441337




4,13441337




closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.









closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.










  • 2





    Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…

    – Jignesh Patel
    Jan 3 at 6:13













  • Does Google has a road map of migrate Android development from Gradle to Bazel?

    – shizhen
    Jan 4 at 1:53











  • @shizhen No, but there are codelabs for you to try it out.

    – Jin
    Jan 9 at 17:30














  • 2





    Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…

    – Jignesh Patel
    Jan 3 at 6:13













  • Does Google has a road map of migrate Android development from Gradle to Bazel?

    – shizhen
    Jan 4 at 1:53











  • @shizhen No, but there are codelabs for you to try it out.

    – Jin
    Jan 9 at 17:30








2




2





Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…

– Jignesh Patel
Jan 3 at 6:13







Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…

– Jignesh Patel
Jan 3 at 6:13















Does Google has a road map of migrate Android development from Gradle to Bazel?

– shizhen
Jan 4 at 1:53





Does Google has a road map of migrate Android development from Gradle to Bazel?

– shizhen
Jan 4 at 1:53













@shizhen No, but there are codelabs for you to try it out.

– Jin
Jan 9 at 17:30





@shizhen No, but there are codelabs for you to try it out.

– Jin
Jan 9 at 17:30












2 Answers
2






active

oldest

votes


















8














Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:




  • 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.


Bazel Build Files



Bazel operates off of two configuration files: BUILD and WORKSPACE



The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.



enter image description here



The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:



enter image description here



Gradle Build Files



The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.



The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:



enter image description here



Things that Bazel does really well include:





  • bit for bit reproducibility. This is EXCELLENT.


  • Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.


  • Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.


  • Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.





Bad about bazel



Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.



Conclusion:



There is a similar level of functionality between these two build
formats, and it becomes apparent that the two systems are made with
different philosophies. Bazel provides a structured system that is
easy to reason about and provides a strong, functional foundation for
large and growing products. Gradle, on the other hand, offers a
flexible, stateful, object-oriented interface that may feel familiar
to those who don’t frequently use scripting languages.



For more references:




  • gradle team perspective on bazel

  • differences between bazel and gradle builds

  • what is gradle in android studio






share|improve this answer

































    4














    I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:




    • Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.

    • Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.

    • Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.

    • Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.

    • Bazel has a built in command called mobile-install, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.



    Is it really good to have TWO build tools for Android?




    There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.



    Having the option to try out different approaches, IMO, is a good thing.




    Does it mean that Android developer probably need to learn this new build tools in future?




    Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.






    share|improve this answer


























    • "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

      – Mark Han
      Jan 3 at 19:19






    • 1





      @MarkHan Not yet, but we're working on it.

      – Jin
      Jan 3 at 19:26






    • 2





      @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

      – Jin
      Mar 15 at 4:46


















    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    8














    Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:




    • 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.


    Bazel Build Files



    Bazel operates off of two configuration files: BUILD and WORKSPACE



    The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.



    enter image description here



    The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:



    enter image description here



    Gradle Build Files



    The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.



    The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:



    enter image description here



    Things that Bazel does really well include:





    • bit for bit reproducibility. This is EXCELLENT.


    • Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.


    • Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.


    • Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.





    Bad about bazel



    Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.



    Conclusion:



    There is a similar level of functionality between these two build
    formats, and it becomes apparent that the two systems are made with
    different philosophies. Bazel provides a structured system that is
    easy to reason about and provides a strong, functional foundation for
    large and growing products. Gradle, on the other hand, offers a
    flexible, stateful, object-oriented interface that may feel familiar
    to those who don’t frequently use scripting languages.



    For more references:




    • gradle team perspective on bazel

    • differences between bazel and gradle builds

    • what is gradle in android studio






    share|improve this answer






























      8














      Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:




      • 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.


      Bazel Build Files



      Bazel operates off of two configuration files: BUILD and WORKSPACE



      The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.



      enter image description here



      The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:



      enter image description here



      Gradle Build Files



      The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.



      The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:



      enter image description here



      Things that Bazel does really well include:





      • bit for bit reproducibility. This is EXCELLENT.


      • Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.


      • Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.


      • Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.





      Bad about bazel



      Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.



      Conclusion:



      There is a similar level of functionality between these two build
      formats, and it becomes apparent that the two systems are made with
      different philosophies. Bazel provides a structured system that is
      easy to reason about and provides a strong, functional foundation for
      large and growing products. Gradle, on the other hand, offers a
      flexible, stateful, object-oriented interface that may feel familiar
      to those who don’t frequently use scripting languages.



      For more references:




      • gradle team perspective on bazel

      • differences between bazel and gradle builds

      • what is gradle in android studio






      share|improve this answer




























        8












        8








        8







        Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:




        • 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.


        Bazel Build Files



        Bazel operates off of two configuration files: BUILD and WORKSPACE



        The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.



        enter image description here



        The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:



        enter image description here



        Gradle Build Files



        The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.



        The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:



        enter image description here



        Things that Bazel does really well include:





        • bit for bit reproducibility. This is EXCELLENT.


        • Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.


        • Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.


        • Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.





        Bad about bazel



        Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.



        Conclusion:



        There is a similar level of functionality between these two build
        formats, and it becomes apparent that the two systems are made with
        different philosophies. Bazel provides a structured system that is
        easy to reason about and provides a strong, functional foundation for
        large and growing products. Gradle, on the other hand, offers a
        flexible, stateful, object-oriented interface that may feel familiar
        to those who don’t frequently use scripting languages.



        For more references:




        • gradle team perspective on bazel

        • differences between bazel and gradle builds

        • what is gradle in android studio






        share|improve this answer















        Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:




        • 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.


        Bazel Build Files



        Bazel operates off of two configuration files: BUILD and WORKSPACE



        The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.



        enter image description here



        The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:



        enter image description here



        Gradle Build Files



        The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.



        The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:



        enter image description here



        Things that Bazel does really well include:





        • bit for bit reproducibility. This is EXCELLENT.


        • Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.


        • Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.


        • Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.





        Bad about bazel



        Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.



        Conclusion:



        There is a similar level of functionality between these two build
        formats, and it becomes apparent that the two systems are made with
        different philosophies. Bazel provides a structured system that is
        easy to reason about and provides a strong, functional foundation for
        large and growing products. Gradle, on the other hand, offers a
        flexible, stateful, object-oriented interface that may feel familiar
        to those who don’t frequently use scripting languages.



        For more references:




        • gradle team perspective on bazel

        • differences between bazel and gradle builds

        • what is gradle in android studio







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Jan 6 at 12:35









        shizhen

        4,13441337




        4,13441337










        answered Jan 3 at 6:22









        FarhanaFarhana

        2,70552335




        2,70552335

























            4














            I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:




            • Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.

            • Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.

            • Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.

            • Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.

            • Bazel has a built in command called mobile-install, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.



            Is it really good to have TWO build tools for Android?




            There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.



            Having the option to try out different approaches, IMO, is a good thing.




            Does it mean that Android developer probably need to learn this new build tools in future?




            Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.






            share|improve this answer


























            • "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

              – Mark Han
              Jan 3 at 19:19






            • 1





              @MarkHan Not yet, but we're working on it.

              – Jin
              Jan 3 at 19:26






            • 2





              @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

              – Jin
              Mar 15 at 4:46
















            4














            I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:




            • Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.

            • Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.

            • Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.

            • Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.

            • Bazel has a built in command called mobile-install, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.



            Is it really good to have TWO build tools for Android?




            There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.



            Having the option to try out different approaches, IMO, is a good thing.




            Does it mean that Android developer probably need to learn this new build tools in future?




            Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.






            share|improve this answer


























            • "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

              – Mark Han
              Jan 3 at 19:19






            • 1





              @MarkHan Not yet, but we're working on it.

              – Jin
              Jan 3 at 19:26






            • 2





              @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

              – Jin
              Mar 15 at 4:46














            4












            4








            4







            I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:




            • Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.

            • Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.

            • Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.

            • Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.

            • Bazel has a built in command called mobile-install, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.



            Is it really good to have TWO build tools for Android?




            There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.



            Having the option to try out different approaches, IMO, is a good thing.




            Does it mean that Android developer probably need to learn this new build tools in future?




            Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.






            share|improve this answer















            I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:




            • Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.

            • Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.

            • Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.

            • Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.

            • Bazel has a built in command called mobile-install, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.



            Is it really good to have TWO build tools for Android?




            There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.



            Having the option to try out different approaches, IMO, is a good thing.




            Does it mean that Android developer probably need to learn this new build tools in future?




            Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 15 at 4:47

























            answered Jan 3 at 15:00









            JinJin

            6,16721931




            6,16721931













            • "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

              – Mark Han
              Jan 3 at 19:19






            • 1





              @MarkHan Not yet, but we're working on it.

              – Jin
              Jan 3 at 19:26






            • 2





              @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

              – Jin
              Mar 15 at 4:46



















            • "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

              – Mark Han
              Jan 3 at 19:19






            • 1





              @MarkHan Not yet, but we're working on it.

              – Jin
              Jan 3 at 19:26






            • 2





              @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

              – Jin
              Mar 15 at 4:46

















            "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

            – Mark Han
            Jan 3 at 19:19





            "maybe not external dependencies (yet)" any insight into when this may come @Jin ?

            – Mark Han
            Jan 3 at 19:19




            1




            1





            @MarkHan Not yet, but we're working on it.

            – Jin
            Jan 3 at 19:26





            @MarkHan Not yet, but we're working on it.

            – Jin
            Jan 3 at 19:26




            2




            2





            @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

            – Jin
            Mar 15 at 4:46





            @MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external

            – Jin
            Mar 15 at 4:46



            Popular posts from this blog

            MongoDB - Not Authorized To Execute Command

            How to fix TextFormField cause rebuild widget in Flutter

            in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith