What I’ve been thinking about for a while is the ability to support compiling native code for multiple platforms/architectures without having to have the environment pre-setup for it, like it does now for visual studio chains.
The highly repetitive nature of visual studio, as a build system, makes me really want to use something like gradle to alleviate my frustrations.
Two different scenarios I’ve recently had to partake in at work is 1) having to build google’s protocol buffers library with 10 total VS version/platform mixtures, when google only offered 1 mixture to start with. 2) having to update usage of an internal library to a newer build in about 6 VS projects (mixed platforms) totaling about 30 configurations across them all. which came out to me having to update about 120-150 different locations across the visual studio projects (not fun!).
So, right now I’m usually finding myself doing either of 1) Maintain large number of visual studio projects/solutions of the same code for each of the different versions - highly repetitive and opens up large chances for human error. 2) Use alternative building mechanisms, such as (obscure?) combinations of batch and GNU make.
Though I’m not quite sure as to the how extensive the problems I seem to encounter all the time at work are elsewhere…
With the enhancement, naturally the question of “what mixtures should projects be built with” arises, so the DSL would likely need some change to support the specification of the versions
apply plugin: 'cpp' NativeChains = [ NativeChain(compiler: NativeCompiler.VisualStudio, version: VisualStudio.VS_2010, platform: Platform.AMD64), NativeChain(compiler: 'msvs', version: '2013', platform: 'x86'), NativeChain(compiler: 'gcc', version: '4.8', platform: Platform.NATIVE) ]
comes to mind as a possibility in how this could manifest (and some possible conveniences to them). As for a default for this configuration, I’m leaning more towards there not being one and forcing it be specified, for simplicity purposes.
As to how this could manifest in an implementation, this would likely involve a couple top-level concepts.
Detect the platforms that Visual Studio supports and record the build environment for that platform. - Make a small temporary batch script to call the /VC/vcvarsall.bat and output the environment (such as with the ‘set’ command) changes for recording and later use/replication. These changes would include, but not be exclusive to, Path, LIBPATH, INCLUDE, and windowsSdkDir. - platforms i’m aware of VS supports/has supported are ‘x86’, ‘amd64’, ‘ia64’, and ‘arm’, either manifesting as native chains or as cross-prefix varieties (_) forms such as ‘x86_amd64’, ‘x86_ia64’, ‘x86_arm’ - These environment variables will be necessary for instantiating later processes such as cl, link, lib, rc, and eventually midl
With all sorts of version/platform mixes, it does become a potential mess, so a command/process factory of sorts is likely going to be useful in designing this, where it takes - a visual studio version - a platform - the process executable to start (not quite sure how ‘ml’ is going to ‘fit’ with it being one that changes names between platforms) which returns something to build the rest of the process arguments with (ProcessBuilder or similar), so arguments can just be added as necessary, expecting the environment and full path to the command already be initialized.
This theoretically could be the base primitives for such support, though things like 1) different intermediate object & cache locations for each mixture 2) different locations for final module/project outputs for each mixture would also need to be considered.
This framework could, seemingly easily, later be extended to support C# compilation (which we also use at work) with it’s special ‘Any’ platform
All in all, if this is considered I would love to try and convince my boss to let me work on helping implement the idea, seeing at how it would be able to alleviate our build maintenance headaches by gradle being the all-in-one solution for us.