Hi,
On Wed, Mar 7, 2012 at 11:39 PM, Adam Murdoch
<[email protected]>wrote:
> On 07/03/2012, at 10:08 PM, Ric Klaren wrote:
>
> 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.
>
Nice stuff =)
> 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.
>
How would you deal with grabbing a dependency that normally would be from
system, but want from another repository because the system implementation
has known issues. Play with the groupId I guess? I suppose dependecies from
the system repository would get some 'system' group id ? So depending on
the platform you could tweak the dependencies...
> Over time, we might add yum and apt repository types, which extend the
> system libraries type to auto-install the dependencies.
>
Not sure if I'd like that.. yum installs would require root/sudo access
which might have issues in different environments, I'd be happy with issue
detection. Also it would not be of real help with windows (where you might
have to deal with visual c redistributables and such).
> 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.
>
Sounds good.
> 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.
>
Talking of installers is anything planned for MSI installers? (this is
currently the big slowdown in the build here)
> 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.
>
This information would also be available in project reports? So you can use
it for trouble shooting? Or more for reporting/tracking? Or for giving
warnings about this version is different as one that was used earlier in
the build?
Cheers,
Ric
Lexmark International B.V., Gooimeer 12, 1411 DE
Naarden, The Netherlands
