Source config

What is source_config?

The "source_config" file is a tiny little configuration that should help us to deal with several repositories in OOo environment.

What's it good for?

In the current design, it contains two types of infomation:

• What are the repository names that belong to my "source tree"
• Which of the modules (subdirs of the listed repositories) should be built

What does it look like?

Is borrowed from the windows .ini format (also used elsewhere). It consists of section labels an key-value pairs:

[section]
key=value

To hold the required information in this use case, a source_config file could look like:

[repositories]
ooo=active
l10n=active
...

[modules]
sal=active
sfx2=active
...

or just like this:

 ; nothing

Where do i find it?

Although that file is defined as optional (see below), its expected location is beside the repository(s). e.g.

.
..
ooo/
source_config

This place is also referenced by the environment variable SOURCE_ROOT_DIR.

In some cases it makes sense to do a rather generic lookup instead of using the source_config file pointed to by SOURCE_ROOT_DIR. In these cases the lookup follows these steps:

• determine module root based on the current directory - or fail
• assume the directory above the module root to be a repository - or fail if it isn't and repository functionality is required
• expect source_config beside that assumed "repository" - or go with the defaults of no source_config

More details

Currently there are only two sections defined: "repositories" and "modules". Implementations shouldn't care about sections they don't know.

In "repositories" the key reflects the directory name of the repository to use and the value "active" is the only allowed. If you don't want a repository to be active, remove its entry. No key or no section at all is read as "there is not other repository beside me".

In "modules" the key reflects the directory name of the activated module. The only allowed value is "active" and no key or no section means "all modules are active".

If there is no module defined in the module section, all modules will be built.

As there are different flavors of this format, here some details that should help to keep the implementation simple and compatible:

• no fancy chars in section, key or value ([a-zA-Z0-9] is a good idea...)
• blanks are not allowed in section and key names
• each section and each key in a section _must_ be unique
• ';' and '#' at the begin of a line indicate a comment