I general, this behavior (first definition overrides all others) is
the *correct* behavior for build infrastructures. In the case where there
are low-level buildfiles that are normally called by individual developers,
while a "meta" buildfile is at the top level normally called by the
build/release engineer. The top-level buildfile may define things to
ensure everything is done with a consistent set of tools, etc. and possibly
"publishes" the build to a standard location, while the lower-level
buildfiles
may have appropriate settings for developers.
There are times, however, when having the lower levels override the upper
is more appropriate, but they are far rarer than the more frequent case
discussed above. Hopefully ant2 will have some *explicit* method for
a lower level to override the upper levels, one that can be grepped for
so that the build engineer can catch it if someone overrides something they
shouldn't in a lower level buildfile.
See Peter D, I don't *always* "drone on" about the same things :-)
-Peter
> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 05, 2001 10:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: over-riding properties and the concept of scope
>
>
> On Thu, 5 Jul 2001, <[EMAIL PROTECTED]> wrote:
>
> > I have set up a project with some sub-projects that could be
> > stand-alone, but can also be a called from a "meta" build-file that
> > builds all sub-projects. If I have variables with the same name in
> > the main build-file they will over-ride the variable in the
> > sub-build-file.
>
> Yes, this has been identified as a problem of current Ant (one of
> many, to be honest). Ant2 will provide more control over which
> properties are going to be passed to the subbuild - and maybe we'll
> even have a backwards compatible solution for this problem in the Ant1
> series.
>
> > I find this to be counter-intuitive because it's exactly the
> > opposite of the way variable scope normally works-- normally "inner"
> > declarations override "outer" declarations.
>
> Consider properties to be constants, just that it doesn't cause an
> error when you try to change them.
>
> The main reason for the current precedence rules (first definition
> wins) was that properties specified on the command line should
> override any later definition IIRC.
>
> Stefan
>
