On Thu, 2014-06-19 at 12:13 -0700, Daz DeBoer wrote:
[…]
> Yes, we're using the term 'native' as a not very good descriptor for the
> Gradle support for building applications in C, C++, Assembler, Objective-C,
> Objective-C++ and Windows Resources. Unfortunately, we haven't come up with
> a better term to describe this set of functionality
[…]
It all depends if the same infrastructure covers just them or all
languages resulting in native code!
> Can you elaborate a little on this? Is it the way the source code is built
> into a binary that is different, or the type of output that is created, or
> both? Where does Assembler fall into this mix?
Sorry, but… it depends.
So for example, with Chapel you always try to compile all the source
with a single compile command generating the executable directly without
generating any intermediate "semi-compiled" files. D is also compiled
in this way by preference. However D can also be compiled in the classic
C++ approach of compile each source file into an object file and then
link all the objects together to create the executable.
As for assembly language, no applications programmer should ever have to
use it!
> Do these other languages as a group follow a consistent pattern, or are
> they each fundamentally different from each other?
Well they are all fundamentally the same in that they generate native
code :-)
In the end it all depends how you are tracking compilation products. I
haven't yet tried the Gradle support for this as I am currently fighting
with Autotools (I thought I had left this behind years ago), and working
with Dub, SCons, Waf and (but only if I really, really have to) CMake.
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.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
