Managing Reusable MQL Projects with Versioned Packages and Tests
Summary
The article presents KnitPkg as a way to share MQL4 and MQL5 code across expert advisors, indicators, libraries, and utilities without manually copying folders between projects. A project manifest declares dependencies and build settings; package versions use semantic versioning, while a lockfile helps resolve builds to specific dependency versions. KnitPkg can install dependencies as an include tree or generate a single flattened header, and composite packages can use development helpers that are converted into consumer-ready includes during installation.
A case study organizes a simple moving average calculation and bar data interfaces into reusable packages, then connects the calculation to an indicator and an expert advisor. The example emphasizes recalculating only when a new bar forms to reduce unnecessary work, and describes compiling package unit tests to check behavior. This is a software workflow guide rather than a trading-performance study: the example specifies a moving-average crossover with a filter but provides no evidence that the trading rule is profitable. Reproducibility also depends on correctly declared versions and dependencies.
Key ideas
- A manifest can declare MQL project identity, build settings, and package dependencies in one place.
- Semantic versioning and a lockfile help consumers install controlled, repeatable dependency versions.
- Packages can be installed as an include tree or combined into a flattened header.
- The case study separates bar interfaces and moving-average calculations into reusable components used by an indicator and an expert advisor.
- Unit tests compiled with a package can help detect regressions, but the example does not establish that its trading rule is profitable.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.