Roundtable integration

Prolint and Roundtable are integrated in several ways:

  1. Populate the "select files to lint" dialog with sourcefiles from the current RTB task
  2. Custom menu-items and button on the Roundtable Tabletop enable you to easily invoke Prolint.
  3. Prolint can validate sourcefiles before they are checked-in, and disallow check-in if the sourcefile contains specific lint warnings

Notes:

The sourcefiles where the integration is implemented are located in directory "prolint/roundtable" with subdirs for each different Roundtable version

dialog "Select files to lint"

This dialog contains a button "RTB task", which is only visible if the Roundtable database is connected. When you choose this button, the browse widget
will be populated with all the objects in your currently selected Roundtable-task.

(finding those objects is implemented in source prolint/roundtable/x/taskfiles.p)

Menu-items and button on Roundtable Tabletop

Three new menu-items have been added to the "Tool"-menu in Roundtable:

  1. "Prolint selected object": launches Prolint and have it analyze the currently selected object
  2. "Prolint selected task": launches Prolint and analyze all the objects in the currently selected task
  3. "Configure Prolint": launches the Prolint Configuration window so you can adjust settings before you analyze any sourcefiles

A new button is added to the Tabletop, next to the "Visual Diff" button. This new button behaves similar to menu-item "Prolint selected object".

These buttons and menu-options invoke Prolint using a profile named "roundtable run".
Except when the Roundtable Check-in Validation feature is also enabled, because then it will invoke Prolint using the "roundtable check-in" profile.

For this to work, you need to customize the event handler in Roundtable. This is easy, but the procedure is different depending on which Roundtable version you are using.

When you are using Roundtable 9.1a or 9.1b or 9.1c then go to the Roundtable directory, find sourcefile rtb_evnt.p and add this single line to it:

   {prolint/roundtable/91c/custom_evnt.i}

When you are using Roundtable 10.1b then go to the Roundtable directory, find sourcefile rtb_events.p and add this line to it:

   {prolint/roundtable/101b/custom_events.i}

Please see prolint/roundtable/custom for working samples of modified rtb_events.p.

Roundtable Check-in Validation

This powerfull feature allows you to enforce that objects meet specific standards, implemented in Prolint rules.
If the feature is enabled, Prolint will validate objects whenever they are checked-in, and will abort the check-in process if specific warnings are discovered.

More information about this feature on page Roundtable Check-in Validation


Roundtable Check-in Validation

Each time you want to check-in an object, or when you want to complete a task,
Prolint will validate the objects.
When Prolint finds errors (not just warnings) it will tell Roundtable to abort the operation.
Errors must be fixed before the object can be checked-in. This way you can enforce that objects conform to specific standards.

Not every Prolint warning is an error. You can define in much detail which Prolint warnings will be upgraded to errors.


These definitions can be different for each workspace, if you want.

When the object you want to check in is an includefile, Prolint will randomly select three objects that depend on this includefile and lint them instead. The number of includefiles (default 3) can also be configured.
Read more on setup and configuration.

When Prolint finds errors, it will show the following message box:


All errors and warnings are displayed in the regular Prolint Results Window. Errors can be recognized because their descriptions begin with "ERROR: ". You can easily sort by description, or even filter:


The "Filter" dialog has a toggle-box to easily set and clear the filter:



Upgrading to Prolint 71: repair Roundtable integration

When you upgrade to Prolint 71 from an older Prolint release and you were already using the Roundtable integration, then you will experience errors until you make the following fix:

Locate in your Roundtable directory the compiled file "rtb_evnt.r" and delete it.

Locate in your Roundtable directory the sourcefile "rtb_evnt.p" and open it in your editor.
Find the line where prolint/rtb/custom_evnt.i is included:

   {prolint/rtb/custom_evnt.i}

and change it to

   {prolint/roundtable/91c/custom_evnt.i}

Optionally compile+save rtb_evnt.p.
That's all, you are ready now.

