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. 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?
- 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?
- What is the future plan of cpp plugin?
- 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?
- 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)?
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.
On 13/05/2012, at 12:20 PM, Shad0w1nk wrote:
That would be excellent.
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.
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.
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.
* 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.
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.
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.
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.
These are very interesting information. Your current feature list for short and soon-ish term is the most interesting for me (and for what I would like to achieve with Gradle). I would really like to help for anything on this list.
I may not be able to be much help for anything touching the dependency management... I don't quiet understand it at this point. As for the other feature, I could definitely give a hand. After using the NAR plugin, I could recommend some idea to implement some feature:
- The static library could possibly be done by adding a linker layer were you could control it by feeding command line argument to the linker directly and possibly choose the compiler and linker to use independently.
- The support for more compiler/easier to implement newer one could be done by having an idea of compiler/linker behavior that can be use/extend for a specific toolchain. For example, some embedded cross-compiler toolchain are using gcc with a different name (like arm-none-linux-gnueabi-gcc ). Been able to just specify the compiler behavior of gcc and changing the executable name that is use directly in the build.gradle file could definitely be really useful.
- The compled variant was probably well addressed in the NAR plugin with the AOL properties (Architecture, Os and Linker). The only problem that I found with this was the lack of flexibility in order to modify them through your build script... but that could be address and changed :-)
- The support for C and any other language could be added by adding some logic to configure a C, C++, ASM, D, etc environment within the gradle script. Again, the NAR plugin address this by having "high level" configuration that gets resolve into command line argument behind the scene for each native language (they support C, C++ and Fortran). It's also a good way to have cross-platform build script.
I'm sorry if I do a lot of comparison with the NAR plugin, but that was my first and only great experience with a modern approach for managing native project.
I'm pretty sure you have some though of your own on how to resolve and address the different features. I could be a good idea, like you say, to identify a strategy on how to implement these feature. Let me know how you want to tackle all these.
|Free forum by Nabble||Edit this page|