telplin
Usage
Installation and what a run does are covered on the start page. This page goes over the flags and the workflows around them.
Flags
Flag |
|
|---|---|
|
Process only these files of the project. A path can be given as is, or by the end of its path inside the project, so |
|
Print the signatures to the console and write nothing. The project is still verified. |
|
Also save the compiler arguments of the design time build next to the project, as a |
|
Save the compiler arguments as with |
|
Include private bindings in the signature file. |
|
Keep let bindings that no other file of this project uses. See below. |
|
Skip the check that the project still compiles with the new signatures in place. |
|
Do not list the signature files in the project file. |
|
Leave the |
|
Leave the XML doc comments in the implementation file. |
|
Write the signatures even when the check fails. For debugging purposes only. |
|
Print the version and exit. |
|
Display the help page and exit. |
Keeping only what is used
A signature file is more effective when it exposes only what the rest of the code base needs.
By default, a module-level let binding is left out of the signature when no other file of the project uses it, which makes it private. Types, members and bindings that carry an attribute (an entry point, a test, a literal) are always kept.
|
Be aware of what "used" means here: only this project is looked at. A binding used by another project, by a test project, through reflection, or by consumers of a published library is not seen, and would be made private. The default is for files that are internal to a project. For a public API, pass --keep-unused to keep every binding; --include-private-bindings implies it.
Response files
The design time build is the slow part of a run. --record saves its result as a .rsp file next to the project, and that file can be the input of later runs:
|
There is no project to update in that case, so the signature files have to be listed in the project by hand.