Offering Help for Native Support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Offering Help for Native Support

Shad0w1nk
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. 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.

Thanks,

Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Offering Help for Native Support

Adam Murdoch

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

Reply | Threaded
Open this post in threaded view
|

Re: Offering Help for Native Support

Shad0w1nk
Hi Adam,

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.

Cheers,

Daniel