On 13/05/2012, at 12:20 PM, Shad0w1nk wrote: > Hi, > > I started looking at Gradle more actively about 2 weeks ago. In fact, I am > more interested in the native (C/C++) portion that the Java. In the pass, I > used the Maven Nar plugin for building native on Windows desktop and on an > embedded Linux system. Unfortunately, Maven has there problem (mainly > flexibility) and Nar plugin doesn't really give official support for > enterprise. Looking at Gradle, you seem to be well place to give enterprise > level support. Sadly, the native capability is needed and looking at it more > in dept I can really see that it's in an experimental phase. > > Luckily, I would really want a tool like Gradle to work with native build. > Poking around in the forum, I can see that you actually have plan to bring > native support to Maven's Nar plugin level. I would like to help you achieve > this objective.
That would be excellent. > In order to do so, I would like to know more information > about the cpp plugin and design choice. I would like to know the following: > - What is the high level idea behind the class architecture of the cpp > plugin? These are the main concepts: * A Binary, which represents a native component built by the current project. * An Executable, which is-a Binary, and represents a native executable. * A Library, which is-a Binary, and represents a native library. * A CppSourceSet, which represents a bunch of source files that are compiled, linked and executed together. * A CompileSpec, which represents how to compile and link a bunch of source sets into a binary. * A Compiler, which knows how to compile and link binaries. > - Did you use Maven's Nar plugin as a reference and, if yes, what portion > did you use (or plan to use) and what portion do you think of doing better? Not really. There would be a few aspects where I'd see the Gradle plugin doing a better job than the Nar plugin: * Dependency management. In particular, things such as publishing and consuming variants (e.g. debug vs non-debug, 32-bit vs 64-bit, gcc3 vs gcc4, cross-compilation, and so on), flexibility in packaging, having c++ specific compile, link, and runtime dependencies, and c++ specific conflict resolution. * Performance. In particular, using Gradle's general-purpose incremental build capability to make compilation both fully incremental and accurate, and supporting parallel compilation. * Flexibility and maintainability. The plugin would pick up all the goodness of Gradle as far as flexibility and maintainability goes. > - What is the future plan of cpp plugin? In the short-term, we want to improve dependency management, as this is currently the weakest part of the c++ support: * Dependency management that works across all our target platforms. * A consistent mechanism for expressing native dependencies, regardless of whether the dependency is built by another project, downloaded from a repository, or installed on the machine somewhere. * Add support for building, publishing and consuming variants. * Define a convention for publishing native components to Ivy and Maven repositories. * Provide dependency management for artefacts that aren't built by Gradle, as part of easing the migration from some other tool to Gradle. Some other things that we want to do soon-ish: * Support for static libraries. * Support for some kind of unit testing. * Support for more compilers, and provide some better ways to customise and/or implement compiler adapters. * Incremental and parallel compilation. * Support for using the C compiler (rather than the C++ compiler) for compiling C code. * Better ways to specify platform and compiler specific compile options, and better control over the compiler that is used. Long-term things: * C# support, and other languages. * Support for packaging native apps and libraries into platform-specific packages: rpm, deb, dmg, msi, etc. * Support for building iPhone apps. * VisualStudio and XCode integration in some form. > - Why do cpp plugin has it's own way of defining the source set and the > configuration? Wouldn't it be simpler if the source set was define exactly > like Java and Groovy project? A good question. At the time we thought that the current source sets were too Java-specific, and we'd start again with the C++-specific source sets. Over time, we'll sync up the two approaches, so that there's one cross-language way to specify source sets. > - Why is there two plugin (cpp-exe and cpp-lib)? Wouldn't it be simpler if > the configuration was define in the global configuration and just specify > the type (lib or app)? There are 3 main plugins: * The 'cpp' plugin, that adds the DSL so that you can declare executables, libraries, source sets and so on, but does not actually specify any particular binary. * The 'cpp-exe' plugin, that extends the 'cpp' plugin to define a single executable. * The 'cpp-lib' plugin, that extends the 'cpp' plugin to define a single library. The 'cpp-exe' and 'cpp-lib' plugins are really just conveniences for a very common case. > > I know that I may no have a clear view of the architecture but from what I'm > seen, you guys seems to know where your heading. I would be great if you > could share this view so I can do what I can to contribute on this section. If you do want to contribute, it might be worth discussing what you want to work on in a little detail on the dev list before jumping in too far. I don't think the direction or vision is entirely clear from the code, and some of the stuff we want to do will involve some deep changes in other parts of Gradle. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
