The CMake-based build+install works, but it ends up installing the header files in include/concurrentqueue/moodycamel. This forces client code to use this header inclusion:
This is also the path taken by the concurrentqueue installation through Vcpkg and it is in the best interest for the spreading of the library that the two approaches are exactly the same.
The line responsible for this, and the only one that should need to be changed is the following.
The name of the organization (moodycamel) has a broader scope than the name of the library (concurrentqueue), it feel really weird that the two are inverted.
The CMake-based build+install works, but it ends up installing the header files in
include/concurrentqueue/moodycamel. This forces client code to use this header inclusion:While it would be preferable a simpler path, as this.
This is also the path taken by the
concurrentqueueinstallation through Vcpkg and it is in the best interest for the spreading of the library that the two approaches are exactly the same. The line responsible for this, and the only one that should need to be changed is the following.https://github.com/cameron314/concurrentqueue/blob/6dd38b8a1dbaa7863aa907045f32308a56a6ff5d/CMakeLists.txt#L61
Changed to this.
I could take care of the change, but I need to understand there's agreement on it. Will this change find acceptance?
NOTE: Should it be critical to keep the word
moodycamelin the path I'd suggest a more intuitive path.The name of the organization (moodycamel) has a broader scope than the name of the library (concurrentqueue), it feel really weird that the two are inverted.