Profiles

You don't always want to run every rule. A "profile" contains a specification of the rules you want to skip and which outputhandlers you want to use. You can create as many profiles as you want.

For example, you may want to create a profile named "indexes" that only uses rules "nowhere", "sortaccess" and "wholeindex" and writes its output to HTML and to a tab-delimited file. Or you may want to ue profile "Ed4Win" that writes its output to the build-window in ED for Windows.

Each subdirectory in "prolint/settings" is a profile. Each of those subdirectories contains a couple of ascii-files to define the characteristics of the profile.

Local profiles vs Shared profiles

Profiles in "prolint/settings" are considered to be "shared" profiles.

In addition to "prolint/settings" you can also create a directory "local-prolint/settings" anywhere in your propath. Each subdirectory in "local-prolint/settings" is also a profile, and these are considered to be "local" profiles.


you can achieve two different goals with local profiles:

  1. Specific profiles for different projects.

    Assuming you have different Progress products, each with their own working-dir or Propath, you can create a subdirectory "local-prolint/settings" in that Propath to override the default profiles in "prolint/settings".

  2. Personal profiles for each user.

    If Prolint is used in a larger development team, each individual programmer can create local profiles simply by creating a directory "local-prolint/settings" in their working-directories and avoid conflicts over shared profiles.

The list of profiles, available in a prolint-session, is merged from profiles in both "prolint/settings" and "local-prolint/settings".

A local profile overrides the shared profile, unless the shared profile contains a file named "no-local-settings.lk". The contents of this file is not important, but the existence of such a file notifies prolint that only the shared profile should be used and the local profile will be ignored.

for a GUI-window to modify the settings described here:

   run prolint/core/lintcfg.w("")                               

See page "lintcfg" for features of this window.

files you may find in a profile subdirectory:

file severity.d

specifies which rules to run and allows to customize severities.

inherits prolint/rules/rules.d

each line has two or three fields:

  1. required YES/NO

    if NO, the rule specified in field 2 will not be used by this profile.
  2. rule id
  3. custom severity

    this replaces the default severity.

    if this field is missing, prolint will just use the default severity

file handlers.d

specifies a list of outputhandlers to start for this profile.
these are programnames found in directory prolint/outputhandlers.

Prolint 'knows' for each outputhandler if it requires a specific Progress version or GUI/ChUI mode. It will not run the
outputhandlers that don't match the current Progress session. This means you can safely select "logwin" even if you
are running a ChUI session, because in that case Prolint will simply skip "logwin".

If file handlers.d is missing, or if the file is empty, or if it only contains outputhandlers that are not supported
in the current Progress session, then Prolint will terminate with an error message.

file nowarn.lst

Same purpose as putting {&_proparse_ prolint-nowarn(ruleid)} in source, but may be more convenient if the source is
maintained by someone else (like sources in adm2/src)

See example nowarn.lst for details.