Return-Path: 
 <ant-dev-return-19940-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 99968 invoked from network); 20 Nov 2001 18:16:49 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 20 Nov 2001 18:16:49 -0000
Received: (qmail 23837 invoked by uid 97); 20 Nov 2001 18:16:49 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 23821 invoked by uid 97); 20 Nov 2001 18:16:48 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 23810 invoked from network); 20 Nov 2001 18:16:48 -0000
Message-ID: <3BFA9D07.2020006@arielpartners.com>
Date: Tue, 20 Nov 2001 13:12:23 -0500
From: "Craeg K. Strong" <cstrong@arielpartners.com>
Organization: Ariel Partners LLC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
X-Accept-Language: en-us
MIME-Version: 1.0
To: Ant Developers List <ant-dev@jakarta.apache.org>
Subject: Re: Smarter Javac
References: <20011120023712.16712.qmail@mailweb30.rediffmail.com>
 <200111201015.fAKAFpJ27175@mail008.syd.optusnet.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

[comments embedded below]

Peter Donald wrote:

>On Tue, 20 Nov 2001 13:37, Magesh Umasankar wrote:
>
>>>because for some reason you may always compile file X with debugging,
>>>while Y with no debugging. This does not mean you can't aggregate the
>>>files during compiler execution
>>>
>>>javac -g Bar.java Baz.java
>>>
>>How would a Javac task that takes in 2 compilers, one with debug turned on,
>>other turned off, depending upon file being used be setup in build.xml
>>for Ant 1.x or Ant2?  I mean, will current Javac attributes be set at the
>>fileset level?
>>
>It will be multiple tasks but that does not mean that the set of data on 
>which these tasks operate is
>a) constant over multiple builds
>b) non-overlapping
>
>The benefit I see of coloring is making it easier to use ant in large 
>systems. As ant doesn't yet integrate full dependency analysis in single step 
>there will always need to be developer awareness of issues such as
>* I turned debugging off - I need to recompile
>* I changed constant X in interface Y - I need to recompile
>
>Only fixing half the problem doesn't really gain us anything - it doesn't 
>make ant any more relevent for usage in large projects (because it doesn't do 
>full dependency checking) and for small projects it is still easier to use 
>jikes and do a full compile.
>
<2cents>

I believe that often the computational effort required to do full 
dependency checking
is larger than the effort required to do a full rebuild.    However, I 
am mostly concerned with
correctness.   For javac, that does not come up quite as often, b/c you 
generally do a full build
every time anyway.  For other tasks like <style> it is much more of an 
issue.   That is why I contributed
the "force" flag.   The idea is that you could define certain colorings, 
and if they changed,
set the "force" flag to recompile the whole thing again.

Note that this may be overkill, as Peter said-- the list of files may be 
different, etc.etc  but
because builds are so fast anyway, we found that all that we really 
wanted was a failsafe capability--
the ability to capture _anything_that_could_possibly_require_a_rebuild. 
  What you couldn't
capture using colorings, you can capture "manually" using <dependset>.   
Yes, it sucks that
you have to define your <dependset> by hand, rather than Ant 
automatically figuring out each
and every dependency, but at least it CAN be done.   That is why I 
believe colorings are a
logical and reasonable next step.  Colorings + Dependset = the 
possibility of guaranteed correctness.

I read a little about CONS, and I understand it does extremely 
sophisticated dependency analysis,
resulting in optimal rebuilds.    Speaking for myself, I would be happy 
with a much less sophisticated,
but _guaranteed_correct_ algorithm that errs on the side of correctness. 
  I think this is a winner
in the long run, as compilers get faster and ever more sophisticated 
themselves....

</2cents>

--Craeg


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