ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <>
Subject Re: Smarter Javac
Date Tue, 20 Nov 2001 18:12:23 GMT
[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
>>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.

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 



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message