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... -----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
