On 22/02/2013, at 2:55 PM, Richard Bair wrote: > I have looked over the spec > (https://github.com/gradle/gradle/blob/master/design-docs/dependency-model.md).
There is also another spec that goes into our plans for c++ in more detail: https://github.com/gradle/gradle/blob/master/design-docs/continuous-delivery-for-c-plus-plus.md > Some of the questions I have are time / schedule related and some are just to > see if the upcoming native support fits our needs. > > Right now, we have make files for all of our native builds. Some of these I > could get rid of and just use Gradle to build. However the GStreamer & WebKit > make files are likely out of scope to convert -- we want to build the way > WebKit & GStreamer normally build, not rewrite their entire build system. So > I expect to end up doing something custom for those two cases. We usually suggest that you wrap the existing build for these things, so that Gradle can call out to whatever tool happens to build the binaries and then pick up the binaries from wherever they end up. We use this approach for migration, too, to avoid a big-bang switch to Gradle. > > In all other cases, we have to do the following: > - Use different compilers on different platforms > - Developers might develop using a free compiler on Windows > for example, but then we use a commercial compiler for > creating > the actual releases. > - gcc on Mac / Linux, but the Visual Studio compiler on Windows > for example The plugins support different compilers for different platforms (gcc, visual studio, and mingw). At the moment, they probe for the compilers and use whichever one they happen to find in the path. We'd like to add something to the DSL that can define exactly which compilers should be used or considered, so that you can declare things like: for a release build on windows, visual c++ must be used, for dev builds, use whatever you find. Each compiler is made available via the DSL, but there's not much you can do with them at the moment. Over time, we'll add more stuff to the compiler DSL, to let you adjust the settings for the compiler (e.g. the path to the compiler executable, perhaps some options that should be used for all invocations of that compiler). The support for each compiler is packaged in a separate plugin. The idea is we will open up the API for this so that support for more compilers can be added fairly easily, without touching the core c++ plugins. This might be combined with some kind of discovery mechanism to make this work in a portable way. > - Compile C / C++ / Objective-C > - Different compiler options depending on platform and project. > - For example we pass the -DNDEBUG param when building the font > natives, > -Wl when compiling on Linux and not Solaris, etc. The definition of each executable and library includes the compiler options to use for building that particular binary. You can combine this with some configuration injection to set up some defaults for all binaries, or all binaries on a particular platform, or all binaries built for a particular project, or whatever. > - Cross compile builds > - A single build can produce x86, ARM hard float, ARM soft float This is something we definitely plan to add. The idea is that each executable or library can be built into a number of variants, one for each combination of target platform, architecture, compiler and so on. We've started working on this for the jvm languages, to support things like Android apps and Groovy or Scala libraries that need to be built for various runtimes. This will be rolled across to the c++ plugins, and also into dependency management so that you can publish and resolve things in a variant-aware way. > - Build some native code on some platforms but not on others > - D3D can only be built on Windows, OpenGL we build on > everything One option would be to group these into separate source sets, and add the appropriate source sets to the binary based on the platform you're building for. > > I looked briefly at the existing C++ plugin but it didn't look like it > supported different compilers. The support is there, in a basic form at least. As mentioned above, we do plan to improve how this works. > > Is the new native support going to provide for all these use cases? Compiling > of Objective-C as well? Yes, I think what we plan should cover all your use cases. > > What is the schedule for the new native support? At this stage, I can't really promise anything, unfortunately. There's nothing planned for the Gradle 1.5 or 1.6 releases, except for the initial variant support I mentioned above (for the jvm languages, not the native languages). I'm hopeful that we might get to some c/c++ use cases in the releases after that, with some progress by the middle of the year. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
