Support for cross-compiling with Yocto

[eaaltonen]

The Yocto Project provides tools to create custom Linux distributions. The scope of this issue is to include the necessary support so that a Project using Gradle as it's build system can be cross-compiled within Yocto tooling and included in the distribution.

Bitbake is a tool of the Yocto project that generates:

• a cross-compiled kernel for the target
• a cross-compiled libc for the target
• a selection of (cross-compiled) libraries for the that the Gradle build may want to link against.

All of the above may change when the Yocto recipes are updated. The mechanism used within Yocto to pass this all of this information to all other build systems (Make, Autotools, CMake...) is with Environment variables. The below block roughly describes the environment with the values being placeholders:

PATH=paths/with:yocto/provided:crosscompilers/tools:and/scripts
CXX=cross-compiler-g++ -march=${cpu-arch} --sysroot=/path/to/yocto/sysroot --more --compiler --options
CC=cross-compiler-gcc -march=${cpu-arch} --sysroot=/path/to/yocto/sysroot --more --compiler --options
LD=cross-compiler-ld --sysroot=/path/to/yocto/sysroot

When compiling for Yocto, the Gradle shall use the C++ compiler, C compiler and linker from the $PATH specified by Yocto variables (there's more to choose from, but CXX, CC and LD seem like the obvious choices). Documentation for these variables is available in the Yocto Reference Manual.

When compiling for Yocto can be either:

• by default if the above variables are defined (most convenient for that use case)
• explicitly requested.

Regarding Compiler Flags

Although the tool to invoke and for example the ${cpu-arch} must obviously come from Yocto in this use case, a Gradle build might want to define additional compiler flags.

[lacasseio]

Thanks @eaaltonen for the great issue. To help us understand the priority, could you provide some more information on the impact such support would have on the native community? More specifically, I'm talking about the impact on the number of users: <10000, 10000..100000, 100000..1000000, >1000000. Also, it would be great to collect a list of Yocto projects that use Gradle as their build system.

[eaaltonen]

I decided to try this Requirements Specification style format so many are talking about - Glad you like it @lacasseio :)

As for the potential user base, you can estimate the scope roughly with the following:

• Yocto is used to create custom Linux distributions (products in a commercial setting)
• The Yocto project members (many of them are silicon vendors, the end products are done by their customers).

Also, it would be great to collect a list of Yocto projects that use Gradle as their build system.

Likely 0. Don't know how long you've been in the industry, but most things initially face the chicken and egg problem.

For cross-platform native development I some time ago came up with the following list: ["CMake", "Gradle"] #399 was a blocker going forward, so I turned to CMake.

The thing lacking in CMake is that it's in the developers responsibility to install all _correct version dependencies before they can even start to build. Gradle could have an edge in this respect.

And finally, when compiling for Yocto Gradle shall use the dependencies available in the --sysroot=/path/to/yocto/sysroot (and complain if the versions do not match).

[smarks86]

+1