On 03/01/2013, at 3:15 AM, Russel Winder wrote: > On Wed, 2013-01-02 at 07:10 +1100, Adam Murdoch wrote: >> On 02/01/2013, at 1:41 AM, Russel Winder wrote: >> >>> I wonder if the C++ plugin should also deal with D and mixed D/C++/C >>> systems? >> >> At some point it might. We don't have any plans to do this at the >> moment. However, something we'd like to do is to rework the c++ >> plugins so that they don't assume that native executables and >> libraries must be built from C++ source files, and also to open up the >> compiler adapter API so that you can provide your own implementation. >> This way, someone could put together a D plugin, which hooks in D >> language support into the appropriate places. > > Mixing C, C++, Fortran and D in a single system has to be the goal if > Gradle is to make any headway in the native code arena.
Currently, we're aiming for something that looks like the Java side of things in Gradle, where you can take Java, Groovy or Scala source (or some mix) and build things that run on the JVM, and you can write plugins to add in support for other languages. So, for the native world, just swap "Java, Groovy and Scala" with "C and C++" and "run on the JVM" with "run natively". We haven't decided exactly which languages would be built-in to Gradle, other than C and C++. Maybe some others, maybe not. The remaining languages would be provided by community plugins. > Also mixed Java > and C/C++ systems, which is a use case for some SCons users, the Java > bit of which is handled badly by SCons. > > The current Gradle model is that there is source to be built and > "dependencies". Gradle basically implies that a dependency is a jar that > can be found in a repository somewhere. Strictly speaking, a dependency can be any type of artefact, not just a jar, and may or may not live in a repository. But certainly Gradle is still biased towards jar in a repository, making it easy to use a jar in a repo and less easy to use anything else. There are a few things we are working on to make this better: * Making the dependency management infrastructure more general, so that it makes fewer assumptions about things like compatibility and naming schemes and how artefacts are used. * Making dependency management more specific, so that Gradle understands how to deal with more specific types of artefacts. For example, understanding the platform naming scheme for native executables and libraries, switching on the execute bit for executables, understanding that header files need to be arranged in a specific hierarchy, not as individual files, and so on. * Improving the meta-data that is published to the repository so that it includes type specific meta-data. For a native library, this might include the platform, the compiler that was used, the debug options used, and so on. This would later be used for type specific dependency resolution, so that Gradle can make better decisions about which artefacts (if any) are compatible with whatever you're trying to build. * Removing more differences between things built locally and things downloaded from a repository so that they can be swapped for each other. In particular, this starts to deal with projects where different parts need to be built on different platforms. > SCons et al. treat dependency as > a relationship between an item of source and an item of created thing. > This latter view fails dismally for Java, Groovy and (especially) Scala > – also I suspect Kotlin and definitely Ceylon (*). It is though the > standard model for C, C++ and Fortran. D sits somewhere in between. > > Is there a way of adding a X.cpp → X.o → X type dependency as DAG > building (as per SCons, Waf, etc.) or does Gradle not really support > this style of build management? Not really. You could set this up if you want to, but Gradle generally models groups of source (source sets) which are compiled or transformed as a whole, at least from a logical point of view. The implementation of a given transformation may transform each file individually or as a whole or some combination. We do need to add better support for this to the up-to-date checks, as the checks assume that the implementations transform the files as a group. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
