Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: domain of ddevienne@gmail.com
 designates 209.85.214.45 as permitted sender)
Received-SPF: pass (google.com: domain of ddevienne@gmail.com designates
 10.204.10.91 as permitted sender) client-ip=10.204.10.91;
MIME-Version: 1.0
In-Reply-To: 
 <CADLR5X+V2fP2Wx8n9kHTq9oNBBcyrqv6ptHaxVAaxeefn-3+8Q@mail.gmail.com>
References: 
 <CAFvvX=a6iURwebprsUYDhtwcmNdwwbgr=88yfAiXpSuCOKFBuQ@mail.gmail.com>
	<87obtc1l08.fsf@v35516.1blu.de>
	<4F39559A.80003@callenish.com>
	<87haytzeoi.fsf@v35516.1blu.de>
	<4F3AAFD1.9050508@callenish.com>
	<0034F824-F1B4-4893-B835-65DC6226B4F7@hibnet.org>
	<4F3D5D39.1000603@callenish.com>
	<E4F33356-4D08-4AD1-BB8B-CA4976961552@hibnet.org>
	<4F3D8BB9.3040301@callenish.com>
	<CAFCRh-_Qem83DK2s-hK9NaNc4gq6W+WhP2nXizie8H7eE6n7rA@mail.gmail.com>
	<4F3EA58E.7060200@callenish.com>
	<CADLR5X+V2fP2Wx8n9kHTq9oNBBcyrqv6ptHaxVAaxeefn-3+8Q@mail.gmail.com>
Date: Sun, 19 Feb 2012 22:26:47 +0100
Message-ID: 
 <CAFCRh-_nqzARck-fXiHnAwO+nEXmfkkDgDfDbMFXxDkP9epWXw@mail.gmail.com>
Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
From: Dominique Devienne <ddevienne@gmail.com>
To: Ant Developers List <dev@ant.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart <gscokart@gmail.com> wrote:
> For me, one feature for a 2,0 would be a different style of dependency
> tree that would allow better parallel execution (on the same machine,
> or why not on distributed machines).

Agreed. I was in fact thinking of this one as well when I wrote my
"integrated build generator/manipulator".

> I see the 'targets' being more declarative, becoming a state
> transition saying : I need this resources in that state, I will use
> this other resources (and I don't want the to change during my
> execution, and I will produce this other resources in that other
> state.

Yep, with the modulo that I see 'targets' in a fine-grained way, i.e.
you know the graph of actions to transition all input files/resources
and come up with the optimum way to achieve the stated goals given the
hardware resources (single cpu computer, multi-core computer, grid of
computers). That's basically Makefile territory in a way, and similar
to what Peter's <outofdate> does as well. Right now Ant's targets
typically deal with "macro" dependencies (build all .class file before
building all .jar ones), and not "micro" dependencies at the file
level, so the opportunities to do stuff in parallel are lessened IMHO.
One reason Ant doesn't care much about this kind of parallelism is
that Javac is fast-enough and cannot be distributed really, and it's
the compilation of native languages like C++ that benefit most from
those, and that's not Ant's territory in fact.

> The dependency tree would be an logical engine finding the shortest
> path to go to the desired state, using parallel/distributed processing
> when possible.
>
> That's what I miss with existing build system : I want to go as
> quickly as possible to a desired build state (from a current state).

Have you read the 4 part series about how Google does its builds?
Below's a link to part#4. --DD

http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org