ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
Date Mon, 18 Dec 2000 23:22:06 GMT
At 01:02  18/12/00 -0800, Peter Vogel wrote:
>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.?

Not me ;) I may have to go do a search on google when I get some time thou ;)

>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,

You realized that you may have just volunteered for brain picking ? ;)

>I am surprised at the lack of "cross fertilization" of ideas and concepts
>between build tools.  

lack of knowledge about each other I guess.

>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,

I am not sure if you mean LARGE or COMPLEX ;) I run/help setup quite a few
LARGEish projects. However they were relatively simple build processes that
don't deviate too much from traditional model. 

However ask Diane - there are a lot of things that make it difficult to
setup complex build environments. There is a little lack of control wrt
setting all execution values as many aren't fully exposed. (ie Javac and
extdirs with some compilers)

> especially where parts of the 
>codebase are shared between projects, 

Right - until I saw the AntFarm proposal I would have advocated monolithic
build files now I think I have changed my mind ;)

>it's also pretty Java-focused.  CONS
>is very powerful with the full expressive power of PERL, built-in and

you have to remember that Ant has deliberately sacraficed power in some
places to make it simple and easy to use. We still haven't found the exact
balance between power/ease/expressability but we try. Many of the things in
make (and I guess CONS ???) would never make it into ant as it is too complex.

>dependency scanning, non-recursive build, etc. but is currently fairly C/C++
>focused, though certainly less so than Ant is Java focused.  

The beuaty of ant is that it is all in the tasks. You want c/c++ tasks then
whip em up ;)

>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.   

Okay - I think these should be placed in tasks rather than in core.
Delicate spiderwebs of dependencies that make builds are unacceptable - I
much prefer simplity of if/unless + tasks to set properties.

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

agreed. Thou currently we rely fairly strongly on good compilers this is
not always a good thing - then there is Conors depends but I am not sure if
that will scale well to thousands/millions of files (especially when you
use inner/anonymous classes a lot).

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

Not sure I agree. I think I prefer AntFarms idea of small reusable project
files that depend on other projects is a better model. Directory sub-builds
is just make et als poor attempt to do the same. Make assumes that
sub-directories assume sub-components which is not always case especially
in some languages (ie java ;]).

>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.

I agree - essentially in Ant2.0 from what I understand the main build file
will be in the "ant" namespace and anyone can tack anything on in other

>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.

Thats a build pattern - not something that requires direct support in tool.
Just like most make/ant projects have usage and clean targets we should
establish conventions for "dist" targets.

>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

I think that will be possible by just changing values of properties at
start of build and running it (assumedly you would point it at different
destination directories). This will be possible with new proposals who are
fully interpreted thou it should be most possible with current ant aswell.

>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.

agreed. Most tools follow emacs conventions for error detections so we
should formalize on that.

>Support for *any* tool to be called from the build. 

anything that can be programmed via a task(let) - sure.

 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.

It is already possible with a little bit of javascript + replace task ;)

>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.  

Have a look at AntFarm as I think you will be pleasantly surprised ;)

>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.

What you are talking about here (templated build files) has been discussed.
While it is possible it is not something we will directly support (because
of added complexity). What I want to do is do templates via template file +
xslt --> build.xml. Not sure on viability yet.

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

just tasks. Something we already have now aswell ;)

>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.

some of that support just requires tasks and no direct support from ants
core. However there is need for small globs of "temporary" information. In
this case it would be useful to assign result data to ant-properties and
retrieve it in a later task. I have made that possible in myrmidon for this

>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.

The only thing you have to realize is that Ant is not meant to be a
cure-all it is waaaay to early in development to try to do that yet.
Simplicty and usability are key requirements unlike other build tools that
often require a make wizard/CM to understand.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message