Getting More Granular Control

Getting More Granular Control

Creating your configurations based on the Getting Started files may be fine for a while, but then you decide that you don't really want the included authentication code or something else. Then you need more granular control of which features get included. In your config.m4 you will find an example of how to do this, but first you need to understand how the build system is built up.

The core of the build system is built on a basic structure. This structure structures seri.cfg the way professionals would do it and based on fundamentals in how SIP works (see next chapter for more details).  This basic structure is always enforced and can be found in the templates/*.m4 files.

Feature Packages and Features

The core system can include (for a specific run of the make command) one or more "feature packages". A "feature package" consists of many features, each of which has been tested and aligned with other features in the same package.  Normally you will want to include only one feature package at the time except where documentation shows that features across feature packages are compatible.

The SERi - Getting Started configuration files is an example of a feature package. Each of the features you find in those files have all been tested with each other and you are guaranteed that they work together. The configure script asks you a lot of questions and for each feature you include, configure will create a macro that once defined will cause that feature to be included.  These macros are found in your local/default/config.m4 file and they are always in the same format: a two-letter prefix that identifies the feature package, an underscore, and then the name of the feature, example: GS_HANDLINGNAT.

This is the hierarchy:

feature package   |--- featureA
                  |--- featureB
                  |--- featureC