[comments embedded below]
Peter Donald wrote:
On Tue, 20 Nov 2001 13:37, Magesh Umasankar wrote:
It will be multiple tasks but that does not mean that the set of data on which these tasks operate isbecause 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?
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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
