Clean up project solution structure

[SaschaWillems]

Description

With some recent additions, the Visual Studio solution generated via CMake became cluttered, confusing people as to what's the right project to actually launch:

This PR cleans up that project structure by moving the recently added vgf components to the ThirdParty folder and framework related projects to the framework folder. That only leaves the samples project at the top level, making it clear that this is the project people are supposed to start from the IDE:

Note that this is a pure visual change and doesn't change anything about the source code structure itself and does not affect the build in any way. It simple tells CMake that, if the IDE supports it, those projects should be displayed in their respective sub folders.

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

• I did a full batch run using the batch command line argument to make sure all samples still work properly

[asuessenbach]

Looks much better!

But I would not expect the framework in a components folder.

And while you're at it: maybe you could move all those Shaders-<Language> folders into some Shaders folder?
Like

Shaders
|--- GLSL
|--- HLSL
|--- SLANG
|--- SPVASM

[SaschaWillems]

I have updated this and move a new third party library added recently to said folder. Framework is now back at top-level.

There is a CTest project that seems to come from the astc third party dependency which can't be moved, so it's still there on top-level.

Steve mentioned that IDEs other than to Visual Studio don't support multi-level structures, so moving shaders into a shaders folder wouldn't work everywhere.

From my POV this is now ready for review.

[asuessenbach]

Steve mentioned that IDEs other than to Visual Studio don't support multi-level structures, so moving shaders into a shaders folder wouldn't work everywhere.

That's surprising. How are the samples listed on such an IDE? With VS, we have 5 folders ("Api", "Extensions",...) beneath "Samples"

[asuessenbach]

... and, maybe totally unrelated: why do we have all those shader projects at all? Why don't we compile the shaders on-the-fly?

[SaschaWillems]

... and, maybe totally unrelated: why do we have all those shader projects at all? Why don't we compile the shaders on-the-fly?

That's what we did in the early days. But that would mean we'd have to ship shader compiler libraries for GLSL, Slang and DXC. Esp. the later have limited OS support and they're not available on all our target platforms. That's why we went for the compile shaders at project compilation time and provide pre-compiled SPIR-V.

[SaschaWillems]

That's surprising. How are the samples listed on such an IDE? With VS, we have 5 folders ("Api", "Extensions",...) beneath "Samples"

No idea. I think this is related to how the folders are structured, but I don't have access to other IDEs outside of VS and VSCode (where this works fine).

So maybe @gpx1000 can chime in. If this does work in other IDEs just fine, I can add it back.

[tomek-brcm]

Nothing is broken for us with this change.