Update CMakeLists.txt

[Xavier-Yin]

Recent versions are stated to remove boost dependency. But when I try to build on a Linux without boost installed, and latest Asio extracted from tarball, it complains for missing boost headers.
According to https://think-async.com/Asio/AsioStandalone.html it should be able to make it actually standalone simply by adding a definition.
This PR seems to work in my case. Asio dependency on Boost headers should now be removed and actually being used in a standalone manner.

[kenr]

Since the vcpkg port file takes care of selecting ASIO standalone we have not set the define.

I assume you did not use the installation instructions and are not using vcpkg to get catch2 either?

[Xavier-Yin]

Yes your right. I'm trying to use pc-ble-driver-py on Linux ARM(V6) where vcpkg seems not easy. Catch2 is installed from source and ASIO is simply extracted from tarball. Actually I can make it compile without the modification to Nordic code in this PR, but it involves ugly 'export CXXFLAGS="-DASIO_STANDALONE"'.
Please consider merging if this PR does not harm your standard vcpkg method.

Hope Nordic is interested in bringing pc-ble-driver(-py) to Linux ARM platform. With bit banging SWD by OpenOCD, direct control to nRF5 by SOCs is easy. This combination is interesting, isn't it? (Or does Nordic have plan integrating to stock Linux BT driver BlueZ?) In fact we're not far from this. 1aadc39 (pc-ble-driver) + 4ea39a06532302ba75ce8e9fd7cc3b2597e2eac3 (pc-ble-driver-py) seems to work together for SD_API_VER_2/3/5 if a little tweak is made.

[Xavier-Yin]

Please also consider merging NordicSemiconductor/pc-ble-driver-py#84 if it does no harm to standard vcpkg environment.

[kenr]

@Xavier-Yin Is is an interesting use case. Official RPi support for pc-ble-driver is not on our roadmap though.

[kenr]

Thank you for the contribution.

[ras0219-msft]

on Linux ARM(V6) where vcpkg seems not easy

We'd like to make this easy -- could you go into a bit more detail about how this was difficult for you?

[Xavier-Yin]

@ras0219-msft
Without figuring out how to cross-compile pc-ble-driver(-py), I simply follow the naive native build steps in Nordic documents. This means I need to install vcpkg on that ARM (Debian). According to vcpkg official README.md - Quick Start installation on Linux takes steps like this:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh

And I got error like this:

./bootstrap-vcpkg.sh: 237: /home/pi/vcpkg/scripts/bootstrap.sh: /home/pi/vcpkg/downloads/tools/cmake-3.12.4-linux/cmake-3.12.4-Linux-x86_64/bin/cmake: Exec format error
./bootstrap-vcpkg.sh: 238: /home/pi/vcpkg/scripts/bootstrap.sh: /home/pi/vcpkg/downloads/tools/cmake-3.12.4-linux/cmake-3.12.4-Linux-x86_64/bin/cmake: Exec format error
cp: cannot stat '/home/pi/vcpkg/toolsrc/build.rel/vcpkg': No such file or directory

Digging a little deeper I found out that the wrong architecture on above comes from vcpkg tool list. As you can see in that file, only x86 is considered. It looks like vcpkg may be far from supporting to run on ARM.

I understand the possibly BEST solution is getting pc-ble-driver(-py) cross-compiled on powerful x86. But I'm not sure if this is on Nordic's roadmap. Or are you interested in this, @ras0219-msft ?