New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various fixes for msvc/cmake builds #10620
Conversation
667c830
to
50ab358
Compare
Source/PCH/CMakeLists.txt
Outdated
|
|
||
| # targets which use the pch need these compile options | ||
| # /Yu - Use precompiled header named "pch.h" | ||
| # /Fi - Force include "pch.h" at top of every source file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is a typo in the comment, should be /FI.
|
@phire might need some tweaks since qt6 was merged |
Source/CMakeLists.txt
Outdated
| add_compile_options(/external:anglebrackets) | ||
| add_compile_options(/external:W0) | ||
|
|
||
| # TODO: Enable this once PR #10559 is merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That PR is now merged.
Source/Core/DolphinQt/CMakeLists.txt
Outdated
| @@ -371,6 +371,11 @@ if (WIN32) | |||
| endif() | |||
|
|
|||
| if (MSVC) | |||
| # Disable some warnings | |||
| target_compile_options(dolphin-emu PRIVATE | |||
| /wd5054 # operator '+': deprecated between enumerations of different types (types defined in Qt headers) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed when you already disable all warnings in external code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw shouldn’t be required anymore as qt fixed their code
|
I did some profiling and I think some more easy-ish big speed boost opportunities are:
|
|
FYI to get this to build on VS2022 with Qt6 I had to add a for each config -- Additionally, I had to make an empty |
|
The |
You tried this PR rebased on master? But, setting it in CMAKE_PREFIX_PATH instead of X_DIR is fine (actually what Qt docs recommends), anyway.
Here is the full mkspecs dir (for x64 only) (it seems the install target of Qt generates it, so I was wrong that it's only an empty file). However, it is still qmake-centric, besides |
|
Yes, this PR rebased on master. And no clue what files it wants from there, it seems to build fine even with none of them. |
|
2e9375b if you want to cherry-pick the Qt6 fixes. |
9c16112
to
401a983
Compare
CMakeLists.txt
Outdated
| project(dolphin-emu) | ||
|
|
||
| if (MSVC) | ||
| set(CMAKE_C_STANDARD 99) | ||
| set(CMAKE_CXX_STANDARD 20) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://stackoverflow.com/a/64890021 seems the way to do this is to set CXX to 23 and remove the explicit "latest" option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what it's worth as written it seems to work, I get -std:c++latest in the build command line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\share\cmake-3.22\Modules\Compiler\MSVC-CXX.cmake has this:
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.29.30129)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-std:c++20")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-std:c++20")
set(CMAKE_CXX23_STANDARD_COMPILE_OPTION "-std:c++latest")
set(CMAKE_CXX23_EXTENSION_COMPILE_OPTION "-std:c++latest")
elseif(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 19.12.25835)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-std:c++latest")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-std:c++latest")
endif()which is i guess what causes just set(CMAKE_CXX_STANDARD 23) to enable latest on current version
|
@shuffle2 I think I'm done for now, do you want to review? |
CMakeLists.txt
Outdated
| set(CMAKE_C_STANDARD 99) | ||
| set(CMAKE_CXX_STANDARD 23) | ||
| set(CMAKE_CXX_STANDARD_REQUIRED ON) | ||
| set(CMAKE_CXX_EXTENSIONS OFF) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
afaiui, this causes cmake to pass Za for C++ sources(?), something that msbuild setup is currently not doing. It's probably better to leave out for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, this option does absolutely nothing on MSVC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove it then?
CMakeLists.txt
Outdated
| @@ -244,16 +258,70 @@ elseif(CMAKE_GENERATOR MATCHES "Visual Studio") | |||
| add_compile_options("/MP") | |||
| endif() | |||
|
|
|||
| if(CMAKE_C_COMPILER_ID MATCHES "MSVC") | |||
| if(MSVC) | |||
| if(POLICY CMP0091) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the check should be against cmake version instead (3.22 aligns with our current VS requirements, 3.20 is required for CMP0117 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what advantage this has. By saying if (POLICY CMP0117) we state exactly what we care about -- the policy existing -- and not some arbitrary CMake version that could mean anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I said this because I’d prefer
cmake_policy(VERSION ${CMAKE_VERSION})
but if that’s not done then checking against highest policy we manually enable is fine I guess
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in, always set all policies supported on whatever the current CMake versions is on? That seems dangerous and very much invites the behavior changing invisibly when you upgrade CMake, which is kinda what policies are designed to avoid. I'd be okay with cmake_policy(VERSION 3.22) (which is the version currently used by VS), though, after testing it works with our files anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes - the thing is that for msvc we know/expect cmake to be the one that gets installed by VS installer. So it's not a random version. I think cmake "getting out of the way" and behaving natively as the one that is installed with msvc is more intuitive and requires less code, but explicitly specifying the version is fine, too (we just have to bump it whenever we bump msvc min version).
anyway, how it is now is fine.
0ad1f11
to
020c55d
Compare
|
@shuffle2 One more check please? I'd like to get this merged so this actually builds on master. |
I have no idea why cmake supports PUBLIC on target_sources, but it does. It causes all targets that depend on this target to try and include the files in their sources. Except it doesn't take paths into account, so it breaks. Mabye it would work if you used an abolute source? But I'm not sure there is a sane usecase.
Since we also treat all warnings as errors, we need to ignore these to successfully build.
I'm not sure if the previous implementation ever worked.
If you don't set this policy, then cmake doesn't even try to select a runtime library
Ninja puts way more effort into compiling targets in parallel, and ignores dependenceis until link time. So we need to jump though hoops to force ninja to compile pch.cpp before any targets which depend on the PCH.
We need these policies, but we kind of want to avoid requiring cmake 3.15 for all platforms
…ke build process wants them.
… VS project files.
020c55d
to
d40009f
Compare
ce02e5d
to
580c721
Compare
There appeared to be quite a bit of bitrot
And I'm not sure if PCH support ever worked, I had to completely rewrite it to get it working.