On Wed, 2011-07-13 at 11:04 +1000, Luke Daley wrote: [ . . . ] > > I see you have started a plugin for C and C++ support. I think this is > > a good move for Gradle. I am happy to volunteer to be an alpha tester. > > Consider yourself on notice then ;)
:-) > > Conversely the market leaders in the C, C++, LaTeX (and D, OCaml, > > Haskell, Chapel, Go, Fortran, etc.) are SCons, Waf and CMake (Make and > > Autotools exists but are really legacy systems) and their Java and > > Groovy support is weak. CMake is just a Makefile manager and probably > > has little to help. SCons and Waf however will have a lot to teach > > about C and C++ compilation and management. > > How would you suggest I start looking at these tools? 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 -- note I think D should be added to the list here, it is a language designed to be a sanitized and better C++ -- as C++ is a better C, but I only mean the positive aspects of that statement not the negative ones :-) > > The single biggest issue is that in Java and Groovy compilation you > > rarely track all of the build targets in the DAG -- anonymous classes, > > etc. create files you have no way of guessing the name of. C and C++ on > > the other hand generally have all generated files in the DAG, usually of > > necessity. > > This throws up some interesting challenges to the Gradle model as it's > not currently fine grained enough to handle this elegantly. But it > should/will be eventually because it's needed for other > incremental-in-nature tasks like archive building/copying. 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. 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. > > 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. > > What it does mean is that there is validity in having a build framework > > that correctly and well handles things both on the JVM and for native > > languages. > > Agreed entirely. Quite an exciting prospect. > > > It might be worth mentioning the crucial difference between SCons and > > Waf. SCons does all its checks everytime and is a Make replacement with > > the ability to do some Autoconf type things. Waf is a two phase > > (configure and build) system that is an Autotools replacement. > > 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, . . .) Without this there will be no traction, and without traction there will just be wasted effort. > I'm interested in your insights here. Obviously it's desirable, but I doubt > it's going to be practical without leveraging an existing specialised tool > for this. Not necessarily. It is all about having a good plugin initialization system. SCons and Waf both do this fairly well, though it can be a bit tortuous to override the algorithm of choice sometimes. Note the crucial difference here between SCons and Waf: SCons rechecks the information on every run, whereas Waf has a configuration phase which stores data on the filestore on the assumption it will be the same next time. > > The SCons project is in the middle of a (very slow) move to Mercurial > > and BitBucket. If you want to dig through the source possibly best to > > work with a clone of my Mercurial repository on BitBucket rather than > > trying to fight with Subversion. > > > > Waf is still a Subversion repository on GoogleCode but then bzr-svn, > > hgsubversion and git-svn are good for taking person Bazaar, Mercurial or > > Git (respectively) repositories from Subversion repositories. > > Thanks for the info. No problem. I only wish I had the resource to spend more time actually doing something on this. I have to say at the outset that needs of income generation will force me to focus on consulting, expert witness, Python training and GPars training. So I may appear all to often to be someone with something to say and yet who appears to do nothing. What is really needed to give the project serious momentum is to find an organization which needs to create mixed JVM/C/C++/D systems that wants to use Gradle and that can provide resource either by developer time or cash to contract developer time. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
