http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2743
*** shadow/2743 Mon Jul 23 09:30:32 2001 --- shadow/2743.tmp.7634 Mon Jul 23 09:30:32 2001 *************** *** 0 **** --- 1,59 ---- + +============================================================================+ + | More sophisticated dependency analysis | + +----------------------------------------------------------------------------+ + | Bug #: 2743 Product: Ant | + | Status: NEW Version: unspecified | + | Resolution: Platform: Other | + | Severity: Enhancement OS/Version: All | + | Priority: Other Component: Core | + +----------------------------------------------------------------------------+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + To the Ant team: + + When I read the documents for the Ant2 re-design, I remembered a Perl-based + make system named "cons", now at <http://www.dsmit.com/cons/>. Like Ant, cons + tries to be a better make. There are two design decisions or features that make + cons unique: + + 1) Cons never calls itself recursively, so it can process the whole dependency + tree in one pass. Actually, cons parses a hierarchy of declarative "Construct" + files and analyses the entire hierarchy before it starts building. This is MUCH + better than the usual make approach with make processes calling themselves + recursively, breaking the dependency chain every time. + + 2) Cons keeps hash keys (MD5 message digests, actually) of all dependencies and + targets it has seen and processed (including external influences like the + system environment and compiler flags), so it can detect very reliably if + anything has changed and needs a rebuild. + + Example #1: If you touch a source's modification date, that source will not be + considered as changed as long as the file contents don't change; if you change + a target, that target will be rebuilt if it doesn't fit to the current set of + dependencies. + + Example #2: You compile a subtree or a project with debugging enabled. When you + re-build the entire project (say, with optimization enabled), cons will re- + compile exactly these files that previously have not been compiled with + optimization enabled, because it records the set of command-line options used + for building each target. + + I have used cons for years in C/C++ building, and I haven't yet come across a + build system that is nearly as reliable. + + As it is, cons is not very well suited for Java applications. Cons follows a + strict dependency hierarchy, where a set of sources always leads to ONE result. + (Java dependency analysis is more difficult, and the class files that are + created during compilation are -- seen from the outside -- essentially random.) + + Anyway, it might be inspiring to look at cons' design from the perspective of + specifying Ant2. + + Best, + + Jochen
