Native plugin has restriction when defining custom toolchain

Bugs
1

I’ve tried to defined my own toolchain based on the Gcc (Keil Arm).
`
model {

toolChains {
    ArmCc(Gcc) {
        path "${System.env.TOOLDISK}\\Keil_v5\\ARM\\ARMCC\\bin"
        eachPlatform {

            cCompiler.executable = 'armcc'
            cppCompiler.executable = 'armcc'
            staticLibArchiver.executable = 'armar'
            linker.executable = 'armlink'
            assembler.executable = 'armasm'
        }
    }
}

components {
    main(NativeExecutableSpec) {
    }
}

}
`
Unfortunately it doesn’t work, since armcc.exe doesn’t support version read in the same way as gcc, so I have following error:

- executable 'main:executable': No tool chain is available to build for platform 'windows_x86':
    - Tool chain 'ArmCc' (GNU GCC): Could not determine GCC version: failed to execute armcc.exe -m32 -dM -E -.

It would work, if function GccVersionResult from org.gradle.nativeplatform.toolchain.internal.gcc.version would support in a better way version reading. I mean GccVersionResult should not brake if compiler cannot handle “-dM -E” parameters.

It’s not even possible to implement custom GccVersionResult, since it’s a private function.

The funny thing is that GccVersion is used only to validate if it has a support for ‘CanUseCommandFile’, which is true for the Keil ARM compiler.

2

Which version of Gradle you are using?

3

the latest and greatest - 2.11

4

I’d also appreciate a solution for this painful restriction…

I really want to get my gcc and arm build harmonized (the latter currently is hard-coded :frowning: )

I also miss a possibility to plug in any custom compiler…

1 Like
5

Looking into the GccVersionDeterminer.java it’s sufficient to replace two “return new BrokenResult” from the GccVersionResult function to the e.g. Logger warning. The change is safe, since it only determines if compiler could handle reading parameters from a file. However it would be nice if such a change is added to the official source.

If needed I can provide a fix.

2 Likes
6

Hi all, dear Gradle team,

is there a plan and chance to integrate / accept the described change requests in future Gradle releases? It is unfortunately quite painful to constantly adapt the Gradle tool chain with every release, change those source files, and then rebuild Gradle because of this.

Pls. help us in this point and relax Gradle behavior wrt.t his topic!
Thanks in advance!
BR,
Franz

1 Like