[Request] Cross-compiling with custom toolchain

[g-berthiaume]

What problem will this solve? The Embedded systems industry is known for its hard-to-use tooling. I would see a bright future for premake in that space. To tap into this industry, you need a build a system capable of using weird toolchains to do cross-compiling.

What might be a solution? Supporting all the different toolchains available in the embedded world would not be practical. CMake solves this problem with the toolchain files. Juste use cmake -DCMAKE_TOOLCHAIN_FILE=path/to/file .. at build time. The toolchain file will define the path to the compiler, linker and assembler and other flags; so CMake can use it with its normal interface.

[samsinsane]

I had a brief look at the link you provided, how close does using something like gccprefix get you? I doubt it'll be a perfect fit, but work could be done to improve the situation for embedded devs - it's probably better to have an embedded dev figure out what kind of APIs are required for any toolchain to work, and perhaps even implement it all while trying it in their environment.

[nickclark2016]

Clang supports the cross compilation by setting a target triple, CPU, FPU, and float-ABI. I think this may be something we can expose as a first step to solve this problem. Maybe something like this?

targettriple "armv7a-non-eabi"
cpu "cortex-a57"
fpu "neon"
floatabi "Hardware"

For target-triple, this could be any string. Setting the CPU works for emitting code for specific ARM chips. The FPU flag specifies which FPU architecture to use on a target for ARM chips. Finally, the Float ABI flag sets the ABI for float, which would be one of: Hardwware, Software, or HardwareInstructionsSoftwareLinkage (names up for discussion). This would provide a good first step to adding cross compilation in Premake. This doesn't provide everything that CMake offers for custom toolchains, but it would be a step forward. Is this a path we want to go down @samsinsane @starkos.

[starkos]

I'll defer to someone with more cross-compiling experience, and a more immediate need for it. I'm not opposed to anything suggested here.

[samsinsane]

Within Premake, how would targettriple work with architecture?

[tritao]

I think the targettriple model would be pretty nice to have on Premake.

From Clang docs, the triple has the general format <arch><sub>-<vendor>-<sys>-<abi>, where:

• arch = x86_64, i386, arm, thumb, mips, etc.
• sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
• vendor = pc, apple, nvidia, ibm, etc.
• sys = none, linux, win32, darwin, cuda, etc.
• abi = eabi, gnu, android, macho, elf, etc

So I would add needed Premake commands for each part: architecture, subarchitecture, vendor, system, and abi.

Some like architecture and system already exist so not needed, but would probably need to be extended to support the triple naming standards (i.e. macosx vs darwin). Maybe we could deprecate the old names, but would really need to think a little more about that to see if any problems would come up.

If you use the general targettriple command, then Premake would parse it (can look at LLVM code for that) and set each individual part. But it could also be overriden individually with each specific part command.

[samsinsane]

Some like architecture and system already exist so not needed, but would probably need to be extended to support the triple naming standards (i.e. macosx vs darwin). Maybe we could deprecate the old names, but would really need to think a little more about that to see if any problems would come up.

I think the main issue here is that our system seems to have a similar but different meaning compared to the targettriple system. For example, iOS is apparently darwin too. Having both macosx and ios become darwin would mean that we'd need another API to pick the "Darwin SDK". Seems like it would be better for users to continue to specify macosx or ios, and for Premake to just map that to darwin if and where required.

Thinking about this a bit more, I think I can answer my own question: it wouldn't. targettriple is likely going to be specified by people who know exactly what they want, Premake shouldn't attempt to unpack it and set architecture and friends to the correct values it will only get in the way or get it wrong - instead, specifying targettriple should result in those APIs not working in most cases. For example, architecture shouldn't emit -m32 or -m64, it should emit nothing when targettriple has been set.

[nickclark2016]

Agreed. targettriple should override any values for architecture and system.