ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shankar Unni <shan...@intruvert.com>
Subject RE: over-riding properties and the concept of scope
Date Fri, 06 Jul 2001 16:51:14 GMT
Peter Donald [mailto:donaldp@apache.org] writes:

> On Fri,  6 Jul 2001 16:25, Stefan Bodewig wrote:
> >
> > I prefer a mechanism that allows the build engineer to specify which
> > properties may be overridden and which must not.  Making it 
> > impossible to override "something they shouldn't" is even better 
> > than having to grep for inappropriate usage every now and then IMHO.
> 
> This concept seems to align with the notion of "public" 
> properties (ie ones that can be accessed and set from another 
> project). 

Another angle on this is not that the lower-level buildfile is "overriding"
something forced from the top, but the concept of "default" values that are
suitable for most uses, while some uses may provide explicit values that are
different from the default or augment the default.

Like I pointed out in a previous message, this is typical for things like
include/class paths, defines, etc.

Now 90% of this could be done without clumsy overriding mechanisms, as long
as there is a mechanism to easily accumulate these things. For instance, in
the Make world, I would define (or rather, specify), say, three variables 

CFLAGS = $(GCFLAGS) $(LCFLAGS) $(VCFLAGS)

where the assumption is that a C compiler takes the last value of a
conflicting option (say). Then, GCFLAGS could be defined in a global
Makefile, LCFLAGS could be defined (or not, as needed) in the "local"
Makefile, and VCFLAGS would be passed in on the command line.

In the Ant world, it would be great to be able to specify something along
the lines of:

  <path id="global.path">
     <!-- path definition -->
  </path>

  <path id="project.class.path">
     <path idref="command.path" if-defined="command.path"/>  <!-- ?? -->
     <path idref="local.path" if-defined="command.path"/>
     <path idref="global.path"/>
  </path>

(or if one could specify that "path idref=xxx" would have no effect if the
id was not defined, or some variant thereof..)

Then, one could simply do a

  <javac .... classpathref="project.class.path" .../>

and get the fine level of control desired - only the buildmaster would
control the global path, but local build files could specify additional
paths to be searched, and individual users could temporarily override stuff
using a command line option -Dcommand.path=... 

--
Shankar Unni <newbie to ant, oldie to make :-/>.


Mime
View raw message