On 07/03/2012, at 10:08 PM, Ric Klaren wrote:
> 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.
I like this idea. We could even push that further and offer a task that will
run yum/aptget for the appropriate packages that your project need. Or even set
up a dev install of these dependencies.
>
> Would system installed libraries have to be modelled as a repository ?
My initial plan was this:
We'd add a systemLibraries() repository type, which would implement some kind
of system-specific way to locate native dependencies. You'd then declare system
dependencies in the same way as regular dependencies.
If you have dependencies that are sometimes installed and sometimes not, you'd
just declare 2 repositories:
repositories {
systemLibraries()
ivy { url 'some-repo' }
}
This way, we'd look first in the system specific location, and then in the
remote repository if not installed.
Over time, we might add yum and apt repository types, which extend the system
libraries type to auto-install the dependencies.
The fact that a library is installed or not would travel in the meta-data for
the library, so that the c++ plugin would use the appropriate -L/-l options
when linking against an installed dependency. The 'install<executable>' task
would also take this into account, and not bother copying libraries that are
already installed.
What is nice about treating system dependencies the same as regular
dependencies is that these dependencies are included in the published meta-data
for the project, and be used in other projects that depend on it. And later,
things such as IDE integration and plugins that build installers and rpms and
so on can take this information into account.
One thing to note here is that we want to add the idea of 'requested' vs
'actual' dependencies as a generic concept to our dependency management. What
this means is this: say you declare a dependency on 'zlib:1.2.+' and you have
1.2.6 installed. Gradle will resolve '1.2.+' to '1.2.6', and make this version
available to the build when compiling, linking, testing, etc. It will also
include both of these versions in the published meta-data (i.e. 'this project
should work with 1.2+ of zlib, but I actually built and tested it with 1.2.6').
You will be able to make use of this during dependency resolution in dependent
projects. You might be able to request things like: use exactly the same
version of zlib that my dependencies were tested against, or use the 'best'
version of zlib that is compatible with my dependencies, and so on.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
