CMake alias to `nlohmann::json`

[parnmatt]

Currently you have the internal name nlohmann_json, and a library alias to nlohmann_json::nlohmann_json, and an export namespace of nlohmann_json:: as per regular convention

Thus when including this project, you can always refer to nlohmann_json::nlohmann_json.

Keep the PROJECT_NAME to nlohmann_json; but have your target name as json with a library alias prefix and export namespace as nlohmann::.

Thus nlohmann::json can be used; which is not only shorter to type, but also in line with the C++ namespacing.

In theory you can make a library alias and separate export group to the current form as well as the suggest form, to not break compatibility. Potentially being deprecated, and optionally removed in a much future version.

[nlohmann]

@parnmatt I am not a CMake expert, so I am calling out to @chuckatkins about this idea.

[chuckatkins]

TLDR: the current behavior should remain default but making it configurable would be a useful addition.

Long answer:
CMake namespacing is really intended to express multiple components of a single library and framework, which is pretty typical of C++ namespacing as well. Boost, for instance, creates the imported targets for boost::date_time, boost::filesystem, etc. that correspond respectively to libboost_datetime.so, libboost_filesystem.so, etc. So really the CMake namespacing model, and for that matter the typical C++ namespacing model (although no hard rules you can make it however you want), is framework_name::component_name. For a small library with a single component, these tend to be the same thing. So with that in mind, nlohmann doesn't really make sense as a framework / library name with a json component library.

That being said, the target name of nlohmann_json is already used as a variable instead of hard coded so it would be trivial to make both the target and target namespace user-editable cache variables. The intrastructure already references them this way via ${PROJECT_NAME}::${NLOHMANN_JSON_TARGET_NAME} so making them advanced cache variables and using ${NLOHMANN_JSON_TARET_NAMESPACE}::${NLOHMANN_JSON_TARGET_NAME} would allow you define the namespacing and target naming however you wanted. Making the namespacing configurable like that is atypical in cmake-world but not unheard of (i.e. not a typical usage but not an anti-pattern) and makes sense for this use case given that the library is commonly embedded as a private dependency that you want to try to make fit with the rest of your project infrastructure. We actually do this very thing same thing for some internal utility libraries used by CMake and VTK.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.