> > 2) Regarding the 'Build a native component using multiple tool chains' and > 'Build a native component for multiple architectures' stories, > Is there any plan to switch to the Visual Studio discovery mechanism to be > more dynamic than expecting the cl, lib and link executables to already be > on the Path (meaning that the environment was already configured)? > > > Absolutely. There will probably be a few parts to this: > > 1. Change the discovery mechanism to look in the default visual studio > install locations. We currently do this in our integration test fixtures, > so we'd move this code into the plugin. > 2. Add some way to specify where to look for various versions of a tool > chain. > 3. Handle multiple versions of the same toolchain. At the moment, there's > just 'visual c++' or 'gcc' but no way to specify which versions are > required, or to build using multiple different versions. > 4. For the visual c++ tool chains, automatically set up all the various > environment variables that need to be set when invoking the command-line > tools. > > Given that most of the installation information of Visual Studio is in the registry (naturally), outside of looking at the default locations, the environment variables VS<#>COMNTOOLS can be used as a basis for locating a given version of an installation. typically going up 2 parent directories of this environment variable leads to the root install directory, from there you can then get to the VC\vcvarsall.bat and use a 'x86' or 'x86_amd64' argument string to initialize the environment. Though some care is likely to be needed here as the x86_64 compiler has a tendency to be an optional installation piece, so it might not always be there. This is a practice that we've been using to support building in multiple versions.
> > > > > I also have interest in contributing to the completion of the support for > C++ and associated languages, though I'm not sure how much 'ramp up time' > there would be due to my current unfamiliarity with gradle's overall > codebase. > > > You'd be most welcome to contribute. Is there something specific you were > interested in? > > We're currently deeply reworking the C++ support, to implement a bunch of > the stories in the spec. The Gradle 1.7 release will contain the first > round of this work, with more to follow in the next few releases. So, the > internals (and externals) will be changing quite a bit, which might make it > a bit tricker to get started. > > If you let us know what you're interested in working on, we can help out > by fleshing out the spec with some implementation hints and so on. > > That's a bit of a tough question, given that I'm not aware of how aggressive of a timeline in that all the milestones/stories are trying to get hit. Between working on/with open source projects in such as x264 and ffmpeg primarily on a windows environment with MinGW and just about every version of MSVS at my work, I'd probably say the above is where my knowledge is primarily located. Outside of the visual studio project/solution integration stories, not currently sure where else I would be useful, though depending on what kind of timeline is being targeted for the completion of all this work I could potentially grab some other bits, time allowing. Thanks, --- Steven Walters > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > >
