You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the only way to integrate the library into a client project is to add the json.hpp file to the source tree of the project. In some use cases that might not be the ideal solution.
For instance I'm working on a JSON processing library that uses the nlohmann/json library not only internally but in it's API as well. So client applications which would wan't to use the library would either have to use the json.hpp file supplied by the JSON processing library, which is awkward, or if they are already using the json.hpp file they can create and pass json variables to the library which can cause unpredictable problems if the version of the json.hpp file used by the client application and the JSON processing library differs.
Fortunately, CMake has a solution to the above problems.
With a few lines of CMake code we can create an interface library (a library target that doesn't generates any output, but it can be used to store usage requirements, which in our case would be the include directory of the json.hpp file) and export it. This way by including the nlohmann/json library into the client application with add_subdirectory, all targets would be able to find and use the library with the find_package command.
With another few lines of CMake we can add an install target to the nlohmann/json project. Users would be able to install it using make install and use it, again, with the find_package command without including the json.hpp file into the project.
So by using find_package users can be sure that all the targets that depend on nlohmann/json are using the exact same file, and since we can optionally specify a version number for the find_package command too, users can avoid problems that might arise when using different versions.
In the end, we wouldn't lose anything. Users can continue to copy the json.hpp file into their projects if they feel that this is the right approach for integrating nlohmann/json into their projects. But we would gain some additional integration options.
The text was updated successfully, but these errors were encountered:
@mmchen It should work. But the package's name was changed sometimes after this PR got merged to nlohmann_json, so you should try to use find_package(nlohmann_json).
At the moment the only way to integrate the library into a client project is to add the
json.hpp
file to the source tree of the project. In some use cases that might not be the ideal solution.For instance I'm working on a JSON processing library that uses the nlohmann/json library not only internally but in it's API as well. So client applications which would wan't to use the library would either have to use the
json.hpp
file supplied by the JSON processing library, which is awkward, or if they are already using thejson.hpp
file they can create and passjson
variables to the library which can cause unpredictable problems if the version of thejson.hpp
file used by the client application and the JSON processing library differs.Fortunately, CMake has a solution to the above problems.
With a few lines of CMake code we can create an interface library (a library target that doesn't generates any output, but it can be used to store usage requirements, which in our case would be the include directory of the
json.hpp
file) and export it. This way by including the nlohmann/json library into the client application withadd_subdirectory
, all targets would be able to find and use the library with thefind_package
command.With another few lines of CMake we can add an install target to the nlohmann/json project. Users would be able to install it using
make install
and use it, again, with thefind_package
command without including thejson.hpp
file into the project.So by using
find_package
users can be sure that all the targets that depend on nlohmann/json are using the exact same file, and since we can optionally specify a version number for thefind_package
command too, users can avoid problems that might arise when using different versions.In the end, we wouldn't lose anything. Users can continue to copy the
json.hpp
file into their projects if they feel that this is the right approach for integrating nlohmann/json into their projects. But we would gain some additional integration options.The text was updated successfully, but these errors were encountered: