Repository navigation
Add top level project guard - #456
Conversation
|
I think the logic is inverted if I see it right. Currently with this changes:
So the NOTs have to be removed. Or does it have a specific reason it's this way?
I think it can be as-is for now. We can also later in theory add it into the library |
Add top level project guard to disable some configuring steps that are unnecessary when using as a subdirectory/fetch_content
You're right! Should have not written anything while lacking sleep. 😅 |
On MSVC, it requires getopt from vcpkg
|
2 participants
Since the recommended way to use the headsetcontrol library is as a subdirectory. Some configuring steps should be disabled. This PR adds a top level project guard to disable some configuring steps that are unnecessary when using as a subdirectory or with FetchContent.
This leverages
PROJECT_IS_TOP_LEVELvariable, which is available since CMake's 3.21. With older version, we fall back to check whetherCMAKE_SOURCE_DIRis equal toPROJECT_SOURCE_DIR.Potential problem: In this patch I also put the build CLI executable step and generating udev rules step behind the guard. Should generating udev contents also be available through API and let the library consumers handle it themselves? Or the generating udev rules step should not be put behind the guard?