Posted by
Ross Berteig on
URL: http://elua-development.15.s1.nabble.com/Mixed-arm-and-thumb-code-tp2537643p2559847.html
Sometime on 3/28/2009, Mike Panetta wrote:
>Actually now that I think of it, are there really any build
>tools out there
>other then scons and derivatives that *don't* use make at some
>point?? I
>can't think of any off hand, but most of the software I build
>is either
>something I manage so uses make or a make manager, or foss/gnu
>type software
>which mostly uses autoconf....
Ant, the build system that seems to be preferred by the Java
crowd, is completely unlike Make, and does not use make on the
back end, unless extended with a custom build step that invokes
make. It takes a whole-project view of the build, and IMHO
doesn't mix well with the notion of building just this subtree
of a project. On the other hand, the whole Java language design
choice of storing source files in directory paths named after
their fully-qualified class names is so hostile to that kind of
development that you (or at least me, coming from a lot of
background with make on more platforms than I want to count)
don't even notice that lack as you fight all the other barriers
that development in Java seems to throw your way.
I'm reasonably sure that attempting to get make to drive the
build of a serious Java project would drive anyone around the bend.
Getting Ant to build "foreign" language (i.e. some C files
implementing a few JNI classes) sources was surprisingly easy,
unlike my attempts to do real work that needed "custom" (meaning
non-standard) build steps in most IDEs. In some ways it was
easier to get Ant to build them than it was to use the C code
from the Java application. But that is part of a rant about Java
that is even further off topic than this discussion of build
systems ;-)
There is even NAnt, which is a port of Ant to the .NET universe.
One of the barriers to getting started with Ant that I noticed
was its use of the full expressive power of XML to describe the
build. For me, all that XML punctuation really gets in the way
of what all boils down to wanting to describe the dependency
graph, decorated by build instructions.
I've always felt that make does that part really well, with a
minimum of extraneous punctuation.
Getting slightly closer to the list's topic, my only exposure to
scons was not positive: for reasons that made sense at the time
I needed to build VLC from sources on Solaris. Not only were the
33 libraries a barmier (most of which needed patching, and all
needed building on the target platform) but the final straw was
tripping over one that needed scons to build, which meant
finding a working Python for Solaris, and learning scons to fix
the inevitable platform-specific build issues. By that point,
the return on the investment became negative, and we abandoned
the whole idea.
I have to agree with Mike's general message that a good build
system really has to work out-of-the-box for distribution with a
portable project. Otherwise, getting it setup and working
becomes yet another barrier to adoption of the system.
Ross Berteig
[hidden email]
Cheshire Engineering Corp.
http://www.CheshireEng.com/_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev