ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <>
Subject RE: PATCH: Attributes of Target can reference properties
Date Wed, 20 Jun 2001 16:59:09 GMT
> > Most people didn't have problems to expand properties for target's
> > attributes at parser time (that is, only properties that have been
> > defined at the same level as targets and be placed before 
> this target
> > would be expanded) - and this is what your patch does.  But this may
> > not be what people expect.  Given
> >
> > <target name="set">
> >   <property name="dep" value=", foo">
> > </target>
> >
> > <target name="bar" depends="set ${dep}">
> Wan't the recomended way of doing this something like
> <target name="bar" depends="dep1,dep2,dep3,dep4"/>
> <target name="dep1" depends="set" if="do.dep1"/>
> <target name="dep2" depends="set" if="do.dep2"/>
> <target name="dep3" depends="set" if="do.dep3"/>
> <target name="dep4" depends="set" if="do.dep4"/>
> <target name="set">
>    <property name="do.dep${depend}" value="true">
> </target>

Silly me, I thought one of the design aims of Ant was to keep
things SIMPLE and avoid kludgy constructs like Make forces
on people.  The monstrosity shown above seems to violate
that in a BIG way.  I'm hoping it is in response to Stefan's
example of multi-level resolution (which seems less valuable to
me w.r.t. building a standard build structure within a set of
projects, at least I have no need for it in Ant, in GnuMake I
built an "object-oriented" template structure that depended heavily
on GnuMake's per-target variable capability).

Anyway, should I resubmit the patch so that it only expands depend?
I agree run-time expansion of the other properties makes more sense
(though at the moment there is NO expansion of any property, so 
parse-time is better than no time).  To me, this sort of functionality is
critical to effective, large-scale (or even medium-scale) use of Ant.

It's bad enough that in order to hack-around the lack of a foreach I 
have to do this:

<target name="doall" depends="eobase, mbbase, 3pl, admin, monitor,
                             i2models, util, gtpd, tpp, smms" />

<target name="dist">
    <antcall target="doall">
        <param name="targ" value="dist"/>

<target name="build">
    <antcall target="doall">
        <param name="targ" value="build"/>

<target name="prototype">
    <antcall target="doall">
        <param name="targ" value="prototype"/>

At least this sort of thing I can "hide" in the standard build
so that the average user of the build doesn't have to know or deal with it,
what you suggest for dynamic dependency management is an ugly hack that
have to be used *in the project buildfile* and could not be hidden in the 
standard infrastructure.  I'm willing to commit a multitude of Make/Ant
"hacks" in an infrastructure file where I can comment the wazoo out of it
and know that it is appearing in only one place where a limited number of
people need to have an intimate understanding of the hack, I am *not*
to compromise the cleanliness and simplicity of subproject ant files...


View raw message