ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <jon.tir...@emm.com>
Subject RE: [PATCH] Dynamic target
Date Fri, 03 Nov 2000 02:24:10 GMT
Agreed.

This needs to be implemented in some kind of Ant++-engine. Which basically
uses the tasks of ant but with a different "kernel". It's an idea but it's
definitely quite a bit of a project...

-----Original Message-----
From: Jose Alberto Fernandez [mailto:JFernandez@viquity.com]
Sent: Thursday, November 02, 2000 6:19 PM
To: 'ant-dev@jakarta.apache.org'
Subject: RE: [PATCH] Dynamic target


Just for the record,

I am not proposing it again. I just wanted to make the point that for this
kind of feature you really need to design something much more solid than
just a hack here and there.

As for the "what you could do is provide a xslt/css/custom frontend that
transforms into ant file" mantra, I do not think one can just do it that
easy
without just reimplementing 80% of ANT in the process. Since you need to
understand
what is and what is not with respect to the particular parameters in the
input.

This is not what css/xslt/etc are all about.

Maybe I am wrong, but ...

Jose Alberto

> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Thursday, November 02, 2000 5:19 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: [PATCH] Dynamic target
>
>
> Hi,
>
> I would be completely and utterly -1 to implement
> patternmatching or any
> dynamic dependency tree building for that matter. If you want
> make then
> there is already jmk, jmak, jam etc. Ant is meant to be simple and
> intuitive. Alternatively what you could do is provide a
> xslt/css/custom
> frontend that transforms into ant file. Whatever the case
> this raises the
> stakes too much IMHO and thus is definetly yucky
>
>
> At 04:54  2/11/00 -0800, you wrote:
> >Yes! The ability to specify targets as a pattern is the proper
> >generalization/formalization of Jonas' proposal. And since
> make has had that
> >for a RLTN (Really Long Time Now ;) it's a pretty proven
> feature. That is an
> >extremely useful tool for build-system-generalization, and
> probably what I
> >miss most from make.
> >
> >So, was it a target-pattern war or anything? I'm pretty new
> to this list.
> >What was the reason for not having target-patterns? I'm
> extremely +1 for
> >target-patterns.
> >
> >Also:
> ><target match="*" property="dynamic.target" ....>
> >    ...
> ></target>
> >is not the implementation of what Jonas proposed, basically the
> >"dynamic.target" magic property of Jonas is the same as the $< magic
> >property of make.
> >
> >-----Original Message-----
> >From: Jose Alberto Fernandez [mailto:JFernandez@viquity.com]
> >Sent: Thursday, November 02, 2000 3:02 PM
> >To: 'ant-dev@jakarta.apache.org'
> >Subject: RE: [PATCH] Dynamic target
> >
> >
> >My concern here is how do you plan to dealt with multiple targets?
> >If I do:
> >
> >  ant unk1 unk2 unk3
> >
> >what Jonas proposed will not work since the property will
> only get one value
> >(not mutable).
> >
> >I do not have a solution for the problem either.
> >
> >How does this work if I have:
> >
> >  <target name="known1" depends="unknown2" />
> >
> >would the execution of known1 cause the execution of the
> dynamic target
> >corresponding to "unknown2"?.
> >
> >If this does not work, then I think we only have a cluge.
> Any solid solution
> >should work consistently independently of the situation.
> >
> >BTW, At some point I proposed having "template" targets.
> Something like:
> >
> >  <target match="unk*" property="prop.name"..... />
> >
> >which matches any target that starts with "unk". If we add
> to this some
> >rules about priorities based on how good the match is, we
> can get something
> >more general and better formulated than the dynamic target concept.
> >
> >In particular, the dynamic target is nothing else than:
> >
> >  <target match="*" property="dynamic.target" ....>
> >    ...
> >  </target>
> >
> >still there is the issue of what is the scope for "dynamic.target"
> >if the rule applies again in a dependence, what should happen?
> >Do we need a separate concept for keeping track of the
> actual target name?
> > "${}" could mean the actual name of the current target, which in the
> >case of a matching target means the actual value matched. So
> no "property"
> >attribute required.
> >
> >Opinions?
> >
> >Jose Alberto
> >
> >
> >
> >> -----Original Message-----
> >> From: Jon Tirsén [mailto:jon.tirsen@emm.com]
> >> Sent: Thursday, November 02, 2000 12:05 PM
> >> To: ant-dev@jakarta.apache.org
> >> Subject: SV: [PATCH] Dynamic target
> >>
> >>
> >> I'm not sure that the feature is 100% bad. I think that a
> >> feature of that
> >> kind in combination with the script-task would make much
> more complex
> >> behaviour in a build-system possible. It would for example be
> >> a very good
> >> tool for generalizing build-files to a higher degree.
> >>
> >> I do agree upon that the patch is to magic/implicit in it's current
> >> manifestation. But I do see the use of such a feature in a
> >> very advanced
> >> ant-build-implementation. (Such as my own. :-)
> >>
> >>
> >> -----Ursprungligt meddelande-----
> >> Från: Conor MacNeill [mailto:conor@m64.com]
> >> Skickat: den 2 november 2000 06:29
> >> Till: ant-dev@jakarta.apache.org
> >> Ämne: RE: [PATCH] Dynamic target
> >>
> >>
> >> Jonas,
> >>
> >> I agree with Stefan. This is too implicit for my liking.
> >> Specially named
> >> targets are not a good idea, IMHO. If you did want to have
> >> this sort of
> >> specific meaning, (and I question whether that is the
> case, anyway), I
> >> think it would require a different element name such as <dynamic>.
> >>
> >> So for now, I'm -1 on this patch.
> >>
> >> Conor
> >>
> >>
> >>
> >
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power."          |
> |       -Abraham Lincoln                               |
> *------------------------------------------------------*
>


Mime
View raw message