1.4 (2025-01-19)¶

Introducing the `.rt` file extension¶

Changes to the promoted file extension used for project and packages have been made. When releng-tool was originally released, no extension was used for various package definitions and scripts. While functional, this was not always ideal for development environments wanting some level of syntax highlighting support. Over the years, alternative extension support has been added, allowing .releng or even .py for an extension type to be used.

For this release, the promoted extension type to use will now be .rt. It is a minimal file extension with a name appropriate to this tool and is believed to not be in conflict with other modern applications/tools that exist today. releng-tool still supports extensionless files as well as the .py extension. The use of .rt over only using .py will allow developers to have a distinction between releng-tool-compatible Python files and generic Python files.

With these changes, the default project configuration will also be releng-tool.rt. An example project structure is as follows:

└── my-project/
    ├── package/
    │   ├── libbar/
    │   │   ├── libbar.rt
    │   │   └── libbar.hash
    │   └── libfoo/
    │       ├── libfoo.rt
    │       └── libfoo.hash
    └── releng-tool.rt

Copy/remove corrections when handling broken symbolic links¶

Script helpers releng_copy and releng_remove have been updated to improve handling when managing symbolic links that are dangling. This allows a script definition to handle scenarios where symbolic links are broken or when a build prepares symbolic links for a target environment that are considered invalid in a host environment.

Previous versions would detect an issue with a symbolic link and a copy or remove event would stop with an error.

Improved Cargo support¶

Support for Cargo-based packages have been improved. Cargo packages now share a build target to prevent re-compiling package dependencies multiple times when multiple Cargo applications exist.

This update also supports automatic Cargo patching for projects that define Cargo libraries. Cargo applications will automatically be patched to use a defined Cargo library in a releng-tool project, if a developer wishes to manage specific libraries in a project.

Lastly, the fetching of Cargo dependencies now occurs after a package’s patch stage. This will allow developers to patch downloaded sources before attempts are made to post-fetch any configured dependencies on a Cargo project.

New «fresh» package action¶

A new package action named «fresh» (<pkg>-fresh) is now supported by releng-tool. This action can be used by default to easily setup a package into a «fresh» state for development/testing purposes. Essentially, the fresh action is a combination of performing <pkg>-clean then <pkg>-configure.

releng-tool libfoo-fresh

Improved Visual Studio integration¶

For builds running in a Windows environment, variables provided by a Visual Studio Developer Command Prompt (VsDevCmd.bat) can be preloaded into a projects or package context.

vsdevcmd = True

This can be used to avoid any requirement to run releng-tool from inside a Visual Studio Developer Command Prompt when attempting to perform a build.

Projects looking to use an explicit version of Visual Studio can specify a version string that is compatible with Visual Studio Locator’s (vswhere) -version argument.

vsdevcmd = '[17.0,18.0)'