How to Host SEAL Modules In a Project

Overview

SEAL modules are shared libraries with a special entry point through which the module properties are advertised. They are registered to a location known to the plug-in manager to make them available at run-time. Follow these steps to make a SCRAM project able to host such modules:

We assume you are maintaining a SCRAM-based project. Other tools will presumably let you do something similar, but we cannot help you.

Add config/module.mk

Modules built in your project include this makefile fragment to get registered into a module database. Each project area has its own module database; the plug-in manager searches all databases in a path, preferring plug-ins defined earlier in the path over those later in it. In LCG projects the database is the directory lib/arch/modules, which should contain only plug-in module registrations and nothing else (note: not the modules themselves, just the registrations).

Copy config/module.mk from SEAL and adjust to your projects conventions. The things you might want to customise are:

Modifule config/Runtime

You need to change your project's global runtime environment to point the plug-in manager to your module database. Add the following definitions:

<Runtime name=SEAL_PLUGINS value="$(LOCALTOP)/$(SCRAM_ARCH)/lib/modules" type=path></Runtime>
<Runtime name=SEAL_PLUGINS value="$(LOCALTOP)/$(SCRAM_ARCH)/tests/lib/modules" type=path></Runtime>
<Runtime name=SEAL_PLUGINS value="$(RELEASETOP)/$(SCRAM_ARCH)/lib/modules" type=path></Runtime>
<Runtime name=SEAL_PLUGINS value="$(RELEASETOP)/$(SCRAM_ARCH)/tests/lib/modules" type=path></Runtime>

In short, you need to point to all the places in which there may be module databases in your project, including the local area and the base release area. It is safe to add directories that do not exist, they are ignored. However the directories added must contain only module registrations. The plug-in manager will automatically generate a cache; see required release build changes.

Do not add directories for other than your own project area. External tools, including other projects you use, should already define their own module databases.

Modify project tool definition in SCRAM toolbox

Add the locations from the previous point to the tool definition of your project. That way your clients will automatically pick up the module databases from your project. You will most likely want to drop the test-related directories and make them visible only within your own project.

Rebuild the module cache when making a release

The plug-in manager automatically caches the information it discovers about the plug-in modules in your project. The caching dramatically speeds up the program startup as it makes all the information available without having to load anything. Thus every project should update the cache just before freezing the release. The plug-in manager automatically updates the cache in every plug-in database directory that it can write to, and does so every time it scans a directory. It is sufficient to run any program that uses the plug-in manager to update the caches, such as SealPluginDump or SealPluginRefresh in SEAL. Just set $SEAL_PLUGINS environment variable correctly.

Note that the plug-in manager does not update the cache if any of the modules in the directory cannot be loaded properly. Make sure all the modules are actually valid before freezing your release. The debugging output (e.g. set LOG=stderr environment variable) tells you if any module is invalid. Normally you will notice simply because listing the plug-ins takes much longer than it should (it should be instantaneous).