Custom gcc toolChain definition doesn't work for all gcc compilers (Gradle 2.0, 2.1 rc)

Old Forum Archive
1

Kudos on rc 2.1, really liking the new components feature, very useful.

I have an issue still with 2.1 that came about with 2.0 and the “easier” configuration of new toolChains. I have a cross compiler on Linux for a powerpc based hardware that uses a gcc type toolChain. Under 1.12 I was able to configure the toolChain by adding the appropriate prefix to the commands, some additional args, and a PlatformConfigurableToolChain and it worked great. Under 2.0 I can still define the prefix and additional args, however the PlatformConfigurableToolChain is no longer needed and Gradle appears to assume that all gcc compilers support the @options.txt type definition of command line arguments but for my gcc compiler this is not true. Under Gradle 1.12 it appears that with a PlatformConfigurableToolChain all the arguments were passed on the command line, under 2.x it appears that it only passes using the @options.txt arugment, so I can no longer compile for this target.

2

Apologies for the delay replying. Without looking deeper, my guess is that the change to use the option file is unrelated to the new ‘target platform’ DSL. But we’ve made some changes to the way we detect the GCC version, which in turn determines whether Gradle considers whether GCC can handle an options file. If Gradle detects the GCC version to be >= 4.0, an options file will be used.

There have been recent changes to this functionality, so perhaps the best way forward would be to see if we can get things working with the latest nightly build of Gradle. It may be that things “just work” due to this commit, or you might be able to disable the use of the command file like this:

model {
    toolChains {
        omnilinux_ppc(Gcc) {
            target("omnilinux_ppc") {
                canUseCommandFile = false
            }
        }
    }
}

Let me know how you go.

3

Something else is broken in the nightly build gradle-2.2-20140916220025+0000, when I execute gradle tasks I get the following error:

Could not find property 'ExecutableBinary' on task ':VMFMgr:buildAllExecutables'.

because I have the following

task buildAllExecutables {
    dependsOn binaries.withType(ExecutableBinary).matching {
        it.buildable
    }
}

and that particular gradle file doesn’t have any executables in it, it is a library only. Under previous versions including 2.1-rc-1 this isn’t a problem. I will try the other method.

4

Yep, this class was deprecated and replaced by ‘NativeExecutableBinary’ in 2.1, and removed in 2.2. We try to keep the release notes updated for nightly builds, so they are worth checking out: http://www.gradle.org/docs/nightly/release-notes.html#native-language-support

5

Sorry, I didn’t look at the release notes, I corrected that and tried the latest nightly build and it still is attempting to using the options.txt file. I also tried adding

canUseCommandFile = false

to my existing

target("omnilinux_ppc") {

section and it still attempts the use of options.txt. I verified the gcc version for omnilinux and it is 3.3.1. I verified it is using that target section by adding a unique flag to the args and it does generate that unique flag in the options.txt file. This is the same section is where the compiler executable is defined and the correct executable name appears in the output of gradle as well.

6

OK so I had a closer look, and it seems that ‘canUseCommandFile’ isn’t an option, since this (internal) property will be overwritten by Gradle based on the determined version for GCC.

My hunch is that for some reason the method ‘AbstractGccCompatibleToolChain.initTools()’ is calculating the wrong version for GCC. This method iterates over available compilers for GCC and uses ‘GccVersionDeterminer’ to work out the version of GCC. In a previous post the configuration you posted doesn’t include an updated path for ‘cCompiler’: this is the first compiler that Gradle will use to determine the version. So Gradle may be finding the default version of ‘gcc’ on the path and using that to work out the version of ‘omilinux_ppc’.

Can you ensure that you’re setting ‘cCompiler.executable’ for your custom tool chain?

If that’s all good, the next thing to do is to take a look at the output of ‘gcc -dM -E’ for this GCC version. This is the output that ‘GccVersionDeterminer’ uses. If you get some unusual output, you could add a test case to ‘GccVersionDeterminerTest’ and supply a patch that makes it work.

7

That was it, I added

cCompiler.executable = prefix + cCompiler.executable

for omnilinux_ppc and it works correctly now, thank you for all your help.

8

Glad we finally got it working for you.

9

I’ve been trying to do this myself for the msp430 target and I can’t seem to get gradle to recognize the TargetPlatformConfiguration class. It claims it cannot find it.

I assume this is a silly error on my part but I was wondering if anyone could point it out? My code looks very similar to the link Ken posted.

Also, is there a comprehensive guide on how to create custom toolchains for arbitrary architectures either with Gcc or Clang?

Edit: I see that the TargetPlatformConfiguration usage has been deprecated without a plugin, and I am now getting the error that the msp430 is not one of the supported targets.

My last question still stands about a comprehensive guide to porting new architectures. In the meantime I will investigate the process. It would be nice if there wasn’t a need for an entire new plugin to do so. A standalone toolchain file perhaps would be convenient maybe…

10

It was deprecated and incorporated into the main definition, is the msp430 gcc based? If so you should be able to follow my posting. Either define the path to a new gcc or define custom names whichever applies and it should work. The only thing I have added since the original post was definition of cCompiler in addition to the others already there since that is what it uses to determine the version of the gcc compiler is in use. Which version of Gradle are you using and if you post yours it would be easier to debug. I found my examples either in the manual or in the samples that come with the full download of Gradle or the test cases provided.