Visual Studio InstallDir Accessor

Help/Discuss
1

Is there a way for me to access the Visual Studio installation directory Gradle discovered? My Windows native build needs headers & libraries in the installation directory and I’d prefer to not hardcode the location when Gradle already knows this information.

I’ve tried various ways to access the VisualCpp installDir, but my attempts fail with either an exception, return null, or return some wrapped DSL object clearly indicating I don’t know what I’m doing.

Thanks!

2

Have you tried going through the binaries?

binaries.withType(NativeBinary) {
   if (toolChain in VisualCpp) {
      do something with toolChain.installDir
   }
}
3

toolChain.installDir returns null

BTW - I’m running with Gradle 2.3. Maybe this is fixed in 2.4+

4

D’oh. I didn’t look at what that was used for last night. installDir is only populated if its specified in the build script, we don’t fill it in with the resolved path since we don’t know the installation directory until just before we compile. I don’t see a place where we expose this.

We do add some include paths already for Visual C++ (just include/ and the MS SDK). Are there additional “framework” type of things that are also installed in that path?

5

When I was looking at the Gradle source code, that’s what I thought I saw. But the code is complex and 95% of the time I’m wrong.

I require headers found in $vsInstallDirName\atlmfc\include.
I also have a dependency on a library found in $vsInstallDirName\atlmfc\lib\atls.lib

Gradle could easily add additional implicit headers from the install dir. The only risk is if a header of the same name exist in multiple directories in which case you’d have a dependency on the order of the headers on the command line.

It isn’t as clear that Gradle should have a concept of “implicit libraries” pulling some/all libraries distributed with the product. In this use case, I think the build script should have sole control over declaring these dependencies.

I understand all of the native stuff is a long work in progress. I’ve added my own plugins enhancing native builds with native external dependencies supporting variants which required support for publishing native build artifacts to a repository. I’m able to do everything that I need, though it might not be the elegant long term solution. So far, it is good enough. If I have to wait another year or so for the long term solution to come out, that’s fine with me. A small part of that long term solution should be allowing the build script access to the toolChain installDir.