I want to know the usage timing for target_include_directories and target_link_libraries
I build a third party lib.so or lib.dll
And using it on my project.
The situation 1 is using the *.so or *.dll , and it doesnt use the library include file.
Because I already use the *.so or *.dll.
Your previous question was about VSCode being able to pick up headers when browsing your project’s code. When you’re in that situation:
The library headers absolutely are used — they’re how your downstream code knows the API of the shared library. You can’t use a C/C++ shared library without a header file to define the public API.
From a VSCode perspective, what really matters isn’t when, how, or in what form your dependencies are incorporated into the project. What matters is that the compile_commands.json file CMake generates contains all of the correct -I flags (or -isystem) with the paths to your libraries’ header files. VSCode will read the commands in that file to determine where it should look for headers named in #include lines.
Any method of getting the include paths into your build commands will work for VSCode. For the purposes of code browsing/editing, it doesn’t matter if the headers are installed somewhere else on the system, inside your own source directory, or generated inside the build directory. (As long as they’re generated during the cmake run, so that they exist for the tools to find them!)
Using targets for external dependencies, with the INTERFACE_INCLUDE_DIRECTORIES property defined, is strongly recommended as the easiest and most maintainable method, for sure. But that’s more important from the perspective of building and maintaining your project code. In terms of what VSCode sees, by the time cmake is done those targets are already gone, and all of their properties have been turned into compiler commands.
You shouldn’t need to do this. If you use target_link_libraries() as shown further above, that will add any required header search paths, compiler options, etc. as usage requirements to any target that links to nlohmann_json::nlohmann_json (which is test_app in this example). As long as you’re not using an old nlohmann_json version that predates adding those details to nlohman_json::nlohmann_json, you should be fine.
Not sure what you’re trying to do here. You shouldn’t be creating this target yourself. You should be using find_package(nlohmann_json) instead, which would provide the nlohmann_json::nlohmann_json target for you. Alternatively, you could use FetchContent, which would download nlohmann_json from GitHub and add it directly to your project: