Hi, On Tue, Mar 6, 2012 at 8:45 PM, Adam Murdoch <[email protected]>wrote:
> Which version of Gradle are you looking at? There are some improvements > that will be available in the soon-to-be-released 1.0-milestone-9. Have a > look at the release notes for some details: > http://wiki.gradle.org/display/GRADLE/Gradle+1.0-milestone-9+Release+Notes > I started looking at milestone 8, downloading the new milestone now. The release notes look promising already, I see many improvements :) So I was wondering what the current intended direction is of the native > support. > > Will multi platform builds and artifacts be supported ? > > > Definitely. You will be able to build and publish multiple variants of an > executable or a library. Initially, we'll probably start with some > pre-canned variants (debug vs non-debug, static vs dynamic, operating > system, architecture, compiler, etc). At some point, there will be some way > to define your own variants. > > The plugin will take care of whatever needs to happen to build each of the > variants you are interested in (e.g. compile once with -fPIC and once > without to build the shared and static variants on linux, just compile once > on windows). It will also take care of choosing the correct variant when > resolving dependencies. > Sounds promising! > Which platforms (and variants in general) do you need to build for? > In any case I'd need the C compiler as well as the C++ compiler. Platforms are windows 32 bit (Visual C/C++ compiler, I suspect 64 bit as well in the future), AIX 6.1 (IBM XL compiler), as far as my knowledge now extends it is a mix of static / dynamic libraries. Dependent on platform a different mix of static/shared linking may be used, nothing that should not be possible to do with gradle. > * I would really like a way to specify a dependency that would result in > -L<somedir> and some -l<sublib1> -l<sublib2> options for the compiler, I > can somewhat work around this by specifying arguments for the compiler, but > it would be nice if this was possible out of the box. (this might make my > migration path easier, I now have a number of do-everything builds that > result in more libraries) > > > Not sure what you mean here. Do you have an example? > I mean something like a 'system' dependency? E.g. on linux I'd prefer to use the system zlib so I get updates from the distribution (when linking dynamically). On windows I'd have to get this zlib from another location (a repository). For the windows case I'd just add a dependency and it would be pulled in by gradle. For the linux gcc case I need something that just adds -lz or a -static -lz depending on the wish for static stuff. Basically something like (with some pseudo ifs): cpp { sourceSets { main { if system is windows { dependency "zlib:zlib:1.2.5" } if system is linux { system-dependency zlib } } } } E.g. deal with the dependency where I expect to deal with dependencies. As opposed to fix it in the executables section like: executables { main { spec { if system is linux { args "-lz" } } } } The 'system' dependency could even do some system dependent sanity checks on the installed library and also shield you from the compiler/linker specifics for the adding of the -lz or whatever the platform linker needs. It might even suggest you run yum/aptget whatever. Would system installed libraries have to be modelled as a repository ? > * Will it be possible to include more shared/objects/static libraries in a > dependency? I tried to include boost for its test framework with a > simplistic 'boost-all' approach, e.g. header files and multiple shared > objects, but got hung up on the single shared object restriction. > > > Yes. The plan is to allow a published module to declare zero or more > artifacts of each type (headers, executable, static lib, shared lib, > exported symbol file, etc), plus a bunch of dependencies. When we resolve a > dependency, we would grab each of the artifacts of the appropriate type, > and do this transitively for its dependencies. > Great! Thank you for the answers. I'll go check out the milestone 9 snapshot. Cheers, Ric Lexmark International B.V., Gooimeer 12, 1411 DE Naarden, The Netherlands
