You create modules in the Project Management area of Klocwork Static Code Analysis.

1. If you're not already viewing the Projects list, click Projects at the top left.
2. Click your project in the list. The project details appear on the right.
3. Click Modules in the project details.
4. Click Create a new module.
5. Enter a name for your module, for example, My Tools.

   Module names cannot exceed 64 characters and cannot contain apostrophes (') or double quotes (").

6. If access control has been set up, you can control who can view source code in this module. Note that users must also have the "Access source files" permission for the project.
   • Allow all sets a generic rule allowing anyone to see source code in this module.
   • Deny all sets a generic rule preventing anyone from seeing source code in this module.
   • The Allow user field allows you to grant source code access to specific users.
   • The Deny user field allows you to deny source code access to specific users.

   For example, to allow only jsmith access to source code in a module, choose Deny all from the drop-down menu and enter jsmith in the Allow user field.

7. You can specify paths in one of two ways; by using tree selection or by specifying path patterns:
   • If you prefer to use tree selection, select the Use tree option. A file tree appears, where you can specifically select folders or files that you want to include as part of the module.
   • Alternatively, you can use path patterns. In the Path patterns field, enter an absolute file path or path pattern. This is the default behavior. Click add to add more file paths to this module.
   Tip:

   You can use asterisks as wildcards (necessary if the path to your source files changes from build to build). A single asterisk, for example */test or /test/*, performs a non-recursive search, meaning that matches will be limited to the current path level and will not include sub directories. When two asterisks are specified, for example **/test.c or /test/**, a recursive search is performed meaning that matches will occur in the current path and all sub-directories of the current path.

   Example 1

   Given the sample file path: /space/workspaces/cvs/ccvs.1.11.18/diff/diff.c

   The pattern:

       **/ccvs.1.11.18/diff/diff.c   
   

   returns a match, since the double-asterisk matches any number of paths (/space/workspaces/cvs in this case). Whereas the pattern:

   */ccvs.1.11.18/diff/diff.c
   

   does not return a match as * can only match a single file or directory.

   Example 2

   To match a specific file under the path: /space/workspaces/cvs/ccvs.1.11.18/ regardless of the minor version number, use the pattern:

   /space/workspaces/cvs/ccvs.1.11.*/diff/diff.c

   since the * matches the 18. Or, to match all files under the same path, use the pattern:

   /space/workspaces/cvs/ccvs.1.11.**

   Note: Path patterns and tree selection are not updated in real time. If you switch between the two selections, changes are not reflected until you save the module.
8. Use the tags field to add information that will be helpful for filtering the module list later.
9. Click Create to save your new module.

1. Click the Issues link for your new module.
2. You should see only issues from source files included in the module.

Precedence is established for module permissions rules as follows:

• User-specific rules take precedence over group rules.
• User-specific rules take precedence over the generic Deny all and Allow all rules.
• Group rules take precedence over the generic Deny all and Allow all rules.
• Deny rules take precedence over Allow rules.

To edit a module:

1. Click the edit icon to the left of the module in the modules list.
2. Edit fields as required, and click Save.

Only the module creator and those with permissions for the current project can edit a module.

Switching from path patterns to tree selection

When editing your module, if you have path patterns defined in a module and you switch to tree mode, the path patterns are applied to the tree. Once you save the changes, your previous path patterns are overwritten by the tree selections. This means that complex wildcard path patterns are not preserved.

For example, if you previously specified /space/a* as your path pattern and it contains /space/apath and /space/anotherpath, both of these paths are selected in your tree. However, when you save the module, /space/a* is not preserved, so future paths that fit this criteria are not included by default.

If you prefer this behavior, it may be best to stick with path patterns.