Previous Next Contents Index Doc Set Home


Controlling the Browser Database With .sbinit

26

This chapter describes how to work with source files whose database information is stored in multiple directories. As a default, the database is built in the current working directory and searches that database when you issue a query.

The information in this chapter pertains mainly to the use of the command line to complete tasks also available from within WorkShop. For more conceptual information on using source browsing, see the online help.

This chapter is organized into the following sections:

Basic Concepts

page 341

Command Reference

page 342

Basic Concepts

The text file, .sbinit, is used by the Source Browsing mode of WorkShop, the compilers, and sbtags to obtain control information about the Source Browsing database structure. Use .sbinit if you want to work with source files whose database information is stored in multiple directories.

The .sbinit file should be placed in the directory from which Source Browsing, the compilers, and sbtags are run. These tools look in the current working directory for the .sbinit file.

Moving the .sbinit File

The default is to look in the current working directory for the .sbinit file. To instruct WorkShop and the compiler to search for the .sbinit file in another directory:

   Set the environment variable SUNPRO_SB_INIT_FILE_NAME to /absolute/pathname/.sbinit.

File Commands

To use .sbinit commands, add the command to the file. The .sbinit file is limited to the following commands:

Command Reference

import

import /pathname to directory

Allows the Source Browsing mode of WorkShop to read databases in directories other than the current working directory. The import command enables you to retain separate databases for separate directories.

For example, you may want to set up administrative boundaries so that programmers working on Project A cannot write into directories for Project B and vice versa. In that case, Project A and Project B each need to maintain their own database, both of which can then be read but not written by programmers working on the other project.

In the following figure, the current working directory is /project/source1. The database in source2 is read by including either of these commands in the source1 .sbinit file:

import /project/source2

import ../source2

export

export prefix into path

Causes the compilers and sbtags to write database component files associated with source files to directories other than the current working directory used by the Source Browsing mode of WorkShop and the compiler.

Whenever the compiler processes a source file whose absolute path starts with prefix, the resulting browser database (.bd) file is stored in path/.sb.

The export command contains an implied import command of path, so that exported database components are automatically read by the Source Browsing mode of WorkShop.

The export command enables you to save disk space by placing database files associated with identical files, such as #include files from /usr/include, in a single database, while still retaining distinct databases for individual projects.

If your .sbinit files include multiple export commands, then you must arrange them from the most specific to the least specific. The compiler scans export commands in the same order that it encounters them in the .sbinit file.

In this figure, to place the .bd file and index file created for files from /usr/include in a .sb subdirectory in the sys subdirectory, the user included this export command in the .sbinit file for source1:

export /usr/include into /project/sys

If the configuration had included a source2 directory with a .sbinit file containing the same export command, then you would save disk space because you didn't create two identical database files. For the stdio.h files, the compiler would create a single database file for stdio.h in the sys subdirectory.

The .sbinit file contains an implied export / into . that instructs the compiler to put database files created for source files not explicitly mentioned by an export command in the current working directory. In the previous figure, the .bd files associated with a.cc and b.cc are placed in the .sb subdirectory in the source1 directory.

When you include the export command in the .sbinit file, an implied import command causes the specified database to be read. Based on the configuration in the previous figure, the database in the sys subdirectory, as well as the database in the source1 directory, is searched each time you issue a query.

As another example, the user included this export command in the .sbinit file for source1:

export /project/include into /project/include

This places the database files and index file created for files from /project/include in the .sb subdirectory in the /project/include subdirectory. An implied import command caused the database in /project/include to be read.

The database files are stored in a common subdirectory even though it located the include file in a nonstandard location. The export command saves disk space if the project includes multiple references from many different directories to the same include file.

replacepath

replacepath from_prefix to_prefix

This command specifies how to modify path names in the Source Browsing database.

In general, from-prefix corresponds to the automounter "mount point" (the path name where the automounter actually mounts the file system); and to-prefix corresponds to the automounter "trigger point" (the path name known and used by the developer).

There is considerable flexibility in how an automounter is used; the method can vary from host to host.

Path replacement rules are matched in the order that they are found and matching stops after a replacement is done.

The default replacepath command is used to strip away automounter artifacts:

replacepath /tmp_mnt

When used for this purpose, the command should be given as the mount point as the first argument and the trigger_point as the second argument.

automount-prefix

automount-prefix mount_point trigger_point

The automount-prefix command enables you to browse on a machine other than the one on which you compiled your program. This command is identical to the replacepath command except that automount-prefix path translations occur at compile time and are written into the database.

The automount-prefix command defines which automounter prefixes to remove from the source names stored in the database. The directory under which the automounter mounts the file systems is the mount_point; the trigger_point is the prefix you use to access the exported file system. The default is /.

The path translations from both commands (that is, automount_prefix and replacepath) are used to search for source files while browsing if the path in the database fails.

At first glance, this may not seem possible; the browser database that is created when you run the compiler contains the absolute path for each source file. If the absolute path is not uniform across machines, then WorkShop will not be able to display the source files when it responds to a query.

To get around this problem, you can do either of the following:

There is a default automount-prefix command that is used to strip away automounter artifacts:

automount-prefix /tmp_mnt /

The default rule is generated only if no automount-prefix commands are specified.

For more information on using the automounter, see the automount(1M) man page.

cleanup-delay

This command limits the time elapsed between rebuilding the index and the associated database garbage collection. The compilers automatically invoke sbcleanup if the limit is exceeded. The default value is 12 hours.



Previous Next Contents Index Doc Set Home