I've added a bunch of jira issues for some of the issues you've raised. Have a look here: http://issues.gradle.org/browse/GRADLE/component/10130
Feel free to add/comment on/vote for these issues. One thing to note is that we currently aren't planning to fix any of these issues for the Gradle 1.0 release (except maybe GRADLE-2151 and GRADLE-2118). On 08/03/2012, at 9:39 AM, Adam Murdoch wrote: > > 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 > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
