Hello, and no, I wasn't able to create the library in the way I wanted. But I also haven't worked on it much, as I'll only need it a bit in the future.
But I do have a suspicion that the problem that I had with CLion is because it doesn't properly support INTERFACE libraries. It took a while for me to understand that, as I'm quite new to C++ development (though not software development in general), but it makes sense. The documentation for CMake says that INTERFACE libraries have no source code, so it wouldn't make sense for CLion to lint source files on such a project.
Some of the libraries on the community sticky post are STATIC (even though it says that only INTERFACE libraries will be accepted), so I'm inclined to believe that I could just change the project type to STATIC. I tried reading some of the Pico SDK source code, and it seems that it's all header files, with implementations in assembly I presume, and so an INTERFACE library would make more sense in that case, but not necessarily for all use cases.
Now for the problem you described, I imagine that you will need to separate what uses the SDK from what doesn't, and put code that is independent from one implementation or another into a common base library.
But I do have a suspicion that the problem that I had with CLion is because it doesn't properly support INTERFACE libraries. It took a while for me to understand that, as I'm quite new to C++ development (though not software development in general), but it makes sense. The documentation for CMake says that INTERFACE libraries have no source code, so it wouldn't make sense for CLion to lint source files on such a project.
Some of the libraries on the community sticky post are STATIC (even though it says that only INTERFACE libraries will be accepted), so I'm inclined to believe that I could just change the project type to STATIC. I tried reading some of the Pico SDK source code, and it seems that it's all header files, with implementations in assembly I presume, and so an INTERFACE library would make more sense in that case, but not necessarily for all use cases.
Now for the problem you described, I imagine that you will need to separate what uses the SDK from what doesn't, and put code that is independent from one implementation or another into a common base library.
Statistics: Posted by suprjd — Wed Jul 09, 2025 6:44 am