ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
Date Mon, 18 Dec 2000 22:56:37 GMT
I agree Ken, I guess, to an extent, we have a disagreement w.r.t. what a
requirements  document is, I believe it defines WHAT the tool must or 
must not do, while a functional specification defines the functionality to 
be implemented to meet the requirements.  I was trying to be non-specific 
w.r.t. functionality.  Vague requirements (like the ones you mention) are 
there in the beginning until discussion (like this) nails them down a bit
tighter.  My intent in listing what I did was only to get people thinking 
about two things:

	1.  What do they *need* from the tool, not how does the tool
	    implement it.
	2.  What ideas can be stolen from other, more mature build tools.
          (i.e. CONS' use of MD5 checksums for dependency up-to-date checks)


Yes, ant can be said to support both of the requirements you list, and, in
the case of the "distribute" mechanism that's the way I've done it too, so
the requirement is there to imply the need for nothing to *preclude* that
sort of thing.


As for the separate .xml files fulfilling the requirement, yes, but at
what cost w.r.t. maintenance of the system?  If you have to update 24 .xml
files every time you do something to one -- OUCH!  Again, drawing from
CONS, which I like as a fairly mature "alternative" build tool, the 
"build configuration" is an object that "colors" everything the tool does
from there.  Any external command is executed w.r.t. a build configuration 
object, which object is in use depends on the logic of the conscript file,
but is usually determined by a command-line flag supplied when cons is 
invoked.  The configuration object determines values of environment
variables, compiler flags, compiler paths (i.e. the traditional CC
variable),
and the name of the sub directory into which derived objects should be
placed.

So, there is still only one place that a directory indicates what needs
to be built and how, but the specifics of that "how" is determined, at least
in part, by the build configuration object.  So, information that should
be local to a subtree remains local to the subtree, and information that 
is global to the build remains global to the build in the top-level
conscript
file.  Information is read recursively through the tree, but the build
itself
is non-recursive, so none of the problems described in the excellent 
"recursive make considered harmful" paper which others have referenced apply
to CONS.

-Peter

> -----Original Message-----
> From: Ken Wood [mailto:kwood@i2.com]
> Sent: Monday, December 18, 2000 1:47 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
> 
> 
> I'm gonna pick on a couple of items, not to be picky,
> but to illustrate what I mean by requirements
> documentation... especially since, at a high
> level, I believe I agree in concept with most
> of Peter's points....
> 
> Peter Vogel wrote:
> 
> > 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.
> > 
> 
> Using Ant 1.2, I created a 'distribute' target
> that uses mkdir, copy, chmod, renameext, and fixcrlf tasks to
> assemble a set of files (such as the jar files, html, etc) 
> to be used as input to InstallShield, and then used 'exec' 
> to run InstallShield to create the installer. So, Ant 1.2
> meets the requirement for distribution builds, at least for me....
> 
> So, my point is that I also want the requirements to
> be fairly well defined. That is, "support for a distribution build" is
> too vague. Does this mean a list of basic operations
> that, when combined, can be used to make a distribution?
> Or, does this mean that there is some way the build
> system knows what are derived objects vs source objects,
> and knows how to assemble them? We certainly can't get
> the design right if we don't get the requirements well
> defined...
> 
> > 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,
> > etc.)
> > While less of an issue for Java, target HW/OS differences 
> may also be
> > considered a configuration differentiator, as might 
> compiler or compiler
> > version).
> 
> What FUNCTIONALITY is required to do this? I can have a separate
> ".xml" file for each build configuration, and therefore I could
> claim Ant 1.2 meets this requirement. Also, I currently use
> the "if" and "unless" capabilities of targets to do NT specific things
> versus "unix'y" things with respect to builds or distribution.
> Again, if we go down the road of writing a good requirements 
> document, 
> it has to be focused and detailed. "Supports X" is too vague. 
> Which is why they are no fun to write compare to churning out code :^)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> 

Mime
View raw message