On 12/27/00 5:32 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I think we're on the same page here - Ant should read in all the project
> files in one phase, create the DAG, then run the build in another phase. I
> don't think this is how JDD's proposal works, however. Targets in
> subprojects don't get included in the main DAG. Instead, there's an
> "exec-target" task that runs after the build has started:
>
> <exec-target target="optional" module="optional/Module"/>
Right -=- as currently written the proposal goes that way. However, I'm
intrigued by this line of thought as it goes quite a bit further than just
"exec-target".
> The idea I've been pushing works something like this. Using the Cons
> examples, the main directory would have a file called "mysystem.ant" that
> looked like:
>
> <project name="mysystem">
> <import name="drivers"/>
> <import name="parsers"/>
> <import name="utilities"/>
> ...
> </project>
>
> Once a subproject is imported using the "import" statement, you can
> reference its targets in the "depends" attribute the way you would any
> other target. You just need to prefix it with the subproject name:
>
> <project name="mysystem">
> <import name="drivers"/>
> ...
> <target name="foo" depends="drivers:compile"> <!-- This target
> depends on the "compile" target in "drivers" -->
> ...
> </project>
>
> Since imports aren't tasks, but separate constructs, we can parse all of
> the subprojects at the same time we parse the main project. And as a result
> we can build the entire DAG before we start executing tasks...
Hmmm. Are your import names abstract names and the import actually looks
something like:
<import name="drivers" location="src/drivers/drivers.ant"/>
<import name="parsers" location="src/parsers/parsers.ant"/>
If you didn't have something like this, I think that you'd end up with
depends statements like:
<target name="foo" depends="src/parsers/parsers.ant:compile">
The explicitness of this is appealing, but it could get a bit too damn deep.
:)
Also -- I guess that you'd want to some how make upward references -- say
the drivers.ant file wants to state a dependancy upwards so that things can
happen correctly ala CONS. If everything was a .ant file, then you'd have to
explicitly declare these things. However, if naming conventions like the
current proposal were made, then an autoscan could be done.
Oh -- one thought about autoscanning up for the parent Workspace -- the
endless upwards spiral could be taken care of by placing a max-parent-ascend
variable into ant and it's configuration. Something like 5 or 10? That would
keep it from chasing things out of control, but still make things useful
from the autoscan point of view.
.duncan
--
James Duncan Davidson [EMAIL PROTECTED]
!try; do()
