Multi-arch build configurations (armhf/arm64) for Travis CI #24943
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change adds support for builds that target armhf/arm64 configurations alongside the current amd64 builds, which should bring support for single-board computers such as Raspberry Pi and Odroid into the core. Due to the Travis white-list freeze, the configuration for this process uses the 14.04 Trusty Tahr container, and uses the 16.04 Xenial Xerus repositories on ports.ubuntu.com to prepare a toolchain that contains the necessary dependencies for ARM cross-compilation. The arm64 configuration above will also use the same armhf dependencies as those builds for things like ripgrep. This should not pose an issue for users due to the backwards compatibility for ARMv8.
Dummy edit to trigger a final Travis CI build to test before issuing pull request
|
@headmelted, thanks for your PR! By analyzing the history of the files in this pull request, we identified @joaomoreno and @jrieken to be potential reviewers. |
This was referenced Apr 18, 2017
Adding deb and rpm packages for linux to the releases tag
|
Closed per #52119 (comment) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request takes the subset of the work done for my Raspberry Pi / Chromebook builds that could be useful to have in the core code and adapts it for some of the restrictions encountered on Travis CI as discussed below.
Some additions have been made to the Travis scripts to support reproducible ARM builds alongside the existing Linux and OSX amd64 builds.
The changes aim to keep the existing build configurations intact and operating exactly as before (listed in the YAML as &toolchain_linux_amd64 and &toolchain_osx_amd64) to prevent breaking anything.
The YAML has been re-structured to be a little more modular owing to the greater number of build configurations (listed under the matrix: node).
The intention of this pull request is to allow for additional cross-compilation targets to more easily be added to the Travis CI builds (with a view to expanding the officially supported platforms in the future), and provides hard-float ARM (armhf) and ARMv8 (arm64) configurations right now that should build immediately.
How this works
When the CROSS_TOOLCHAIN environment variable is set to true for a build configuration, an alternate toolchain will be prepared that uses the Travis CI trusty container, and re-creates the source packages list on the host VM to scope amd64 and i386 architectures to the main Ubuntu repositories, and the current target architecture (as defined by the ARCH environment variable) to the Ubuntu Ports repository. Unfortunately, due to the Travis CI whitelist freeze, and the need to reconfigure dpkg for an additional architecture, sudo is required for this process, which slightly increases the bootstrap time for the build session (although in my testing no more than was already required for the OSX builds, and they happen in parallel). As the automated testing currently runs on the amd64 builds (which happen faster due to not requiring sudo), this change should not increase the overall time for a given commit to build and "greenlight" successfully (in my test runs the cross-compilation builds generally finish before the amd64 builds have completed running tests/coveralls).
As some dependencies are historically not as well supported on other architectures as they are on amd64, it was necessary when re-creating the architecture-scoped package lists to point to the 16.04 (Xenial Xerus) repositories rather than the 14.04 (Trusty Tahr) repositories, not least as the cross-compilation step by GCC requires that the dependencies on amd64 and a given alternate architecture are version matched also.
The target architecture is provided in the form of a triplet (by way of the GNU_TRIPLET environment variable). If the dependencies for a given target require multilib support, as is the case for the arm64 target, this can be provided by the GNU_MULTILIB_TRIPLET environment variable.
The GPP_COMPILER and GCC_COMPILER environment variables directly correspond to the CXX and CC variables, and overwrite them as a first step of the build script. The reason for not directly setting the CXX and CC variables is that Travis CI will overwrite them for the cpp image while bootstrapping the build session, and this provides a workaround.
npm and Electron have a single ARM configuration at the present time which is broadly ARMv7l armhf, which is specified to the build script by way of the NPM_ARCH and VSCODE_ELECTRON_PLATFORM variables. As ARMv8 is backwards compatible, this should not pose a problem for 64-bit users.
Some repetition could have been saved by using the triplet name to build the g++ and gcc compiler references, but I decided against doing so as this does not hold true as a pattern for all targets (mingw, for example, has a slightly alternated naming convention).
In theory, adding support for architectures such as MIPS/PowerPC/SPARC should be as simple as adding a matrix entry and the triplet name, but I'm unsure if this is overkill as it seems unlikely that there would be demand on those platforms (old pre-2006 Macs that have since switched to Linux, maybe?).
If I can be of any assistance with this change please feel free to contact me on here or on twitter (@headmelted).