ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vitaly Stulsky" <>
Subject RE: javac dependencies
Date Thu, 08 Jun 2000 11:38:25 GMT

Files: build.xml, build.xml.diff,, lib.jar
I didn't modify patch and also didn't check its compatibility with current version.
Be careful while applying it!

[Cut from the patch cover letter]
At glance.
1) Here is enclosed patch for the JavaC dependency tracking.
2) Also this patch allows using multiple source location in the JAVAC srcdir
3) Implemented new JAVAC option SOURCEPATH.

Full description
1) Dependency tracking.
   To switch on this feature you have to use dependence="on" JAVAC option.

   Algorithm performs class files analyzing and backward dependency tracking.
     a) depends on With applied patch if we change, ANT
     recompiles In current realization compile list contains only
     b) If we will change in the ant sources, current ant realization
     recompiles only one file. In new realization compile list contains >= 33
     (the number of files depends on your own Task extensions).

   For this functionality you have to modify It is necessary to
   lib.jar to the Class-path.

   In next few weeks I'll comment lib.jar source, make proper indentation and
   send sources to the community. Also it is possible to include lib.jar code
   to the ant.jar. If anybody wants to view the sources immediately I'll send
   them on first demand directly to he or she.

2) With applied patch it is possible to use such src dirs:
		<property   name="src.dir"
					value= "com/company/progr/mainprogr;
   All paths must be separated by semicolon ( I estimate Unix users indignation,
but now current
   approach easily extended to usage semicolon on NT platform and colon on

3) For every project it is necessary to specify sourcepath option. This option
will be passed
directly to javac. This functionality is follows from multiple src paths. Now
you can
specify not root of all packages in the srcdir option. Root dir has to be
specified in
sourcepath option.
For our project this functionality is very useful, cause we have many reusable
utilities and
want to distribute parts of them with different projects. All utilities classes
are stored
in one upper-level package For every project we have to
select from 3 to 10
lower-level packages and include them to the distribution. Approach with
multiple srcdirs makes
build file easiest and better understandable.

We'll be glad to answer all of your questions.

[End cut]
Files: diffs.txt

[Cut from Conor's patch cover letter]
Interestingly I have also been working on dependency tracking and multiple
source paths.

For multiple source paths, I submitted a patch for multiple source paths a
while back. I chose to use a comma to separate the source paths since it
seemed likely to offend the Windows folks and the Unix folks equally :-) The
patch was not applied because of the use of that comma. There was also some
desire to support elements instead of just an attribute, something like
    <srcdir name="xyz">
    <srcdir name="abc">

I have changed my approach now to use the more "forgiving" ways of
Project.translatePath. I have added a method to Project called
translatePathInternal. Whereas translatePath will translate a path to the
local platform conventions, this new method translates paths, whether
specified with ":/" or ";\", to a platform independent format based on ':'
and '/' but supporting DOS drive style paths (C:\...). This path can then be
tokenized on the ':' character to build the source paths vector. So you can
specify the path in either Windows or Unix style and it should work on
either platform. I'm not sure how other platforms react :-) I still haven't
added the element approach yet.

For dependency tracking I took a different approach from you. I separated
dependency analysis into a new task <depend>. The depend task builds a
dependency file by analysing the given set of class files (either a
directory or a jar). Javac uses the dependency file to determine which
classes are affected by classes being recompiled. In theory the dependency
file could be built in some other way but still be used by Javac. The
dependency format is pretty simple and could be changed easily.

Example usage
 <javac srcdir="${src1.dir}:${src2.dir};${src3.dir}"
 <depend src="${build.classes}" depfile="${build.dir}/depfile.txt" />

I also only follow direct relationships. Say you have a scenario of A
depends on B and B depends on C but A does not depend on C. If you change C,
my approach will only compile C and B but not A. My feeling is that if A
does not depend directly on C, changes to C cannot affect A through B. I'm
still thinking about that :-)

I can't really say which approach is better. I include my source code (and a
set of diffs) here to let people see an alternative approach.
[End cut]

Vitaly Stulsky
View raw message