On 13/07/2011, at 3:42 PM, Russel Winder wrote: > > Difficult. I have spent the last 10+ years following the whole build > scene, and I still don't know enough about the internals of all these > systems to advise properly. What I can say is that CMake and Autotools > focus on managing Make and so are probably so far adrift from Gradle as > to not have useful things to chip in. Rake is so Ruby oriented, SBT > Scala oriented, Leiningen Clojure oriented, etc. that it might be > difficult to extract useful data for C, C++, D, Fortran and LaTeX > builds. Which leaves SCons and Waf. Waf was originally a fork of SCons > but has evolved into something very different. Waf is very much an > Autotools replacement, it is about putting a 100k file into your project > to provide the build system for that project. It is very much a > download, build, test, install focused system. Waf has very much > simplified core internals compared to SCons. SCons started when Steven > Knight and others rewrite Cons (a Perl system in Python) since then it > has grown a little like topsy, and whilst it works very well, the core > internals are no in need of a revolutionary rewrite. The SCons approach > is though the best model for a Gradle C, C++, D tool
I think so too, and this is roughly where we're starting. > > The problem here is that with Java, Groovy etc. it is generally best to > just recompile everything. Certainly the dependency analysis in javac > and groovyc is fairly poor, not sure about scalac. > > SCons and Waf both scan all C, C++, Fortran(, and D just not yet) > sources in order to ascertain the relationship between code files and > header files. This is essential for these languages as teh compile > simply translated source to object and the object files have to be > tracked. To start with, we're approaching C/C++ compilation the same way as Java: Compile all the C/C++ source in a single task. If any of the inputs to this task change (source, headers, compiler, compiler options, etc), then all of the source is recompiled. Later, we will add incremental compilation, where only those source files whose inputs have changed will be recompiled. We'll also clean up stale output files, where the associated source file no longer exists (this is a nice advantage of the 'source set' approach over the 'action per source file' approach). > > SCons and Waf both use MD5 signatures not just timestamps for > determining whether a source file needs to be recompiled. This is > deemed a huge win, for the really big builds -- we are talking here of > massive systems taking 20-40 hours to build from scratch. Gradle's incremental build already uses MD5 signatures, not timestamps, so we're ok in this respect. > >>> This means parsing the files to determine the graph of >>> relationships. >> >> This will be challenging, but there are Java libraries around to do this >> that we can leverage when the time comes. > > I don't know of any tools other than compiler for doing scans, what Java > libraries are you thinking of here? SCons and Waf use text processing > for the scaning, which given they are Python systems is fairly > straightforward. In C and C++ you have to process #include in D and Go > it is import, in LaTeX it is \input or \include -- though LaTeX is > exceedingly complicated since it is a macro based notation with > expansion. There are quite a few places where a task might want to extract dependencies out of source files, and do its work on a subset of its source files based on this. It might be good for us to introduce some common infrastructure for these tasks, such as persistence of the dependency graph, cleaning up stale outputs, and so on. And maybe even some way to say from the command-line 'build this particular output file' or 'rebuild everything affected by this source file'. >> >> We don't exactly know how far Gradle is going to go in supporting >> portability like autotools. > > To be honest if Gradle is going to get into the C, C++, Fortran, D, Go, > LaTeX build arena then portability has to be a primary requirement. It > has to work, out of the box, on Ubuntu, Debian, Fedora, RHEL, SUSE, OS > X, Windows. It has to be able to detect and use according to a priority > list any and all of the compilers available on any one system (Intel, > Microsoft, GCC, Comeau, Digital Mars, . . .) To start with, we will support tooling portability, for those tools that Gradle knows about. This means that Gradle will take care of thing like whether the output file should be called 'mylib.dll' or 'libmylib.so', or what the debug switch is for msvc vs gcc. This default behaviour will, of course, be tweakable, and you'll be able to define your own compiler drivers. Our initial targets are windows and linux, using gcc and msvc to build C and C++ applications and libraries. Beyond that, we'll let the community drive the other stuff we should support. We probably won't support source portability, such as generating a config.h. But there's no reason we couldn't put a plugin together to do this at some point. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
