CMakeLists INSTALL DESTINATION and INSTALL_INTERFACE are inconsistent

Previously, I had been grabbing concurrentqueue with cmake's FetchContent and it worked great. Recently, I switched to using it as a bitbake recipe in an embedded system, where concurrentqueue gets installed as a system-level dependency. I suddenly had to change my includes to #include <moodycamel/concurrentqueue.h>. And of course this fails when I want to build without the system-level install for local debugging without the embedded sysroot.

I think the problem is simple:

https://github.com/cameron314/concurrentqueue/blob/189e381cfae411e5159444d27b95beee10f930af/CMakeLists.txt#L9-L13

and

https://github.com/cameron314/concurrentqueue/blob/189e381cfae411e5159444d27b95beee10f930af/CMakeLists.txt#L54-L62

should match.

I propose removing the trailing moodycamel from the install destination.

That way, all the include statements in the source code will be the same (#include <concurrentqueue.h>) whether someone grabs concurrentqueue with FetchContent or they install concurrentqueue to the system and use find_package(concurrentqueue) followed by target_link_libraries(${PROJECT_NAME} concurrentqueue::concurrentqueue).

Currently, I'm patching concurrentqueue on fetch with this exact change and it's working well for me.

Read the referenced install and INSTALL_INTERFACE sections in CMakeLists.txt and compare their destinations. Verify that the installed layout and FetchContent usage produce the same include path, then confirm the CMake package target remains usable with find_package and target_link_libraries.