Description
The README says:
In the future, core apis will be updated independently from the core, so all the compatible cores will seamlessly adopt new features. This requires support from all the IDEs, so in the meantime we suggest to release the core by copying a snapshot of this api folder.
The most elegant and effective solution is to develop the core with api symlinked and produce the distributable archive by telling tar to follow symlinks. Example command:
I'm not so sure I like the idea of adapting the tooling to automatically combine (target-specific) core files and generic api files (from this repository). It seems nice to automatically update all of your cores to a new API version, and that works with changes to e.g. String or (to some degree) Streaam, but will that not break when other fnctions/APIs are added? If the function (e.g. like digitalWrite()
) is added in ArduinoCore-API, it will be declared (and ARDUINO_API_VERSION
is bumped to indicate the new API is available), but the implementation is target-specific and must be provided by the target core (hence this will lead to linker errors).
To me, it seems better to let each core explicitly update to new API versions, which gives the core a chance to test against the new API version, add new APIs or otherwise make changes, etc. The current recommended approach of a symlink is not particularly good in this regard, since the symlink is not tracked in git, so it needs external documentation to know what API version was used for a particular core version, making it harder to go back to older versions.
Tracking the API version used more explicitly seems better to me, and an obvious mechanism for this is to use submodules. These are a bit like symlinks, but then refer to external git repositories and are versioned (i.e. refer to a specific commit id). Updating a submodule to a newer version is commited as normal in the parent repository.
One caveat for submodules is that, I think, you can only add the repository as a whole, not just a subdirectory (so in this case, cores/arduino/api
could be a submodule, but then you would get cores/arduino/api/api
with the actual files). Fixing this could be done by putting the files in the root of this repository, though having some structure in this repository might also be useful.