gradle / gradle-native

The home of Gradle's support for natively compiled languages
https://blog.gradle.org/introducing-the-new-cpp-plugins
Apache License 2.0
91 stars 8 forks source link

Investigate sysroot configuration with Xcode's clang #1014

Open lacasseio opened 5 years ago

lacasseio commented 5 years ago

See https://github.com/Microsoft/azure-pipelines-image-generation/issues/898

ThadHouse commented 5 years ago

https://github.com/gradle/gradle/issues/9359

I had reported this to Gradle here as well, with full logs.

lacasseio commented 5 years ago

See https://github.com/gradle/gradle/issues/9359 for the complete logs to help the investigation.

ThadHouse commented 5 years ago

I asked on slack, but never got an answer. Why does gradle even handle the sysroot configuration. No other build system I have ever used has done this, and instead just calls the compiler directly. That seems to work fine for all the other build systems.

ThadHouse commented 5 years ago

Also for a workaround, here is a simple model rule that removes all the sysroot things from mac.

        @Mutate
        @CompileStatic
        void removeMacSystemIncludes(ModelMap<Task> tasks, BinaryContainer binaries) {
            binaries.each {
                if (!(it instanceof NativeBinarySpec)) {
                    return
                }
                NativeBinarySpec nativeBin = (NativeBinarySpec)it
                if (nativeBin.targetPlatform.operatingSystem.isMacOsX()) {
                    nativeBin.tasks.withType(AbstractNativeSourceCompileTask) { AbstractNativeSourceCompileTask compileTask->
                        compileTask.getSystemIncludes().setFrom()
                    }
                }
            }
        }
lacasseio commented 5 years ago

Modelling the sysroot allow for a better understanding of what the user's intention is and provide good defaults. We want to prefer stronger modelling and understanding than leaving everything to the user which requires more configuration to get something working.

ThadHouse commented 5 years ago

Ok. We will likely keep the rule posted above then, as we would prefer the compiler provide the defaults, rather then gradle choosing the wrong defaults.