Gradle vs. Make for AOSP build

[Dmitry Sokolov]

Hello,

As it was announced during I/O, the build of Android applications is being moved from Ant to Gradle.

Does Android team have any plans to migrate Android platform build from Make to Gradle?

Thank you,

Dmitry

[Jean-Baptiste Queru]

No such plans at the moment. Last time I checked, Gradle didn't support parallelism, and that's a non-starter for AOSP.

Any change in build system is a very massive undertaking. As measured within Google's source tree, the build system is close to 600k lines of code. On its own, re-writing 600k lines is not a trivial task.

On top of that, we have to take the whole ecosystem into account. Even if Google somehow managed to do that switch internally, the rest of the ecosystem would probably have a hard time switching at the same time, so we'd still need to be able to manage classic product configurations and module definitions, for a transition period that couldn't last for less than 2 full releases but might realistically need to stretch over 2 or 3 years.

Since I have first-hand experience in doing massive build system switches (I was involved in one a few jobs ago), here's what my advice would look like:

-tighten the syntax for product makefiles, board makefiles and module makefiles by having the build system issue warnings for the ones that don't follow the rules.

-tighten more by making non-compliance an error but allowing each makefile to opt out.

-tighten more by making the opt-out part centrally controlled.

-move to nested build systems, where the classic build system invokes the new one for all the properly-written makefiles.

-move the special cases over, one by one.

-retire the old build system.

The cornerstone is to tighten the product definitions and board definitions, since those will need to be read by both sides.

The real pain isn't about all the regular makefiles: converting those is just a long slow grind. The real pain is about all the special cases at the heart of the system: libc.so doesn't follow regular rules, neither does core.jar, neither does framework.jar, neither does libwebcore.so, just to name a few "interesting" cases.

JBQ

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[Dmitry Sokolov]

Thank you, JBQ

I completely agree with you regarding the scope of work required. Just wanted to confirm if there are any plans..

As far as I know, Gradle 1.6 introduced incubating feature for parallel execution (not for parallel configuration yet), which parallelize across projects only (not within the same project). So, I think you are right, there is no an equivalent level of support for parallelism in Gradle yet.

The benifit I like in the idea of Gradle migration is sharing the same set of build/makefiles for platform and application (SDK based) builds. However, like you mentioned, it is not an easy effort, which should not compromise performance of the build.

Regards,

Dmitry 

[Kenneth Endfinger]

Gradle now supports parallelism and is amazing super at gigantic (uber-gigantic) build configurations. Can you update your position on the matter? 

[Jean-Baptiste Queru]

Gradle supporting parallelism means that migrating to it for AOSP went from "pointless" to "impractical".

In addition to the earlier discussion (which remains valid), keep in mind that Google has been slowing down the release pace for Android, with almost a year between KitKat and Lollipop, and that could proportionally lengthen any migration.

JBQ

 

--

Jean-Baptiste M. "JBQ" Quéru
Architect, Mobile, Yahoo

For more options, visit https://groups.google.com/d/optout.

[Ying Wang]

Totally agreed.

[Kenneth Endfinger]

I could write a makefile to gradle generator.

You received this message because you are subscribed to a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/dxP0tp0e1MI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-buildi...@googlegroups.com.

[Stuart Small]

What is the advantage of moving to gradle?

[Dmitry Sokolov]

It would be nice to see Android platform build template, something like "BUILD_GRADLE". It is important to note that in context of the platform build, Gradle should be able to:

1. Exclude resources that correspond to dpi levels not stated in PRODUCT_AAPT_CONFIG (which is extremely important in the platform build to optimize size of preloaded packages)

2. Sign apks with the proper key (as stated in LOCAL_CERTIFICATE)

I am afraid if we start using gradle wrappers in the platform build, those 2 items won't be covered

[Glenn Kasten]

This thread is starting to veer off-topic for android-building.

As has been noted, this would be a major undertaking,

and I suggest that further serious discussion move to android-contrib.

https://groups.google.com/forum/#!forum/android-contrib

On Monday, November 10, 2014 11:30:25 AM UTC-8, Kenneth Endfinger wrote:

I could write a makefile to gradle generator.

To post to this group, send email to android-building@googlegroups.com

To unsubscribe from this group, send email to

android-building+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

---
You received this message because you are subscribed to the Google Groups "Android Building" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-building+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
You received this message because you are subscribed to the "Android Building" mailing list.

To post to this group, send email to android-building@googlegroups.com

To unsubscribe from this group, send email to

android-building+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/dxP0tp0e1MI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to android-building+unsubscribe@googlegroups.com.