Add top level project guard

[TheBill2001]

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_LEVEL variable, which is available since CMake's 3.21. With older version, we fall back to check whether CMAKE_SOURCE_DIR is equal to PROJECT_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?

[Sapd]

I think the logic is inverted if I see it right.

Currently with this changes:

• Building HeadsetControl standalone -> CLI, tests, install, CPack are disabled
• Using as subdirectory → CLI, tests, install, CPack are enabled

So the NOTs have to be removed. Or does it have a specific reason it's this way?

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?

I think it can be as-is for now. We can also later in theory add it into the library

[TheBill2001]

I think the logic is inverted if I see it right.

You're right! Should have not written anything while lacking sleep. 😅

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud