exref

MODULE

exref

MODULE SUMMARY

Cross Reference Tool

DESCRIPTION

Note!
The exref tool has some limitations and is no longer supported. Please consider using the new cross reference tool xref.

The exref tool is an incremental cross reference server which builds a cross reference graph for all modules loaded into it. Information which can be derived from the cross reference graph includes use graphs and module dependencies. The call graph is represented as a directed graph (see digraph(3)). A function vertex is represented as:

      {{Mod, Fun, Arity}, {Type, File, Line}}

In this code:

      Type = local | exported | {exported, compiler} |
             {local, compiler} | {void(), record}

A call edge is represented as:

      {EdgeId, {Mod1, Fun1, Arity1}, {Mod2, Fun2, Arity2}, Line}.

EXPORTS

start()-> {ok, Pid} | {error, {already_started, Pid}}

Starts the exref server. The exref server must be started before any other functions in module exref can be used.

stop() -> stopped

Stops the exref server.

module(Module) -> true

This is a short form for calling module(Module,[search,verbose]) (see below).

module(Module, Options) -> true

Module = atom() | [atom()]

Options = [Option]

Loads the module Module into the cross reference graph. Module can also be a list of modules. Options is a list with the following possible options:

search: Searches for source file in code path and replaces the path X/ebin with the path X/src.
verbose: Creates an output of module names during loading.
auto: Automatically loads all referenced modules into the cross reference graph, with the exception of modules specified with the excludes/1 function. See also the no_libs option.
recursive: Recursively includes all files in a directory. See also the no_libs option.
warnings: Emits warnings about the application and the spawning of variables. The reason for this is that apply, with variable modules or functions, leads to an incomplete call graph. The apply call will be inserted into the call graph instead of the actual call. The same applies to spawn.
no_libs: Used together with the options auto and recursive, this options prevents modules in the standard libraries from being loaded into the cross reference graph.

directory(Directory)
directory(Directory, Options)

Loads all modules found in the directory Directory into the cross reference graph. Options are the same as for module/2. The function directory/1 is equivalent to directory(Directory,[verbose]).

directory_module(Directory, Module)
directory_module(Directory, Module, Options)

Loads the module Module located in the directory Directory. Module can also be a list of modules. Options are the same as for module/2. The function directory_module/2 is equivalent to directory_module(Directory,Module,[verbose]).

delete_module(Module)

Deletes the module Module from the cross reference graph. Module can also be a list of modules.

excludes(Modules)

Appends the modules of the Modules list to the list of modules which are excluded from the cross reference graph.

includes(Dirs)

Appends the directories of the Dirs list to the include search path for Erlang include files (see epp(3)).

defs(Defs)

Appends the definitions in the Defs list to the definition list used by epp (see epp(3)).

analyse(Type [,Arg]) -> Result

Performs various analyses of the cross reference graph and returns an Erlang term with a format that depends on the Type of analyse. Some analyse types can have an optional argument Arg. The result can be formatted to a textual printout with pretty/1. The available Type and Arg combinations are:

call

Emits the calls from the functions, for all functions in the graph.

call, Module

Emits the calls for all functions in the module Module,

call, Function

Emits the calls from the function Function, which has the format {Mod, Fun, Arity}.

use

Emits the use of functions, for all functions in the graph.

use, Module

Emits the use of functions, for all functions of the module Module.

use, Function

Emits the use of the function Function, which has the format {Mod, Fun, Arity}.

module_call

Emits the module dependency graph. For example, if module M1 has calls to M2, this analysis emits M1: M2 ...

module_use

Emits a module graph which is the reverse of the module dependency graph. For example, if module M1 is called by modules M2 and M3, the analysis emits M1: M2 M3.

exports_not_called

Reports all exported functions which are not used. This means that all entry points to a program can be found, also exported functions that should be local.

locals_not_called

Reports all local functions which are used. These functions can be removed without the program being affected.

undefined_functions

Reports all function calls which are calls to functions outside the cross reference graph. The library functions and Erlang BIFs are never considered undefined.

recursive_modules

Reports modules that are (partially) recursively defined, which means that they contain function calls outside the module which in turn call the functions in that module.

user_defined, {Mod, Fun}

Calls user-defined analysis. The reason for user-defined analysis being attached in this way is that the call graph cannot easily be copied to other processes. It should be performed within the exref server process.
The function definition must be as follows for user supplied analysis:

         my_analysis(G) ->
                 io:format("MY ANALYSIS ... ~n", Args),
                 ...

G is the cross reference graph as described above. The return value from a user-defined analysis is ignored.

pretty(AnalyseResult) -> ok

This function pretty-prints a verbose textual representation of AnalyseResult which must be the output from analyse(Type[,Arg]). The result from a user-defined analysis cannot be used as input to this function.

exref

MODULE

MODULE SUMMARY

DESCRIPTION

EXPORTS

See Also

AUTHORS