Return-Path: 
 <ant-dev-return-13813-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 46495 invoked by uid 500); 16 May 2001 21:10:15 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 46365 invoked from network); 16 May 2001 21:10:02 -0000
Message-ID: <3B02ECB3.1B1EFB12@digitalfocus.com>
Date: Wed, 16 May 2001 17:10:11 -0400
From: Daniel Barclay <Daniel.Barclay@digitalfocus.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: depends list order? (was: [RESULT] multithrading)
References: <20010516161835.84471.qmail@web13406.mail.yahoo.com>
 <3B02C166.100BDC35@digitalfocus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

I wrote:
> 
> Diane Holt wrote:
> > ...
> > As to whether targets listed in the "depends" attribute should be executed
> > in the order of the list -- as long as we're allowing a list to be
> > specified, it'd be counter-intuitive (read: wrong :) to have it not do
> > that.
> 
> ...
> I don't think the order of a dependency list should be relevant (except
> possibly as a default, or as a way it happens to work on which you shouldn't
> rely).
> 
> If targets named in the list have some dependency, that dependency should
> be specified explicitly in those targets' dependencies.

Hmm.  I just ran into a case where order can't be specified by 
dependencies.

I want to be able to build some item without building any depended-on
items in addition to being able to build it normally, building 
depended-on items first.


That is, I want something like this:

  <!-- build module2 _with_ depended-on items: -->
  <target name="module2" depends="module1, module2.raw" >
  </target>

  <!-- build module2 _without_ depended-on items: -->
  <target name="module2.raw" >
    <whatever tasks to build module 2 here>
  </target>

Running "ant module2" would build module2 after building what it
depends on (module 1).

Running "ant module2.raw" would build module2 without checking or
processing depended-on items (module 1).


For target module2 to work reliably, its depended-on targets have to 
be processed in the order in which they are listed.  (Target module1 
must be processed before module2.raw.)  

I don't think that listing order should be significant, so the execution
order should be specified using dependencies between the targets that
need to execute in some order.

However, there is no way to specify the order as a dependency:  I can't 
make module2.raw depend on module1 to set the order, because I don't 
want module2.raw to depend on and execute module1.


The tasks to build module2 could be copied into target module2, like 
this:

  <target name="module2" depends="module1" >
    <whatever tasks to build module 2 here>
  </target>

  <target name="module2.raw" >
    <whatever tasks to build module 2 here>
  </target>

However, that results in duplicate code which obviously isn't good.


The common code could be factored out and called using antcall tasks:

  <target name="buildModule2" >
    <whatever tasks to build module 2 here>
  </target>

  <target name="module2" depends="module1" >
    <antcall target="buildModule2" >
  </target>

  <target name="module2.raw" >
    <antcall target="buildModule2" >
  </target>

(Actually, that could be simplified to this:

  <target name="module2.raw" >
    <whatever tasks to build module 2 here>
  </target>

  <target name="module2" depends="module1" >
    <antcall target="buildModule2" >
  </target>

)

However, that doesn't feel right either, because it hides the dependency
of module1 on module2.raw.


I don't think I'd want to try to suppress execution with if/unless.
(I wouldn't want to suppress module1 directly, because "ant module2.raw
module3" should build module1 if module3 depends on module1.  I'm not
sure what other suppression options might be possible, but it seems that
it might get pretty nasty.)


So what's the right way to have the option to suppress building depended-on
items?


Should the order in a depends attribute be significant?  What happens if
that order contradicts the order in another depends attribute?  What happens 
if that order contradicts an explicit dependency? 

Thanks,
Daniel
-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com