A config file can incorporate one or more other files by means of the #include directive. Included files may themselves include other files, but only of the same basic configuration type (macro files include macro files, for example). (If you nest #include's too deeply, you will bump up against the system's limit on the number of simultaneously open files.)
Although #if-#endif's, #ifdef-#endifdef's, and #fix-#unfix's can span across included files (e.g., you could begin an #if in one file and close it with an #endif in another), it is not good practice to do so. In any case, an #if (or #ifdef) in one config file may not be #endif (or #endifdef) terminated in a subsequent config file of a different type.
The #include directive takes three forms, for example,
#include <alarms/security_alarms.cfg>where the file in the second example is found in the default config file directory =piktdir/lib/configs, and the third is located in the =piktdir/lib/configs/alarms directory.
You may name included config files anything you want--i.e., they don't have to end with the .cfg file extension--but the eight main config files must remain systems.cfg, defines.cfg, macros.cfg, alarms.cfg, alerts.cfg, programs.cfg, files.cfg, and objects.cfg, and these eight config files must reside in the =piktdir/lib/configs directory.
Macro substitutions do not apply to preprocessor directives, so the following (unfortunately) doesn't work:
#include "=contribdir/security_alarms.cfg"An active #fix directive does not apply to any include files. If you want to turn off comment stripping and macro expansion within an include file, you must employ #fix-#unfix within that include file.
Includes are especially useful for compartmentalizing across different systems administrators (where each has his/her own sub-config file), and across functions (e.g., security alarms in one file, network alarms in another), and for including files contributed by outsiders. Includes are also good for quarantining information about different operating systems (e.g., you could isolate Unix command macros for different operating systems in their own, separate include files).
You must take care, however, not to multiply your config files to the point where they become hard to manage. Also, for every include file, that's one more file open and close, relatively expensive operations in terms of time. If you find your piktc preprocessing unacceptably slow, you might consider scaling back on the modularization and reconsolidating your include files.
Refer to the Samples section for many more examples.
|prev page||1st page||next page|