Closed simoneruffini closed 1 year ago
Hi, Thanks for your idea!
I think I get your need, but I think the solution is not the most adequate.
What about including a folder with just the core files (the lib
) in the releases instead ?
Do you now any library that does the thing you describe?
This has the problem that I the repo can't be added as a git-submodule that helps with keeping track of remote updates and changes.
Do you now any library that does the thing you describe?
I don't know... I use it, although for me is manually performed and not with a github action.
If we group necessary file in a "lib" folder, you should be able to add repo as submodule and only build/import this folder while ignoring other files.
I'm not sure creating a special branch here is the correct answer when build system is able to take care of it. Or am I missing something ?
I can already do that with the current directory structure, I just didn't want to have all the examples in the repo too. Sometimes the build system is just an "include all .c .h" files and this could mess up stuff. Moreover you bring with the repo some hal files that could "potentially" (improbable but could happen) mess stuff up
Hi @simoneruffini, I'm closing this issue. I advice against globing all c file from a directory. This is not the way to go on modern Cmake :) and as you mention, is not clean since it can bring unwanted things to the build list!
Create a stripped down version of the master branch called
lib
that contains only the CMAKE functionality (the content of thecmake
folder). This branch could be calledlib
and can be used directly for git-submodules inside stm32 projects. The benefit of this branch is less imported code in a new project. The branch can be automatically generated frommaster
by a github action, it will live on its own, never merged into any branch but only merging/rebasing withmaster
.