› ›

GSOC 17 - Migration to gradle as build system

thefallthefall
edited March 2017 in Summer of Code 2017

Hi, I am interested in this project. Where should I start? How difficult will it be? I am currently going through the basics of Gradle.

Tagged:

Comments

  • codeanticodecodeanticode

    Hi, thanks for your interest! Are you thinking of using Gradle as a build system for the entire Processing source, or only for the Android mode (as discussed here)?

  • thefallthefall

    Hi! Yes, I meant gradle for the Android mode. I would like to know the issue list for this project and where I can start.

  • codeanticodecodeanticode
    edited March 2017

    Hi, the GitHub repository contains all the information about the project, including issues and build instructions.

    Note that Processing for Android can already be built using Gradle. However, we need to transition to Gradle as the internal build system that the Android mode uses to generate an Android package form the sketch code. This would likely involve re-implementing the AndroidBuild class (which currently uses ant).

  • thefallthefall

    @codeanticode

    I have been going through the AndroidBuild class file. One thing I understand is we have to use sdkmanager instead of android tool. But I don't get how where the ant scripts are and how we can use Gradle for the class. What I understand is the class is using the build.xml.tmpl file to create a build file. So the project will be removing the build template file and using a build.gradle file instead. Am I correct?

  • codeanticodecodeanticode

    Yes, you are correct. First, we would need to use the sdkmanager command line tool instead of the android tool to download the various components of the SDK.

    Right now the mode creates an ant project and then proceeds to run ant on it.

    The gradle export works by taking the ant project and moving files around to turn it into a gradle project. This could be useful to implement the gradle build.

  • thefallthefall
    edited March 2017

    Okay, what about methods like createLibraryProject()? Because it currently depends on the android tool to create the project but sdkmanager cannot do that.

  • thefallthefall

    @codeanticode

    I had a question - we are running ant builds programmatically, correct? If so, to migrate to Gradle, the Gradle Tooling API will be required. Using that we can replace the antBuild() with its gradle equivalent.

  • codeanticodecodeanticode

    @thefall answering your last two questions:

    • What about methods like createLibraryProject()? I believe most of them will become obsolete with the transition to gradle. In the particular case of createLibraryProject, it is used to create the library projects for AppCompat and the GVR SDK, but these are already provided as AAR packages, which are not supported by the ant toolchain, but can be used directly from gradle.

    • We are running ant builds programmatically, correct? Yes, I think we would need to use the Gradle Tooling API. One important consideration to keep in mind is that dependencies should not be downloaded during during the build process, but retrieved from the local SDK (which would be downloaded/uploaded beforehand).

    In general, I think that the Android Build class, and any related code, are slated for a major rewrite, since they grew organically since the early days when only regular android apps were supported and built using ant. Over time, and particularly during the last year, new functionality (wear/handheld apps, cardboard) was added, but without modifying the original structure, which led to a somewhat confusing codebase that will benefit a lot from a cleanup/rewrite.

  • thefallthefall

    @codeanticode

    Do I have submit my proposal here for review? I have already submitted it on the GSOC website.

Sign In or Register to comment.