Skip to content
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

Merged
merged 16 commits into from May 22, 2022

Conversation

phire
Copy link
Member

@phire phire commented Apr 27, 2022

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.

CMakeLists.txt Outdated Show resolved Hide resolved
@phire phire force-pushed the cmake_win_fixes branch 2 times, most recently from 667c830 to 50ab358 Compare April 28, 2022 17:21

# 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
Copy link
Contributor

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.

@shuffle2
Copy link
Contributor

shuffle2 commented May 9, 2022

@phire might need some tweaks since qt6 was merged

add_compile_options(/external:anglebrackets)
add_compile_options(/external:W0)

# TODO: Enable this once PR #10559 is merged
Copy link
Member

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.

@@ -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)
Copy link
Member

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?

Copy link
Contributor

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

@shuffle2
Copy link
Contributor

@phire fwiw #10652 removes the need to fiddle with ignoring warnings generated from fmt

@shuffle2
Copy link
Contributor

I did some profiling and I think some more easy-ish big speed boost opportunities are:

  • pch for C files (for externals)
  • pch for DolphinQt (including moc outputs) which includes Qt headers

@AdmiralCurtiss
Copy link
Contributor

FYI to get this to build on VS2022 with Qt6 I had to add a CMAKE_PREFIX_PATH pointing at the Qt directory, as else it wouldn't find Qt6 (even if I set Qt6_DIR). So in CMakeSettings.json add:

        {
          "name": "CMAKE_PREFIX_PATH",
          "value": "${workspaceRoot}\\Externals\\Qt\\Qt6.3.0\\x64"
        },

for each config -- ARM64 instead of x64 for the ARM builds, presumably.

Additionally, I had to make an empty mkspecs\win32-msvc in Externals\Qt\Qt6.3.0\x64, as apparently the Qt CMake files set that as an include directory? We probably should add that in the Qt repository.

@AdmiralCurtiss
Copy link
Contributor

The --no-angle also needs to be removed in the Qt deploy step, as that option no longer exists in Qt6.

@shuffle2
Copy link
Contributor

shuffle2 commented May 15, 2022

FYI to get this to build on VS2022 with Qt6 I had to add a CMAKE_PREFIX_PATH pointing at the Qt directory, as else it wouldn't find Qt6 (even if I set Qt6_DIR). So in CMakeSettings.json add:

        {
          "name": "CMAKE_PREFIX_PATH",
          "value": "${workspaceRoot}\\Externals\\Qt\\Qt6.3.0\\x64"
        },

for each config -- ARM64 instead of x64 for the ARM builds, presumably.

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.

Additionally, I had to make an empty mkspecs\win32-msvc in Externals\Qt\Qt6.3.0\x64, as apparently the Qt CMake files set that as an include directory? We probably should add that in the Qt repository.

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).
mkspecs.zip

However, it is still qmake-centric, besides mkspecs\win32-msvc\qplatformdefs.h. Is that all we need?

see dolphin-emu/ext-win-qt#19

@AdmiralCurtiss
Copy link
Contributor

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. qplatformdefs.h seems like a reasonable guess though.

@AdmiralCurtiss
Copy link
Contributor

AdmiralCurtiss commented May 15, 2022

2e9375b if you want to cherry-pick the Qt6 fixes.

@AdmiralCurtiss AdmiralCurtiss force-pushed the cmake_win_fixes branch 2 times, most recently from 9c16112 to 401a983 Compare May 21, 2022 01:31
CMakeLists.txt Outdated
project(dolphin-emu)

if (MSVC)
set(CMAKE_C_STANDARD 99)
set(CMAKE_CXX_STANDARD 20)
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

@shuffle2 shuffle2 May 21, 2022

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

@AdmiralCurtiss
Copy link
Contributor

@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)
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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 Show resolved Hide resolved
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)
Copy link
Contributor

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 )

Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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.

Source/Core/DolphinQt/CMakeLists.txt Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
@AdmiralCurtiss AdmiralCurtiss force-pushed the cmake_win_fixes branch 2 times, most recently from 0ad1f11 to 020c55d Compare May 21, 2022 13:47
@AdmiralCurtiss
Copy link
Contributor

@shuffle2 One more check please? I'd like to get this merged so this actually builds on master.

phire added 7 commits May 22, 2022 00:29
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.
@AdmiralCurtiss AdmiralCurtiss force-pushed the cmake_win_fixes branch 3 times, most recently from ce02e5d to 580c721 Compare May 22, 2022 00:07
@AdmiralCurtiss AdmiralCurtiss merged commit 0e948f3 into dolphin-emu:master May 22, 2022
10 checks passed
@phire phire deleted the cmake_win_fixes branch January 28, 2023 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
5 participants