Compilation

Note

This page is still being written as per #1136.

The Tact compiler can produce various outputs, ranging from the BoC of the compiled contract to various supplementary files, such as the compilation report or the contract package, which is the JSON file with the .pkg extension that one can use to verify the smart contract’s origin.

With the proper configuration settings, you can customize the behavior of the compiler to skip the generation of some or all the build artifacts, and even control the addition or exclusion of getters for supported interfaces.

Since the Tact compiler is a command-line program, some of the configuration settings can be set directly. When inside a folder with a Tact-based project, such as one created using the Blueprint or from the tact-template, refer to the npx tact --help command for further instructions.

Build artifacts

A number of build artifacts can be produced per compilation of each contract. Some of the artifacts can be omitted using configuration settings.

The location of the artifacts depends on the output field of the tact.config.json. In [Blueprint][bp]-based projects, output is not used and all generated files are always placed in build/ProjectName/.

Compilation report, .md

Every markdown compilation report first features the name of the contract that it was prepared for and then the byte size of the contract compiled to BoC.

The following sub-headings describe the respective sections of the .md report.

Structures

Written as '# Types' prior to Tact 1.6

The first section introduces the present structures, i.e. some of the composite types, Structs and Messages that are declared or imported directly in the contract code, as well as those exposed from the Core standard library.

Along with the number of structures present, each of the Structs and Messages are described with their respective signatures and TL-B schemas, which include the message opcodes.

For example:

Total structures: 10

### StateInit
TL-B: `_ code:^cell data:^cell = StateInit`
Signature: `StateInit{code:^cell,data:^cell}`

### Deploy
TL-B: `deploy#946a98b6 queryId:uint64 = Deploy`
Signature: `Deploy{queryId:uint64}`

...etc.

TL-B schema of each Message contains its opcode, which is handy for looking up the auto-generated opcodes as well as confirming the manually provided ones. For example, the following Message declarations:

message GeneratedOpcode { }
message(0x12345678) ManuallySpecifiedOpcode { }

translate to their respective TL-B schemas:

### GeneratedOpcode
TL-B: `generated_opcode#6dfea180  = GeneratedOpcode`
Signature: `GeneratedOpcode{}`

### ManuallySpecifiedOpcode
TL-B: `manually_specified_opcode#12345678  = ManuallySpecifiedOpcode`
Signature: `ManuallySpecifiedOpcode{}`

where 6dfea180 and 12345678 specified after the # in the constructor definitions are opcodes written in hexadecimal notation, representing $32$-bit unsigned integers. Thus, the automatically generated 6dfea180 opcode of the GeneratedOpcode Message represents the decimal value of $1845404032$, and the manually provided 12345678 opcode of the ManuallySpecifiedOpcode Message represents the decimal value of $305419896$, and not $12345678$ as it might appear.

Get methods

This section specifies the number of available get methods or getter functions and outlines them with their argument names, if any.

For example:

Total get methods: 2

## lshift
Argument: x

## gas

There, the lshift() getter has a single argument x, whereas the gas() getter has no arguments.

Exit codes

This section lists all default exit codes, as well as those generated from the error messages of the require(), along with those messages for your convenience.

For example:

* 2: Stack underflow
* 3: Stack overflow
...etc.
* 135: Code of a contract was not found
* 42933: Hey, I'm the error message of require()

There, the exit codes in the range from $0$ to $255$ are those reserved by TON Blockchain or Tact compiler, while the exit code of $42933$ is produced by the respective call to the require() function.

Trait inheritance diagram

This section shows a Mermaid diagram of inherited traits, including the BaseTrait.

For example:

There, JettonWallet inherits the WalletExitcodes and GasConstant traits, and all inherit the BaseTrait.

Contract dependency diagram

This section shows a Mermaid diagram of contract dependencies, i.e. any calls to initOf in order to compute the initial state of other contracts.

If the contract has no dependencies, only its name is displayed:

However, if the contract, say FirstOne, somewhere in its code computes the initial state of another contract, say SecondOne, such a relationship is shown in the diagram:

A real-world example of this would be the JettonMinter contract, commonly referred to as the Jetton Master. Often, JettonMinter needs the initial state of the JettonWallet, which is why JettonMinter defines the following internal function:

inline fun getJettonWalletInit(address: Address): StateInit {
    return initOf JettonWallet(address, myAddress());
}

Thus, the following dependency diagram is produced: