Index: trunk/doc/user/06_features/hierarchic/index.html =================================================================== --- trunk/doc/user/06_features/hierarchic/index.html (revision 10258) +++ trunk/doc/user/06_features/hierarchic/index.html (revision 10259) @@ -314,19 +314,60 @@ turns off the search mechanism and searches right in the project global namespace; if the object is not found, it is created in the project global namespace. +

Expert: hlibrary

+

+The simpler usage discussed above, is also the self-containe usage: when +all sheets files of the hierarchy are placed in a single project directory +and all sheets are listed in the project file (as root and aux sheets). +A variation for large projects is placing all sheet files in a directory +tree and have a project file in the top directory, listing all sheets. +

+This setup is called self-contained because packing up the project starting +from its root directory results in a portable file that can be distributed. +After unpacking on a different system, all files are available and the project +can be compiled. This is because all symbols and devmaps are automatically +embedded in the sheet files, all project-specific configuration embedded in +the project file. +

+Another usa case of hierarchic pages is maintaining a library of child sheets; +for example in IC design it is common to have symbols for blocks like a xor gate +and then have the "few FET implementation" of that xor gate as a child sheet +in a library. The advantage is that different projects can share and reuse +the same child sheets. The drawback is that these child sheets are not copied +into the project directory and the project is not self-contained: the +library of child sheets need to be distributed alongside the project. +

+This option is supported by sch-rnd via path based child sheet references. +Reusable child sheets are placed in the so called hlibrary. This is very +similar to the symbol library, with the search paths configured in the +config node rc/hlibrary_search_paths. Each hlibrary path is a tree of +sheet files and directories on the file system. Child sheets from +sheet ref syms are addressed using the same cschem/child/name +attribute. During project compilation when the given sheet is not +found by name in the project file, sch-rnd announces this in the +message log and automatically searches the hlibrary path and picks the first +file with a matching name. The name is either in the form of "foo.rs" or +just "foo" (sch-rnd automatically macthes the .rs or .lht endings). +

+Sheets loaded this way are not added to the project file and are +listed as [E] (for external) sheets in the sheet selector. This is a clear +indication that the sheet is not listed in the project file and is automatically +loaded from the hlibrary for a hierarchic design. +

+The project properties dialog lists external sheets in a separate group +and the toggle button converts an external sheet into an aux sheet, adding +it to the project file sheet listing with its relative path to the project +file. This is useful only if the external sheet is coming from a project-local +hlibrary.

Expert: addressing sheets by path

-Not yet supported. (TODO) +

Expert: addressing sheets by uuid

Not yet supported. (TODO) -

Expert: hlibrary

-

-Not yet supported. (TODO) -

Expert: non-graphical sheets

Non-graphical sheets define object directly in the abstract model,