How to put projects added through add_subdirectory into a VS filter?

I want to use shaderc in my project, so I added it as a submodule and linked it from my CMakeLists.txt

add_subdirectory(3rdparty/shaderc)
target_link_libraries(MyProject PUBLIC shaderc)

This clutters my Visual Studio solution with projects and filters of shaderc.

Apart from GLFW3, all of these and more are coming from shaderc.

Is there a way I can hide these or put them into an extra filter?

EDIT:

The answer by ComicSansMS is probably the real answer to this question, but I couldn't get it working for shaderc specifically.

I have moved to linking it from the VulkanSDK, which can be done with

find_package(Vulkan REQUIRED COMPONENTS shaderc_combined)

target_link_libraries(QuickPreviewVisualize PUBLIC ${Vulkan_LIBRARIES})
target_link_libraries(QuickPreviewVisualize PUBLIC ${Vulkan_shaderc_combined_LIBRARY})
target_include_directories(QuickPreviewVisualize PUBLIC ${Vulkan_INCLUDE_DIR})

For the debug to work, you will have to link to shaderc_combinedd.lib instead, therefore to a quick string replace and link idividually:

string(REPLACE ".lib" "d.lib" SHADERC_DEBUG ${Vulkan_shaderc_combined_LIBRARY})

target_link_libraries(QuickPreviewVisualize PUBLIC  	
    debug ${SHADERC_DEBUG} 	
    optimized ${Vulkan_shaderc_combined_LIBRARY})

Finally, this leads to a lot of linker warnings about missing pdb files, which you can disable through your project (or maybe even only for this library include?)

# the debug version of shaderc doesn't ship with .pdb files in the VulkanSDK
# therefore supress the warning about missing pdb files
target_link_options(MyProject PUBLIC "/ignore:4099")

The problem here is not target_link_libraries, but the fact that you pulling the entire dependency into your build with add_subdirectory. This means you are running shaderc's entire build configuration as part of your own build. Because of this, you are forced to some extent to play by its rules.

The cleanest way to resolve this is to not use add_subdirectory here. Instead, build shaderc on its own (possibly as part of your own project's CMake configuration, via execute_process; or by using a package manager such as conan or vcpkg) and then only depend on that pre-built version in your project. This decouples your own build from that of the dependency and isolates from any shenanigans that its build system may want to perform. It also has the advantage that you won't have to rebuild all of shaderc whenever you hit "Rebuild Solution". The only disadvantage of this approach is that if you make changes to the shaderc source code, rebuilding your project will not automatically rebuild shaderc as needed. But that is usually not a use case for third-party dependencies.

If you are still 100% set on using add_subdirectory here despite all the disadvantages, there is a hack. You can use CMAKE_FOLDER to set a global default folder for all targets that don't specify their own folder:

set(CMAKE_FOLDER "shaderc")
add_subdirectory(shaderc)
unset(CMAKE_FOLDER)

For all dependencies which end up in their own folders, you can manually move them so subfolders by setting their FOLDER target property in the surrounding project.

add_subdirectory(shaderc)
set_property(TARGET HLSL PROPERTY FOLDER "shaderc/hlsl")
set_property(TARGET glslang PROPERTY FOLDER "shaderc/glslang")
# [...]

Note that this really is nothing more than a hack and may break out of the blue whenever you upgrade shaderc.