jkrech
commented
3 weeks ago Assuming that your BSP CMSIS-Pack is generated as a versioned snapshot of your repository, I don't think that there is "two versions of the truth". If the run-time software has modules with APIs that can be reused across projects, these should be described a components in the package description and then referenced by the projects rather than copied and duplicated. Please take a look at: https://github.com/Open-CMSIS-Pack/BSP-Pack-HandsOn .
Separating project files from source files does not seem like the best solution either, as the may run out of sync.
At this point the CMSIS Pack tooling for the end-user does not make use of cloning repositories (e.g. git repositories) for distributing software but instead uses Packs. The meta data kept in the package description however allows to specify the "origin" of a pack as e.g. a github repository and map a pack version to a repository tag.
ReinhardKeil
Lots of Si vendors distribute run-time software on github. It would be helpful if that code could be reused in CMSIS without creating copies inside packs. It is possible, today, to define example programs in board support packs using the tag. But that tag requires a "folder" attribute to find the content and those files must be included in the pack. This means the BSP and original repo contain "two versions of the truth".
It would be great to be able to refer to a repo from the example element (in addition to the folder attribute). That way vendors could put the CMSIS-specific files (csolution, cproject, etc.) in the BSP and pull the application sources from github.