10.12.1 Understanding the OmniHelp merge process
To merge files in one OmniHelp project with files in other OmniHelp projects, you must designate one of the projects to be the main project; the others are subprojects. The projects to be linked are merged at run time, when a user loads a project into a browser, or chooses a link that has a destination in another project. The merge process seamlessly integrates the contents of all subproj.oh* files from each subproject into those of the main project; the result is just as if main and subprojects had always been one project.
Each OmniHelp project involved in a merge must have a unique project name. You must provide instructions in the main-project configuration file for merging subproject files when OmniHelp is loaded into a browser.
The merge process includes each subproject’s merge data; as a result, other subprojects specified for merging into a given subproject are also integrated into the main project, allowing any degree of nesting of subprojects. However, OmniHelp does not support circular merging, where one subproject tries to merge another that has already been merged, or tries to merge the main project. Such anomalous merge attempts are ignored.
Main project must know about subprojects
The main project (and any subproject that includes other subprojects) must be aware of all existing and potential subprojects at the next level down, whether or not those subprojects are actually present when the main project is loaded into a browser. The name and title of each subproject must be listed in the main project’s configuration file (see §10.12.2 Listing and mapping OmniHelp subprojects), and each subproject must have an entry in the including project’s table of contents (see §10.12.3 Providing TOC placeholders for OmniHelp subprojects).
> 10 Generating OmniHelp > 10.12 Merging OmniHelp projects > 10.12.1 Understanding the OmniHelp merge process