`pico_btstack/CMakeLists.txt` makes `PICO_BTSTACK_PATH` unusable

[usedbytes]

The pico_btstack library CMakeLists.txt hard-codes all of the btstack source files. This means that it's tightly coupled to a specific btstack version.

This is causing problems for my project, picow_ds4 (see https://github.com/usedbytes/picow_ds4/issues/1) which submodules btstack in order to support Playstation 4 controllers (which have HID descriptors which are too big for the upstream default) - and uses PICO_BTSTACK_PATH to use that submoduled version. pico-sdk has updated its btstack, I have not, so now my project doesn't build with an updated pico-sdk.

Having all of the source files listed in a CMakeLists.txt which lives inside pico-sdk seems like a layering violation - it's effectively an unmanaged dependency to a specific version of btstack, which is somewhat fragile.

You're welcome to argue that the submodule provides the versioning :-) - if you have the same version of btstack as what's submoduled in to pico-sdk then there's no issue. However it does make it basically impossible for projects to use PICO_BTSTACK_PATH unless they also submodule pico-sdk, which I'd like to avoid if possible.

I wonder if it would be better to have the pico_btstack build done within btstack itself, as a port, rather than managed by the pico-sdk build directly?

Related to #1379 / #1380 which is the specific PR which caused the particular breakage in https://github.com/usedbytes/picow_ds4/issues/1

[peterharperuk]

Yes. If there was a cmake file in btstack we would use it.

[peterharperuk]

@mringwal Do you have an opinion on this? It would be nice to not hardcode the list of source files in the pico-sdk but just include it from btstack. I think I copied the list from Micropython, so they have the same issue. I imagine I could convert your Makefile.inc files to cmake files with some "magic" but I doubt that would be that robust.

[mringwal]

@peterharperuk this is mainly relevant while people try stuff that hasn't been used much in the past ;) In general, I agree with the observations. I guess there are two main options here: a) is to provide a minimal CMakeLists.txt that contain all files from btstack/src that are currently used for inclusion (that would synchronize the list with the actual files). The fancier version is to fully embrace CMake. We started to consolidate our various CMake builds and have an early proof-of-concept (see global-cmake branch). I'm not sure yet, what path we'll use.

[kilograham]

Yeah, note some libraries just provide a CMake file which defines a variable with all the filenames