Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <57DC0292D622D411A62600D0B746D3EC2B57D1@email.arsin.com>
From: Peter Vogel <pvogel@arsin.com>
To: "'ant-dev@jakarta.apache.org'" <ant-dev@jakarta.apache.org>
Subject: RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
Date: Mon, 18 Dec 2000 16:53:43 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:JFernandez@viquity.com]
> Sent: Monday, December 18, 2000 4:14 PM
> To: 'ant-dev@jakarta.apache.org'
> Subject: RE: Whoa Bessie... Was -- Re: [Proposal] AntFarm
> 
> 
> > From: Peter Vogel [mailto:pvogel@arsin.com]
> > 
> > 
> > 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.
> > 
> 
> This sounds a lot like the right abstraction to look at XSLT (or CSS)
> for ANT. To see them as build configuration objects.
> The question is how they get associated with the build. 
>  - Is there a default configuration or user configuration object?
>  - Can one conbine their application to the same build?
>    User config file, OS config file, build-type config file, etc.
> 
> How does one specify in CONS what objects to use?

Typically, something like this:

cons BUILD=RelR1Eval

(Release, Region 1, Evaluation)

the variable $BUILD is used in the top-level "construct" file and,
potentially,
in the lower-level conscript files to determine which environment gets used.

Environments are instantiated as objects:

$RelR1Eval = new cons { <instance variables defined> }

$envs{RelR1Eval=>$RelR1Eval, ...}

-Peter