On 12/14/2012 02:47 AM, Russel Winder wrote:
> Hans Dockter and I were chatting at Groovy & Grails eXchange 2012
> yesterday, in particular about the coming C and C++ support in Gradle.
> It seems right for there to be a challenge SCons vs Gradle building C++
> code.
>
> Obviously SCons wins in the LaTeX, Fortran, D, etc. arena since Gradle
> has no capability there. Gradle clearly wins in the Java, Groovy, Scala,
> Kotlin, Ceylon space as SCons Java support is just, well let's be
> honest, not up to it – due to conflicts between the way Java is built
> and the SCons internal model which is C oriented.
I think if gradle does C/C++ support right, then its core functionality
should have everything required to support LaTeX, Fortran, D, and any
other system that basically generates a collection of output files from
a collection of input files with some dependency awareness. Writing
plugins (or whatever it would be) to support these systems should be
pretty easy. We should also be able to use gradle for ad hoc tasks like
building documents using custom code generators. I think these and
perhaps a few other examples should be on a list somewhere for things
that should become easy once C/C++ is fully baked. If they're not
already easy now, we should figure out why they're not easy and make
sure whatever those obstacles are are fully handled with C and C++
support. My guess is that they will be. I've used "make" to do these
kinds of things for years, and I don't think any of these problems have
anything fundamentally different from building C or C++.
That said, LaTeX is a little bit special because it often requires
multiple passes. My personal LaTeX support make code actually greps in
the log for the string "cross-references right" to see if it has to
rerun itself. There's also lots of side cases with lists of figures,
tables, etc., indexes, bibliographies, etc. I have personal make code
that I have used to build pretty complex LaTeX documents that include
lists of tables, lists of figures, tables of contents, and indexes (but
not bibliogrphies) along with the ability to specify other dependencies
(like maybe diagrams that have to be converted using xfig) and the
potential to have the file divided into multiple chunks each of which
may include common pieces. My code requires you to specify the
dependencies manually, but otherwise it handles all the hassle of
running latex multiple times until the results are stable. I haven't
used this recently, but it likely still works for many of the cases.
It's under 100 lines of make code. I'd be happy to contribute it.
> So the question is what is the most suitable challenge that we can
> arrange for say late 2013? (So that we can give results at Groovy &
> Grails eXchange 2013.)
>
I think it would be nice if the challenge included being able to build
some custom system with custom code generators that is not specified in
advance.
Also, something involving code generation has to be there. For example,
it would be great to have something that uses flex and bison but handles
using cached files if those tools are not available. I'll post more
about that. Also, whatever is build should span across multiple
directories without losing the ability to have fine-grained dependencies.
Disclaimer: I've read about scons and know what it is, but I've never
used it and don't know specifically what its capabilities are in this area.
--Jay
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
