TorstenRobitzki / bluetoe

C++ Framework to build Bluetooth LE Server (GATT)
MIT License
142 stars 29 forks source link

build system, migrate to a modern cmake approach #35

Closed xnlcasad closed 6 years ago

xnlcasad commented 6 years ago

Attempt at a clear separation of dependencies between the different submodules of bluetoe.

create a bluetoe::tests:test_tools module create a bluetoe::utility module create a bluetoe:sm (security manager) module create a bluetoe::bindings::nrf51 module create a bluetoe::iface module create a bluetoe::linklayer

The tests can be built and run in the host environment, inside bluetoe's root folder:

mkdir build && cd build cmake .. make && make test

To build the examples for nrf52: cd examples mkdir build_nrf52 && cd build_nrf52 cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DARM_GCC_TOOL_PATH=/path/to/gcc-arm-none-eabi/ -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DBINDING=nrf52 -DNRF5_SDK_ROOT=~/path/to/nrf5_sdk/ .. make blinky.flash make thermometer.flash

To build for the nrf51, replace -DBINDING=nrf52 with -DBINDING=nrf51

CMAKE_BUILD_TYPE can take the usual cmake build config types.

A client project that intends to use bluetoe as a library should add to bluetoe's client project CMakeLists.txt file:

add_subdirectory(bluetoe) target_link_libraries(client_target_name PRIVATE bluetoe::iface PRIVATE bluetoe::bindings::${BINDING})

The bluetoe::bindings::${BINDING} module has a dependency on a client project provided cmake_target named toolchain::${BINDING}. This client provided cmake_target injects the binding's vendor specific compile options and include paths necessary to build the hardware specific part of bluetoe. For reference look under examples nrf51_toolchain_support/CMakeLists.txt

xnlcasad commented 6 years ago

I suggest that we squash the 3 commits and merge a single commit into the master branch (no merge-commit), the rationale is to have a bisectable (always passing CI) master history.

TorstenRobitzki commented 6 years ago

branch merged