On 22 Jun 2014, at 4:26 am, Michael Putters <michael.putt...@binarygenetics.com> wrote:
> Right now Gradle doesn't add all that much vs existing solutions, but I'm > hoping I'll eventually be able to easily deploy my dependencies in a Maven > repository and stop having everybody in a team build each library we use with > whatever build system they require (which is always a different one, > obviously). > > Of course it's trickier than with Java (due to all the variants of the same > library: architecture, operating system, debug/release, etc.), but even the > ability to just register pre-built native libraries as Maven artifacts would > do wonders… We’re working on full dependency management for native binaries. This will certainly include publishing and resolving binaries from a binary repository. > > -----Original Message----- > From: Steven Walters [mailto:kemu...@gmail.com] > Sent: Saturday, June 21, 2014 6:02 PM > To: dev@gradle.codehaus.org > Subject: Re: [gradle-dev] "Native Support" [was Google Test Support] > > On Fri, Jun 20, 2014 at 8:54 AM, Russel Winder <rus...@winder.org.uk> wrote: >> >> As for assembly language, no applications programmer should ever have >> to use it! > > Assembly always has a place, and that place more commonly appears in > maximizing speed/performance. > This is more frequent in applications that have a heavy mathematical > background/focus. > statistics/scientific analysis, and video/audio processing are some examples > of this. > >> >> Someone on the Gradle native code team needs to write a short article >> saying what Gradle beats Dub, SCons, Waf and CMake. If this argument >> cannot be made convincingly then Gradle will have no future in the >> wider world of native code build. From experience it is hard enough >> weaning people off Make, and introducing Python is a battle. I suspect >> introducing JVM is going to be an even bigger battle than introducing >> PVM. > > I say that Gradle's (initial?) target audience for the native code support is > not development teams that deal purely in native code. > It'll be harder to convince them away from what they've been used to for > years and it "works" enough for them. > That is more summarily, those teams don't have a pain point that needs > resolving. > > Instead Gradle's first goal should be targeting teams/"houses" that deal in a > mixture of jvm and non-jvm based languages. > In my opinion, this is because there isn't much in a good single solution for > dealing with the combination of all of them. > Often needing different build systems/frameworks to try and smudge together > some final result. > Or teams developing something in house to try and handle it more gracefully > (but then the maintenance!) > > E.g. at my work, we are a multi-language house from being heavy in both > PLM/PDM and CAD, so we're consistently dealing with all of Java, C, C++, and > C#. > Being able to use only a single build system to handle everything would be > such a blessing and simplification of the mess that is the current state of > things. > That is, it would solve the pain point we've had for a rather long time. > > Regards, > Steven > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
