Behavior of Toolchain.addPlatformConfiguration for platform/toolchain filtering?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Behavior of Toolchain.addPlatformConfiguration for platform/toolchain filtering?

Xavier Ducrohet
I'm trying to build an executable under linux for both linux and windows, as well as mac on mac.
For Linux, I'm using a mingw32 toolchain that can output windows executables on linux.

I added a Clang toolchain for MacOS and the mingw32(Gcc) toolchain for windows, and forgot about linux. Basically I had this:

  1. toolChains {
  2. host(Clang)
  3. mingw(Gcc) {
  4. addPlatformConfiguration(new MingwOnLinuxConfiguration())
(I also setup the toolchain to point to the installed mingw)

With this TargetPlatformConfiguration:

  1. class MingwOnLinuxConfiguration implements TargetPlatformConfiguration {
  2. boolean supportsPlatform(Platform element) {
  3. return element.getOperatingSystem().name == "windows"
  4. }

What is extremely strange is that when building linux on linux, it should have failed: no Clang toolchain available, and mingw should be compatible with windows target only. Yet it used mingw to build linux. Is this expected?

I've also run into a few issues where changing C compiler Args or Linker Args doesn't trigger a new compile or linker execution. It seems like the task inputs don't take those into account properly (under Gradle 1.12). I can file a separate bug for this.

Once I fixed this (by adding another default Gcc toolchain), I was able to build linux/windows from Linux and Mac from MacOS which is pretty nice!



Reply | Threaded
Open this post in threaded view
|

Re: Behavior of Toolchain.addPlatformConfiguration for platform/toolchain filtering?

Daz DeBoer-2
On Wed, Jun 11, 2014 at 9:59 PM, Xavier Ducrohet <[hidden email]> wrote:
I'm trying to build an executable under linux for both linux and windows, as well as mac on mac.
For Linux, I'm using a mingw32 toolchain that can output windows executables on linux.

I added a Clang toolchain for MacOS and the mingw32(Gcc) toolchain for windows, and forgot about linux. Basically I had this:

  1. toolChains {
  2. host(Clang)
  3. mingw(Gcc) {
  4. addPlatformConfiguration(new MingwOnLinuxConfiguration())
(I also setup the toolchain to point to the installed mingw)

With this TargetPlatformConfiguration:

  1. class MingwOnLinuxConfiguration implements TargetPlatformConfiguration {
  2. boolean supportsPlatform(Platform element) {
  3. return element.getOperatingSystem().name == "windows"
  4. }
 
What is extremely strange is that when building linux on linux, it should have failed: no Clang toolchain available, and mingw should be compatible with windows target only. Yet it used mingw to build linux. Is this expected?

Yep. Gcc.addPlatformConfiguration() is adding a new supported platform to the set of platforms that are supported by Gcc by default.
There's not currently any way to replace or remove this default support.
 

I've also run into a few issues where changing C compiler Args or Linker Args doesn't trigger a new compile or linker execution. It seems like the task inputs don't take those into account properly (under Gradle 1.12). I can file a separate bug for this.

This definitely should work, but there might be cases in which it's not quite right. If you can provide more details that would be helpful.

--
Reply | Threaded
Open this post in threaded view
|

Re: Behavior of Toolchain.addPlatformConfiguration for platform/toolchain filtering?

Xavier Ducrohet
Thanks Daz, I'll try to see if I can reproduce.

I'm running into another question.

Since we are compiling a windows exe on linux using mingw32, I'm trying to run windres on a .rc and .ico file to generate an extra obj. How can I add this custom obj file to the linker call?


On Thu, Jun 12, 2014 at 6:42 PM, Daz DeBoer <[hidden email]> wrote:
On Wed, Jun 11, 2014 at 9:59 PM, Xavier Ducrohet <[hidden email]> wrote:
I'm trying to build an executable under linux for both linux and windows, as well as mac on mac.
For Linux, I'm using a mingw32 toolchain that can output windows executables on linux.

I added a Clang toolchain for MacOS and the mingw32(Gcc) toolchain for windows, and forgot about linux. Basically I had this:

  1. toolChains {
  2. host(Clang)
  3. mingw(Gcc) {
  4. addPlatformConfiguration(new MingwOnLinuxConfiguration())
(I also setup the toolchain to point to the installed mingw)

With this TargetPlatformConfiguration:

  1. class MingwOnLinuxConfiguration implements TargetPlatformConfiguration {
  2. boolean supportsPlatform(Platform element) {
  3. return element.getOperatingSystem().name == "windows"
  4. }
 
What is extremely strange is that when building linux on linux, it should have failed: no Clang toolchain available, and mingw should be compatible with windows target only. Yet it used mingw to build linux. Is this expected?

Yep. Gcc.addPlatformConfiguration() is adding a new supported platform to the set of platforms that are supported by Gcc by default.
There's not currently any way to replace or remove this default support.
 

I've also run into a few issues where changing C compiler Args or Linker Args doesn't trigger a new compile or linker execution. It seems like the task inputs don't take those into account properly (under Gradle 1.12). I can file a separate bug for this.

This definitely should work, but there might be cases in which it's not quite right. If you can provide more details that would be helpful.

--

Reply | Threaded
Open this post in threaded view
|

Re: Behavior of Toolchain.addPlatformConfiguration for platform/toolchain filtering?

Daz DeBoer-2
On Mon, Jun 16, 2014 at 5:30 PM, Xavier Ducrohet <[hidden email]> wrote:
Thanks Daz, I'll try to see if I can reproduce.

I'm running into another question.

Since we are compiling a windows exe on linux using mingw32, I'm trying to run windres on a .rc and .ico file to generate an extra obj. How can I add this custom obj file to the linker call?

Ideally, we'd add windres to the Gcc tool chain for support of Windows Resources. This shouldn't be hard to do code-wise but may require some updates to our CI infrastructure.

If you're already creating an object file and just want to link it in, you can do something similar to the WindowsResourcesPlugin:

                        final resourceOutputs = resourceCompileTask.outputs.files.asFileTree.matching { include '**/*.res' }
                        binary.tasks.createOrLink.source resourceOutputs

On windows, I don't think a static library can encapsulate resources, so if a static library contains resources we needed to include these explicitly when linking the static library into another binary:
                        if (binary instanceof StaticLibraryBinaryInternal) {
                            binary.additionalLinkFiles resourceOutputs
                        }

Please let me know how you go with this.
cheers
Daz

 


On Thu, Jun 12, 2014 at 6:42 PM, Daz DeBoer <[hidden email]> wrote:
On Wed, Jun 11, 2014 at 9:59 PM, Xavier Ducrohet <[hidden email]> wrote:
I'm trying to build an executable under linux for both linux and windows, as well as mac on mac.
For Linux, I'm using a mingw32 toolchain that can output windows executables on linux.

I added a Clang toolchain for MacOS and the mingw32(Gcc) toolchain for windows, and forgot about linux. Basically I had this:

  1. toolChains {
  2. host(Clang)
  3. mingw(Gcc) {
  4. addPlatformConfiguration(new MingwOnLinuxConfiguration())
(I also setup the toolchain to point to the installed mingw)

With this TargetPlatformConfiguration:

  1. class MingwOnLinuxConfiguration implements TargetPlatformConfiguration {
  2. boolean supportsPlatform(Platform element) {
  3. return element.getOperatingSystem().name == "windows"
  4. }
 
What is extremely strange is that when building linux on linux, it should have failed: no Clang toolchain available, and mingw should be compatible with windows target only. Yet it used mingw to build linux. Is this expected?

Yep. Gcc.addPlatformConfiguration() is adding a new supported platform to the set of platforms that are supported by Gcc by default.
There's not currently any way to replace or remove this default support.
 

I've also run into a few issues where changing C compiler Args or Linker Args doesn't trigger a new compile or linker execution. It seems like the task inputs don't take those into account properly (under Gradle 1.12). I can file a separate bug for this.

This definitely should work, but there might be cases in which it's not quite right. If you can provide more details that would be helpful.

--




--