search

otland / forgottenserver

A free and open-source MMORPG server emulator written in C++
https://otland.net
GNU General Public License v2.0
1.58k stars 1.05k forks source link

Improve CMake presets for Visual Studio #4743

Open ranisalt opened 3 months ago

ranisalt commented 3 months ago

Pull Request Prelude

Changes Proposed

Visual Studio cannot handle multi-config generators, so it is necessary to have one preset per configuration, otherwise developer experience is mediocre. There are no plans to add support from Microsoft.

Codinablack commented 3 months ago

I don't understand why someone would want to have ninja handling the build for them on windows if they are using visual studio to develop. That doesn't make sense to me. You are also gonna be hard pressed to find anyone who is developing on windows who is not using visual studio, unless they are using jetbrains products. In which case this doesn't help them at all.

Also, visual studio takes a mere moment to make any real major adjustments, which is done so pretty easily in the project settings.

As for build times, visual studio with unity builds tfs in about 1 minute for release, and half that time for debug.

So basically, I am just trying to figure out why this is needed? Why delete the working visual studio solution?

ranisalt commented 3 months ago

I don't understand why someone would want to have ninja handling the build for them on windows if they are using visual studio to develop.

This PR is doing exactly the opposite, not using Ninja if you pick the VS preset. It doesn't really matter because CMake will do the job, but it helps a bit with integration.

Why delete the working visual studio solution?

Because it's not working as expected and no one steps up to fix it - e.g. it builds everything and can't select features, doesn't integrate with vcpkg (which caused the troubles with default features you had), can't enforce dependency minimum versions -, and because Visual Studio solutions are severely handicapped: for starters, it does not support folders, which makes it impossible to have two files with the same name in separate locations. It's also not possible to use relative includes (all files are considered to be in the same folder), so it makes code un-portable from Windows because include paths won't match.

Of course it may be possible that there are solutions to these problems, but it comes back to the first sentence.

VS itself also does not support multi-config generators (as mentioned), so there must be a separate preset for each config we want available.

Maybe sln/vcxproj can do everything that CMake does, it's just not so well documented. CMake can also generate VS solutions (cmake -B vc17 . if on Windows), while VS solutions can't be used anywhere else. Windows is the only one with special treatment.

Mind you, CMake is also not my favorite tool, I prefer Meson and it's Python-like syntax a lot more, but it does the job really well, it's deeply documented and widely used in our community that it just doesn't make sense to stray away from it.

Codinablack commented 3 months ago

CMake can also generate VS solutions (cmake -B vc17 . if on Windows), while VS solutions can't be used anywhere else. Windows is the only one with special treatment.

Legit. This is very true.

Ok. I understand now. It is better to generate the solution on the system that will be using it, I can definitely agree on that. I can also see how having a solution premade could lead to problems with integration.

I must have been confused about the ninja thing, thanks for clearing that up for me!