On 20 Jun 2014, at 10:54 pm, Russel Winder <rus...@winder.org.uk> wrote:
> 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. We should be able to deal with either of these approaches. Right now, the native plugins compile source to object files and then link them into a binary. However, we’ve tried to keep the assumptions about how stuff is built constrained to a single plugin or two. This means most of the infrastructure doesn’t care about how a particular binary is produced - only that it is. For example, the dependency management stuff doesn’t know or care whether a binary is compiled and linked as one step or two or 200 or none. Having said that, there would be some work involved in adding support for building a binary directly from source in a single step. -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