You may have noticed that directory "prolint/rtb" has been deleted and replaced by a new directory "prolint/roundtable" with subdirectories for several Roundtable versions.
"91c" should probably work for Roundtable versions 9.1a to 9.1c.
"101b" is made for Roundtable 10.1b and may work for other Roundtable versions too.


Configuration of Roundtable Check-in Validation

Validation is disabled by default

To enable validation, create a directory "prolint/custom/rtb-check-in" and then copy file "prolint/roundtable/version/prolint-rtb-check-in.ini" to "prolint/custom/rtb-check-in/default.ini".


The ini file contains several tuning options for the validation.

The validation will read the options in file "prolint/custom/rtb-check-in/default.ini".

If a specific workspace requires specific validation options, you can also create a specific ini-file. For example: for workspace "MAINT" you can create a file named "prolint/custom/rtb-check-in/ws-MAINT.ini" (that is "ws-" + wspace-id + ".ini").

Fine-tuning the validation

Prolint runs every rule specified in profile "roundtable check-in". But not every warning from these rules should be an "error"; only errors will abort the Roundtable check-in procedure.
So you will have to define errors, and that is what file prolint-rtb-check-in.ini is for.

Includefiles versus CompilationUnits

When you want to check-in an includefile, Prolint will randomly select 3 compilation units (using the "where-used" XREF stored in Roundtable) and lint those instead. In this case, Prolint will only upgrade warnings to errors if those warnings are found in the includefile.
Other warnings from the selected compilation units will simply be skipped.

When you want to check-in a compilation unit, and Prolint discovers warnings in includefiles used by that compilation unit,
Prolint may or may not upgrade those warnings to errors based on settings in the following sections.
Warnings from the compilation unit will simply be upgraded to errors, unless the rule is not listed in section [error-rules].

section [error-rules]

[error-rules]
compiler=all
strattrib=all
substitute=module,my
noundo=module,my
varusage=module,my
ifindent1=module,my
dotcomment=module,my
noeffect=module,my

The first section, [error-rules] contains a list of rules. These are the rules whose warnings can be upgraded to errors. If profile "roundtable check-in" contains more rules they will run, but their warnings will just be warnings.

Prolint treats includefiles different from compilation units. After all, the programmer who is working on a compilation unit might not be responsible for the includefiles, and blocking errors from includefiles is counter-productive so you may want to tune that.


Each rule in the section can have attributes: "all", "module", "my" or any combination of these three. These attributes affect how warnings from includefiles are treated.

If attribute "all" is set, warnings from any includefile will be raised to errors.


"module" : warnings from an includefile will not be raised to errors, if the includefile is not located in the same module as the object you are about to check-in.


"my": warnings from an includefile will not be raised to errors, unless you "own" the includefile.


"module,my" : the includefile will cause an error if it is located in the current module OR if you "own" the includefile.

So when do you "own" an includefile? This is determined in the remaining sections.

section [behaviour]

[behaviour]
number-where-used=3
my-inc=programmer,manager,compltd-by

If Prolint finds a warning in an includefile, and "my" is specified in section [error-rules], then we have to decide if you "own" the includefile. Prolint assumes you "own" the file when you have ever worked on it.
Prolint reads the tasks list from Roundtable, and checks in each task if you were the manager, or the programmer, or if you were the person who completed the task.

key "my-inc" can have any combination of "programmer", "manager" or "compltd-by". This specifies which task fields are evaluated.

section [wildcards:not-my-includes]

[wildcards:not-my-includes]
src/adm/*.i=jurjen,john
src/adm2/*.i=*

Lost ownership? Suppose you were involved with an includefile in the past, but are not responsible anymore...


This section can contain a list of wildcard patterns for filenames. Each wildcard has a CAN-DO like list of user-names.
If the includefile matches any of these patterns, and you match the userlist, you are assumed to not "own" the includefile.
This overrides the outcome of key "my-inc" in section [behaviour]

section [wildcards:my-includes]

[wildcards:my-includes]
sports/*.i=john,bill

Same idea, but this time the other way around: If the includefile matches any of these patterns, and you match the userlist, you are assumed to "own" the includefile.
This overrides the outcome of section [wildcards:not-my-includes]