Include mode vs Flat mode¶
KnitPkg supports two strategies for making dependency headers available to your project at compile time:
- Include mode:
include_mode: include - Flat mode:
include_mode: flat
Include mode (include_mode: include)¶
In include mode, KnitPkg does not generate a flat (single-file) header.
Instead, when you run kp install, KnitPkg:
- Resolves your dependency versions using the registry metadata.
- Downloads dependency sources into
.knitpkg/cache. - Processes the dependency headers and resolves any
@knitpkg:includedirectives found inside them. - “Mounts” (builds) a merged include tree under
knitpkg/include/.
The key idea is: after kp install, knitpkg/include/ contains the headers your project needs, organized by organization and package name, ready to be referenced by #include.
Flat mode (include_mode: flat)¶
In flat mode, kp install generates a single flattened header (a “flat file”) from a declared entrypoint.
Conceptually, KnitPkg:
- Resolves and downloads dependencies into
.knitpkg/cache. - Reads the entrypoint header(s) declared in the manifest.
- Follows
@knitpkg:includedirectives to pull external headers from dependencies. - Produces a generated file under
knitpkg/flat/(for exampleknitpkg/flat/KnitPkgSMA_flat.mqh), containing everything needed to compile.
The key idea is: instead of including many separate headers, your main .mq5 includes one generated file.
A concrete example: calclibimp uses include mode¶
To make this less abstract, let’s look at the project calclibimp. In short, calclibimp is an MQL5 library project meant to expose indicator calculations from @douglasrechia/calc as a compiled library.
Info
The package @douglasrechia/calclib provides stubs to make it easy for any KnitPkg project to link against @douglasrechia/calclibimp.
Below is the knitpkg.yaml from calclibimp. Note the highlighted lines: it is a library, it uses include mode, and it depends on bar and calc.
What happens when you run kp install?¶
In include mode, after kp install finishes, you will typically see a directory structure like this:

knitpkg/
└───include/
└───douglasrechia/
├───bar/
│ Bar.mqh
│ BarArray.mqh
│ BarMqlRates.mqh
│ BarTimeSeries.mqh
│ BarWatcher.mqh
│ TimeSeries.mqh
│ TimeSeriesArray.mqh
│
└───calc/
Calc.mqh
Notice how knitpkg/include/ now contains the headers for the bar and calc dependencies. This is the core promise of include mode: KnitPkg installs the dependency headers into a predictable include tree so your project can compile.
No entrypoint required¶
In include mode, you do not need an entrypoints: section in the manifest.
Your main source file can include dependency headers directly from knitpkg/include/. For example, in src/CalcLibImp.mq5, the includes look like:
How to choose between include mode and flat mode¶
The choice depends on how you want to ship and organize your project:
- Choose flat mode when you want to distribute a project as a small set of files (often a single generated include), such as projects published/sold to end-users (for example in the MQL5 store). Flat mode can reduce the number of extra files installed in a user’s environment, at the cost of a bit more setup (entrypoint + generation step).
- Choose include mode when you prefer a classic include-tree workflow (many headers available under
knitpkg/include/), and you don’t mind the dependency headers being materialized as separate files.
In both modes, the workflow is still the same at a high level: kp install resolves and downloads dependencies, then prepares your project so kp compile can run successfully.