Incremental build scratch pad
Book page: Submitted by erikh on Sat, 2006-04-29 17:51. Last updated on Mon, 2006-05-01 18:43.
This scratch pad for the Incremental builds main page. Like a Wikipedia discussion tab, this page accumlates notes for the design.
2006-4-29 erikh
Maybe pointing out the obvious, incremental builds of plain-old Java can be managed by comparing the timestamp on the source and compiled file only because the runtime JVM handles the integration.
Unless we have a viewer that can provide equivalent integration at runtime, DITA XML modules have to integrate at build time. That integration has to resolve:
Some potential issues with that approach:
A final thought - is the dependency map a subset of the merge map? That is, could the dependency map be the merge map with wireframe (as it were) topics? That might allow for convergence of tools, processes, and understanding.
2006-4-29 erikh
Maybe pointing out the obvious, incremental builds of plain-old Java can be managed by comparing the timestamp on the source and compiled file only because the runtime JVM handles the integration.
Unless we have a viewer that can provide equivalent integration at runtime, DITA XML modules have to integrate at build time. That integration has to resolve:
- Dependencies created by xrefs, conrefs, and links within the topic
- Dependencies imposed on a topic by topicrefs in the map (and, looking down the road to DITA 1.2, potentially by key definitions in the map)
Some potential issues with that approach:
- The developer has to understand both the DITA and Ant representation of the dependency relationships.
- We might get more efficiency if the dependency declaration could also store frequently-used text. For instance, if we store the titles of topics, we don't have to open a topic file to supply its title text to linking topics.
A final thought - is the dependency map a subset of the merge map? That is, could the dependency map be the merge map with wireframe (as it were) topics? That might allow for convergence of tools, processes, and understanding.
- Login to post comments
- 6103 reads
Search
Recent Content
- Forum for DITA Users
35 weeks ago - Publishing for DITA
5 years ago - Optimizing the DITA Authoring Experience — Online Course
5 years ago - Linking to another chunked topic
5 years ago - Advanced Reuse Strategies — Online Course
5 years ago - 2019 Content Management Strategies/DITA North America Conference
5 years ago
Subscribe
Navigation
Currently online: 3 guests and 0 users:
Build dependencies, intermediate files
Erik's proposal looks to be in a similar vein to the old "makedepend" thing that was popular in makefiles in the past: have a target which builds a target, which we then include to get the dependencies. Does anyone remember advantages and disadvantages of the approach? I'm thinking of read-only volumes messing up one's day, for instance.
We should assemble an exhaustive list of the dependencies that you get with a bare-bones DITA install, and see if they can be factored into categories. This might suggest whether it's best to let this be managed by XSLT or Java.
Someone also needs to convince me that the incremental build problem and the need to replace dita.list with something "better" are the same problem.