For those following this project for some time, they might have noticed my references to xPacks, to the package manager, the package builder, etc.
My 2019 new year's resolution was to complete these tools, and any help will be highly appreciated.
In short, the idea is to design and implement a set of tools allowing to build modular software, where the modularity unit is the 'xPack', seen as one or more closely related files, usually source files and includes, plus a minimum of metadata, to help the tools automate the process.
The design is greatly inspired by Node.js & npm, xPacks being actually specialised node modules, sharing the same package.json description and possibly being stored on the same npmjs.com public server.
An example of an experimental such project is the SiFive template (https://www.npmjs.com/package/@sifive/templates), which can generate simple blinky projects for some of the SiFive RISC-V demo boards. Don't be scared by RISC-V, the tools have nothing specific to RISC-V, the same approach can be used for Arm or any other architecture.
I invite those willing to experiment to try this project generator, and proceed with building the project.
The plan is to write similar project templates, first for STM32 devices, later possibly for other families.
Crucial for this project are several tools:
- xpm - the xPack Project Manager (https://www.npmjs.com/package/xpm)
- xbld - the xPack Builder
- xmk - the xPack Make
- xsvd - the xPack SVD
xpm - the xPack Project Manager
The current xpm already implements the basic functionality; its main goal is to manage dependencies, and bring together the needed xPacks, either with source code, or with binary tools.
I expect your reaction to be: Yet another package manager? Aren't the Linux package managers, or existing package managers (like Microsoft vcpkg, Arm yotta, Arm CMSIS packs, etc) enough?
Well, most existing package managers are not designed to handle very well multiple versions of the same package at the same time; xpm uses the same concept as npm, and allows each project to refer to specific versions of the existing xPacks, and specific versions of the tools used to build the project.
Thus, once the project dependencies are defined and validated, the project should build properly at any time, and in any environment, even on CI servers.
Another advantage od xpm is that it is highly portable, it works on most relevant platforms.
xbld - the xPack Builder
xbld is the successor of the initial xmake, with functionality redefined. (plus that it avoids the name clash with another Lua make tool).
This tool is intended to be functionally equivalent to the Eclipse CDT builder, i.e. to build a given artefact (executable or library), based on a set of simple rules, without the need to manually write make files.
The initial xmake used in the SiFive template was reworked, and now can build both regular projects and associated tests.
Currently it generates either make or ninja configuration files, and runs the build. It can also export Eclipse projects.
The next step is to implement the internal builder, and be able to run the build directly, without the need of external tools.
The latest version is not ready, I plan to update the GitHub project soon.
xmk - the xPack Make
This tool is currently in design stage.
The plan is to implement a similar functionality as ninja, i.e. a very simple tool that takes a graph of target dependencies, a list of command lines, and runs them in order to satisfy the dependencies.
The input file is a relatively simple json, with a content inspired from the ninja.build; the json format is simple enough to be generated by upper tools, and also provides a minimum validation when written by hand.
The tool will be available with both a CLI and an internal API, allowing easy integration in other tools, like xbld, which will use it directly.
I expect xmk to raise the same questions: Yet another make tool? Aren't make/ninja/etc good enough?
Well, make is definitely not good enough; it is old, slow, it poorly processes names with spaces, on Windows it is not easy to find a properly functioning one, etc.
ninja is generally better from many points of view, and some newer tools like meson do not even use make, supporting only ninja. However, ninja is a binary tool, that needs to be compiled and installed on each machine using it.
xmk is planned to be a replacement of ninja, but using more modern technologies, like node.js, making it automatically portable for all platforms supported by node.js (all relevant ones). As a node module, it can be automatically installed as a dependency by npm/xpm, greatly automating builds and tests, even on CI servers.
xbld may raise similar questions, like Why not continue to use the Eclipse CDT builder?
Well, first that Eclipse is no longer on the wave; I would say it lived its life and now slightly goes down the slope.
One of the main design goals of the xPack tools is to fully provide the required functionality from console, on all relevant platforms. This not only helps running tests on CI servers, but will also provide a good starting point to integrate them in any of the new graphical tools, like Visual Studio Code, Atom, etc.
The immediate entries on my schedule are:
- complete the refurbish of cli-start-options node module (https://github.com/xpack/cli-start-options-js ), to be used for all xPack CLI tools
- implement the xmk tool (https://github.com/xpack/xmk-js , currently an empty placeholder)
- rename xmake as xbld and integrate the internal builder, using xmk
Once the build tools are fully functional (hopefully in 6-8 weeks), work on the STM32 template will start. I'll take from where the SiFive template left it, integrate CubeMX and add support for an several RTOSes (FreeRTOS, CMSIS RTOS and µOS++).
The main components will be based on the existing code in µOS++, which will be split into several xPacks.
xPack & µOS++ Forum
Given the planned migration away from Eclipse, I created a new site to host discussions about xPacks and µOS++:
Apart from initial comments on this post, I invite all those interested in contributing to the xPack and µOS++ projects to use the new forums, which are planned to replace this element14 community.