ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Lions, Import, and ProjectRef, oh my !
Date Thu, 14 Jun 2001 15:37:18 GMT
> From: Peter Donald []
> At 09:35 AM 6/14/01 +1000, Conor MacNeill wrote:
> >I see <import> as a execution time operation, so it would be
> implemented as
> >a task and have property expansion applied, even if I see
> that as having
> >dubious value.
> I am curious why you see it as a execution time feature. I
> see it in much
> the same way as I see imports in java. Thus I don't see it as
> execution
> time but post-parse, pre-execution time ;)

In other words, compilation time ;-)

With a more heavy role for types, libraries, task definitions, etc. There
seem to be natural to have some sort of "compilation" stage (or maybe it
should be called a "declaration" stage), which is more than just syntactic
parsing but it does not involve execution of targets.

If we were to crystalize such stage, I think I would agree with Peter that
<import>, <projectref> and other <type> declarations belong there.

If we do not, then Connor's model treats <import> consistently with other
things like the current <taskdef>. We do not want "arbitrarily" to have some
things being one way and others the other way, at the end that causes more
problems when people try to put the whole thing toguether. We need some
unified principle. (An example of the problem today is with the differences
on where <property> and things like <patternset> can be defined.

When you think about a "declaration" stage, then one should also think about
what is the actual role of <property> defined outside of <target>. In my
opinion, they are declaring constants which are global to the project. And
if you think of them that way, then they can perfectly be evaluated during
the declaration/compilation stage (as many other languages do). And , if
they are evaluated at that time, then they can perfectly be available to
<import>, <projectref>, <type>, etc. Declared after them.

This may also would help sort out whether arbitrary tasks should be allowed
outside of targets or not. Part of the confusion is the double role played
by those tasks that define things (<property>, <available>, <taskdef>, and
so on). Maybe they need to be segregated on a group of its own.

> >Lets discuss, without too much aggro hopefully, if, why and
> how one project
> >may control another that it references via a <projectref>.
> As a simple
> >scenario, lets say I want to change the value of a property,
> build.dir, in a
> >referenced project, so that I could combine a number of
> builds into one
> >build location. It seems a reasonable scenario to me. I
> think this will cut
> >across a number of issues including project to project
> control, scoping and
> >immutability of properties, etc.
> Well I don't see projectref as offering any control
> what-so-ever ;) Two
> reasons mainly;
> * I can not see any logical way of doing it (without causing
> anomalies,
> contradictions etc)
> * We can always do it via another mechanism
> The original reason for supporting the construct was for
> something like the
> following case
> Consider the Projects A, B, C and D. A depends apon B and C,
> B depends upon
> D and C depends on D. In Ant1 there is no real way of
> supporting this as
> the DAG is restricted to one project. In standard
> implementation project D
> would be built twice (once from B and once from C). You could hack it
> together by creating another project that ant-calls the
> projects in desired
> order but this quickly gets out of hand. X-project DAG would
> however make
> this trivial.

Before I address your questions below, can you show us what kind of syntax
you proposed to represent the example above. In particular, I would like to
understand how you envision B and C referring in their own buildfiles, to
the common D. As I understood <projectref> where associated with a name that
was local to the refering project.
This seem to require being able to express global relations

Jose Alberto

> Now lets say we allow properties to be set via projectref.
> How do we do it?
> We could scan the whole project tree (which would require all of them
> simultaneously loaded) and search for parameters to each build file.
> A few hard problems arise from this;
> * what if different projects set the same property but to
> different values?
> * what if projects set different properties that are incompatible?
> * how to we determine what values of the properties are passed
>   - are they the values at the time of first execution? which
> would cause
>     inconsistencies depending on if the project is run free
> standing or
>     because of proejectref. (ie one project may be passing
> uninitialized
>     properties because it hasn't run yet)
>   - do we synchronize all projects up to point where they
> call project?
>     (This would be an implementation nightmare and in some
> cases impossible).
>   - some other method?
> Theres other problems that arise but the above should give
> you an overview
> of the sorts of problems that this approach will lead to.
> Cheers,
> Pete
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*

View raw message