ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <>
Subject RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
Date Mon, 18 Dec 2000 21:02:45 GMT

> Agreed to a certain degree. I think both of our porposals 
> suffered a little
> from a lack of perception. Both were just next-generation ants with a
> different architecture. They did not challenge any 
> established ideas - they
> merely crystalized them. 
> Both the other proposals are from people outside of "ant-dev 
> core" and thus
> may have a different perspectives and may spot things that we 
> miss. I am
> especially interested in the "import" idea from AntFarm 
> because it would
> solve many of the issues that the ant-user list has complained about.

I wonder, how many of the current ant developers have looked at "other"
alternative build tools (by alternative, I mean non-"make" based) like
CONS, etc.?

Having spent the last 12 years with CM representing at least a part of
my responsibilities, and the last 6 with CM being my primary specialty,
I am surprised at the lack of "cross fertilization" of ideas and concepts
between build tools.  Ant has some great concepts (xml based build file, 
somewhat object-oriented and extensible) but is immature and pretty limited
in its ability to manage a LARGE codebase, especially where parts of the 
codebase are shared between projects, it's also pretty Java-focused.  CONS
is very powerful with the full expressive power of PERL, built-in and
dependency scanning, non-recursive build, etc. but is currently fairly C/C++
focused, though certainly less so than Ant is Java focused.  

So, in keeping with an earlier message regarding requirements vs. 
"how its done" proposals, let me weigh in on what I believe the 
requirements of *any* build system are:

Support for detailed dependency checking, including "non-traditional" 
dependencies such as which compiler is in use now vs. the last time 
a compile was done in the tree.   

Automatic dependency update and verification, that is, no "make depend" or

Support for building from anywhere in the tree, updating only what
is necessary to build at that level and below.

Support for multiple projects sharing code within a single tree.

Support for embedded information.  Every CM environment is different, and
a regular build process has different notification requirements from 
location to location, if this information can be maintained in common
with the build script(s) themselves, all the better.

Support for a "distribution" build that extracts only those derived objects,
etc. that are required for installation of the built components on a target
deployment system.

Support for automation by an external entity.  It should be possible to 
conduct an "unattended" build on a regular basis.  This *should* imply
a command-line interface.

Support for different build "configurations" -- the simplest example of this
is a debug vs. a release build, but there are others: in one example from my
past we had 24 different build configurations (Release/Debug, DVD Region
1/2/3/4/5/6, Eval/Paid). All should be buildable/distable within a single
tree (so
derived objects should be maintained in a separate location from the source,
While less of an issue for Java, target HW/OS differences may also be
considered a configuration differentiator, as might compiler or compiler

Support for integration into relevant IDEs (this could be subsumed by my
"automation by an external entity" req. but I felt it worth being explicit)
that is, the tool should support being integrated into the developer's
not the developer integrating into the tool's workflow.

Support for automated parsing of build logs -- it should be possible to
the location of any build errors that occur, where building for that
started and ended, and what errors occurred.  Obviously some support from 
compilers and other tools is to be expected here, but help from the build
is useful, for example, most tools exit with a non-zero return code if
went wrong -- the build tool should provide output indicating what it tried
do (flags, etc.) and the RC it got if it gets a non-zero return code.

Support for *any* tool to be called from the build.  For example, I like to 
include a "build number" in all derived objects, that build number is
embedded in a header file included as needed by other source files, but we
not like to check in 100's of revisions to a header file just to update a
number, so usually the header file contains a "placeholder" for the build
and that number is updated automatically by the build process in a
pre-preprocessing step usually done by a tool like perl/sed/whatever.

Support for both centralized and de-centralized (but non-recursive) build 
description files.  In a large project, having a single build description 
file implies a huge number of revisions to that one file, because a change
anywhere in the tree might require a change to the build description, it is
usually better to distribute the information about how to build a region of
a tree into that region of the tree.  That way information about a subtree
is local to that subtree.  This DOES NOT imply a recursive-style build (i.e.
the traditional "cd subdir; make" approach) only the localization of
implied by that.  At the same time, there is a huge need for some
(i.e supported build configurations, how to perform various common tasks
etc), etc.) to be centralized for ease of maintenance of the whole tree.
done this many times taking advantage of GNUmake's "include" directive to
centralized variables and targets, while individual makefiles just provide
specifics, like what files to compile and what target to assemble) CONS does
real well with a top-level file that is always grabbed first (no matter
one invokes cons from within the tree) and sub-files incorporated as needed.

Support for building and exporting unit and integration test information
data, test benches, harnesses, etc.) 

Support for tools like code coverage analysis tools that have a "precompile"
component which generate data files that need to be harvested for the 
analysis phase later, etc.

Again, this is based on 12 years of doing CM for projects ranging from a 10K
lines of code to 2M lines of code with varying degrees of code sharing, and
the need to support 100s of developers, etc.  I've done my best to avoid 
describing any "hows" here, just "whats" but I'd be happy to discuss hows
anyone interested, based on my experience implementing many of the above
requirements with a variety of tools including Make (GNU), Perl (alone and
in conjuction with other tools), CONS (perl-based framework), and, to
a lesser extent, ANT.

Manager, Configuration Management
Arsin Corporation
4800 Great America Parkway, Suite 425, Santa Clara, CA 95054

View raw message