Update IDE Folders

[Meinersbur]

Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (set_property(TARGET <target> PROPERTY FOLDER "<title>")) when using the respective CMake's IDE generator.

• Ensure that every target is in a folder
• Use a folder hierarchy with each LLVM subproject as a top-level folder
• Use consistent folder names between subprojects
• When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of set_property/set_target_property, but are still necessary when add_custom_target, add_executable, add_library, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.

Before:

After:

Visual Studio now supports CMake projects directly, but the Visual Studio solution generator still has advantages. One is that targets including entire folders can be hidden when not needed. This removes non-relevant items form code search and does not try to rebuild them. For instance, when hiding Tablegenning and Resources targets, an iterative build can be faster than using ninja. The other one is that the organization in folders is less cluttered than the CMake targets view or the startup item view¹:

Footnotes

1. Items can be hidden from the dropdown menu, but the entire list is still flat with hundreds of executables. ↩

[whisperity]

Maybe if this is only affecting IDEs, then perhaps the property's name should reflect this, i.e., IDE_FOLDER? Unfortunately, directories are also called "folders" at least on Windows, so I see a slim chance of misunderstanding this as the path from which the external project is loaded.

[Meinersbur]

It's already called FOLDER in https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/AddLLVM.cmake#L2080-L2083. I would prefer to keep it consistent.

[JDevlieghere]

This looks like a nice improvement for folks using those generators. Even though most of these changes look straightforward, it would be a lot easier to review if this was broken up per subproject. Is there any reason that's not possible?

[jh7370]

This looks like a nice improvement for folks using those generators. Even though most of these changes look straightforward, it would be a lot easier to review if this was broken up per subproject. Is there any reason that's not possible?

+1 to this: 195 files is too many to review in a single PR really, so if we have an alternative, incremental approach, we should take that. (Also big +1 to the improvement though).

[Meinersbur]

As suggested, I split the patch into per-subproject patches:

LLVM (dependency of the other patches)
BOLT
Clang
Clang-Tools-Extra
Compiler-RT
Flang
libclc
LLD
LLDB
MLIR
OpenMP
Polly
Misc