gradle-native icon indicating copy to clipboard operation
gradle-native copied to clipboard

VisualCpp toolchain getInstallDir() and getWindowsSrdDir() returning null

Open prb28 opened this issue 7 years ago • 4 comments

The visualCpp toolchain work perfectly but the methods to get it's installation directory always return 'null'.

In the build script:

...
model {
    binaries {
        withType(NativeBinarySpec) {
            if (toolChain in VisualCpp) {
                println "installDir : $toolChain.installDir"
                println "windowsSdkDir : $toolChain.windowsSdkDir"
            }
        }
    }
}
...

Expected Behavior

In the stdout we should see:

installDir : C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726
windowsSdkDir : C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0

(expected output estimation)

Current Behavior

In the stdout:

installDir : null
windowsSdkDir : null

Context

To add the Microsoft Foundation Class (MFC) Library to the project I need to add the include path to the compiler.

model {
    binaries {
            rcCompiler.args "/IC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.15.26726\\atlmfc\\include"
            cppCompiler.args "/IC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.15.26726\\atlmfc\\include"
            if (targetPlatform.name == 'x86_64') {
                linker.args "/LIBPATH:C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.15.26726\\atlmfc\\lib\\x64"
            } else {
                linker.args "/LIBPATH:C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.15.26726\\atlmfc\\lib\\x86"
            }
    }
}

Steps to Reproduce (for bugs)

In a minimal build add the print options.

Your Environment

Windows 2010, Visual Studio 2017.

prb28 avatar Aug 22 '18 14:08 prb28

So, the ToolChain object is not intended to be a query API. Instead, it's intended as a specification API for setting up a custom toolchain. Which is to say, the getters here do not expose the toolchain that Gradle has discovered, but expose the values that have previously been set through this API. There's not an existing public API that will expose the discovered Visual Studio installation directly.

It sounds like what you want to accomplish here is to add some additional headers and libraries from the Visual Studio installation to the compile/link paths. This is something that we eventually want to support as explicitly modeled features or capabilities on the component, so that you can express that "this library requires MFC" and then we'll be able to select a toolchain that supports that capability, and add on the appropriate headers/libraries to the compile/link paths, possibly add additional flags, etc, etc. In other words, you wouldn't need to find the installation directory and then add everything to the paths, you would simply declare MFC as a requirement for your component.

This capability would be part of the new C++ plugin work that is underway, but is probably a little further out on the horizon (perhaps sometime in the next year).

ghale avatar Sep 18 '18 20:09 ghale

Thank you for this answer. Yes, my first need is to add some capabilities to the toolchain.

But I think it would be great to have some info about the discovered toolchain. As an example: for our build chain we had to create a classifier like os@flavour@build_type@target, for an example it can be "windows_vc17@default@release@x86" to publish the artifacts in an ivy repository. The version of the Visual C++ toolchain is important, it enables us to avoid the VC++ runtime mixing between libraries.

prb28 avatar Sep 18 '18 21:09 prb28

So, the ToolChain object is not intended to be a query API. Instead, it's intended as a specification API for setting up a custom toolchain. Which is to say, the getters here do not expose the toolchain that Gradle has discovered, but expose the values that have previously been set through this API. There's not an existing public API that will expose the discovered Visual Studio installation directly.

This is a request I made also for the traditional "Rule" plugin. I need to know which VisualStudio has been choosen by gradle in order to reuse the same compiler later on for a additional post compile task. So could you please add this 'getters' extension to the current "Rule" plugin?

zosrothko avatar Sep 19 '18 15:09 zosrothko

Is there any status on this? I am running into the same issue where I need to know where the toolchain gradle found is located.

tlf30 avatar Dec 15 '23 02:12 tlf30