From the example in the docs:
model { and the DSL documentation, it seems the only configuration for a GCC toolchain is the "path". I've tried to use it but it seems like it always revert to my install GCC that's present in the path. Looking at the info output it shows: Starting process 'command '/usr/bin/g++''. Working directory: /usr/bin Command: /usr/bin/g++ -dM -E - But it doesn't show the same for my custom toolchain, so it seems like it's not even trying to use it.
One thing though is that my custom toolchain doesn't have a g++ entry in its "bin" folder. Instead it has "i686-linux-g++". Is this the source of the problem? The Gcc class has properties for the c/c++ compiler, linker, etc... but those are read only so I can't customize them. thanks Xav
|
On Thu, Mar 6, 2014 at 12:37 PM, Xavier Ducrohet <[hidden email]> wrote:
Yes, this is likely Gradle executing the compiler to get the version string.
If you actually try to build something, you should get a message describing why the tool chain is not available. Are you not seeing that? Perhaps just define an executable with a windows platform, and see what gets reported.
Very likely.
What version of Gradle are you using? These properties are indeed read-only, but they are configurable objects of type 'GccTool':
Daz |
Hi Daz, I'm not seeing any message about my toolchain not being available. When I try to build the MacOS exe on linux it does complain with: Execution failed for task ':compileDarwin32MksdcardExecutableMksdcardC'.
> No tool chain is available to build for platform 'darwin32': - Tool chain 'visualCpp' (Visual Studio): Visual Studio is not available on this operating system. - Tool chain 'gcc' (GNU GCC): Don't know how to build for platform 'darwin32'.
- Tool chain 'clang' (Clang): Could not find C++ compiler 'clang++' in system path. I'm using Gradle 1.11, and I hadn't realized GccTool can customize the executable!
My build.gradle file now looks like: model { toolchains { gcc(Gcc) { path '/path/to/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.7-4.6'
cCompiler.executable = 'x86_64-linux-g++' cppCompiler.executable = 'x86_64-linux-g++' linker.executable = 'x86_64-linux-ld' assembler.executable = 'x86_64-linux-as'
} } } and it's still not doing anything. The --info still doesn't show any special output about my config being broken (or even used in anyway).
Am I correctly replacing the default toolchain or just adding a new one that's lower priority than the default? On Thu, Mar 6, 2014 at 11:59 AM, Daz DeBoer <[hidden email]> wrote:
|
ok so with progress made on the other thread, I'm running into new problems. I'll keep on this thread since it's more relevant. with: toolChains {
gcc(Gcc) { path '/path/to/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.7-4.6/bin' getCCompiler().executable = 'x86_64-linux-g++' getCppCompiler().executable = 'x86_64-linux-g++'
getLinker().executable = 'x86_64-linux-ld' getAssembler().executable = 'x86_64-linux-as' } building fails with:
* What went wrong: Execution failed for task ':compileLinux32MksdcardExecutableMksdcardC'. > No tool chain is available to build for platform 'linux32':
- Tool chain 'gcc' (GNU GCC): - Could not find Objective-C++ compiler 'g++'. Searched in: /usr/local/google/home/xav/dev/ext/idea133/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.7-4.6/bin
It looks like it's still looking for "g++" instead of the compiler executable I set. I'm also a bit confused with the message mentioning "Objective-C++". On Thu, Mar 6, 2014 at 12:14 PM, Xavier Ducrohet <[hidden email]> wrote:
|
On Thu, Mar 6, 2014 at 2:10 PM, Xavier Ducrohet <[hidden email]> wrote:
Well that's a pretty sucky experience :). We've added Objective-C++ support for GCC, but in doing so we've made it a requirement that each GCC tool chain have an objective-c and objective-c++ compiler. These are named 'gcc' and 'g++' by default, but there's no equivalent mechanism to set the executable for them.
Your best bet would be to create empty files named 'g++' and 'gcc' in the same directory. Or symlink the real compilers to those names. Apologies for the inconvenience. Daz
|
Thanks Daz, Is there time to fix this in 1.12? I'll create a script that temporarily create those files so that I can move forward. thanks again.
On Thu, Mar 6, 2014 at 1:19 PM, Daz DeBoer <[hidden email]> wrote:
|
On 7 Mar 2014, at 8:24 am, Xavier Ducrohet <[hidden email]> wrote:
Yes there is. I’ll fix it soon.
-- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com |
great, thanks! On Thu, Mar 6, 2014 at 1:46 PM, Adam Murdoch <[hidden email]> wrote:
|
On 7 Mar 2014, at 9:04 am, Xavier Ducrohet <[hidden email]> wrote:
-- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com |
cool, thanks! On Mon, Mar 10, 2014 at 12:25 PM, Adam Murdoch <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |