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

Support CMake on Windows #8087

Merged
merged 18 commits into from May 14, 2019

Conversation

6 participants
@spycrab
Copy link
Contributor

commented May 8, 2019

Less intrusive version of the previous PR that relies on Visual Studio's CMake integration.

Use at least Visual Studio Update 1 Preview or later!

@spycrab spycrab referenced this pull request May 8, 2019

Closed

Use CMake on Windows #8068

14 of 14 tasks complete
@NarryG

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

Outside of lots of warnings when building externals, everything appears to be working as expected (from the standpoint of someone developing a fork) this time around (2019 preview 2).

I only have two real gripes:

  • I use portable mode for development purposes. I like having a different config so I don't mess with my normal Dolphin config when doing development. Since cmake nukes the entire build folder rather than just the output files (like "clean" in a normal VS project does), this isn't possible without adding my own build-step to copy the output files. Not a major issue, but something to note.

  • My fork utilizes C++/CLI to rig things up to some C# libraries. Previously, I'd directly reference the binaries but that's not possible any more. I can still make it build, but intellisense isn't smart enough to realize what's going on. That's a me problem, but it is something to note. C++/CLI is in maintenance mode so I'm not surprised it doesn't play nicely with cmake integration, but it is something to note for the future (certain features, extensions, etc may not play nicely with cmake). Managed to get this working with some finagling. Just needed to reference the binaries differently for Intellisense to pick up on them.

"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"inheritEnvironments": [ "msvc_x64_x64" ],
"buildCommandArgs": "-m -p:PreferredToolArchitecture=x64",
"buildRoot": "${workspaceRoot}\\build",

This comment has been minimized.

Copy link
@riking

riking May 9, 2019

Contributor

should this use build-debug instead?

This comment has been minimized.

Copy link
@NarryG

NarryG May 9, 2019

Contributor

should this use build-debug instead?

Debug builds on Windows build into the same folder under the name "DolphinD" rather than using a separate build folder so this won't cause any issues. The current implementation keeps that behavior.
https://github.com/spycrab/dolphin/blob/e3805b71f1d9ee879ba2bbbfd5fd2a5f563ee2ce/Source/Core/DolphinQt/CMakeLists.txt#L160-L164

This comment has been minimized.

Copy link
@spycrab

spycrab May 9, 2019

Author Contributor

Yeah, what NarryG wrote.

This comment has been minimized.

Copy link
@stenzek

stenzek May 11, 2019

Contributor

This seems to create problems with debug and release builds coexisting. One overwrites the other?

How about instead of copying the binaries to the build directory, we use the install step to copy everything into /Binaries?

This comment has been minimized.

Copy link
@spycrab

spycrab May 11, 2019

Author Contributor

It really shouldn't, as the debug binary is named DolphinD and the release one just Dolphin.

This comment has been minimized.

Copy link
@stenzek

stenzek May 12, 2019

Contributor

I'm referring to the the intermediate/object files, not the resulting binary.

This comment has been minimized.

Copy link
@spycrab

spycrab May 13, 2019

Author Contributor

Well it would probably act just as it would when you reconfigure your CMake project under Linux.

@BhaaLseN
Copy link
Member

left a comment

Thanks for getting back to the VS Integration topic! Haven't tried it yet, but the majority looks like the same old space/tabs thing from the other PR.

Perhaps we should change CMakeLists.txt in the .editorconfig so it enforces the space-indent instead of the tabs it specifies right now (which seem to be ignored for the majority of CMake files anyways)?

Show resolved Hide resolved Source/Core/Common/CMakeLists.txt Outdated
Show resolved Hide resolved Source/CMakeLists.txt Outdated
Show resolved Hide resolved CMakeLists.txt Outdated
@@ -9,6 +9,11 @@
#include <string>
#include <vector>

#ifdef _WIN32
// TODO: Horrible hack, remove ASAP!

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN May 9, 2019

Member

This was mentioned on the other PR already, but could you add some more detail to this comment why the hack is necessary?

This comment has been minimized.

Copy link
@stenzek

stenzek May 11, 2019

Contributor

Wild guess, it's to do with the CreateDirectory macro. I'd propose renaming the function instead.

This comment has been minimized.

Copy link
@spycrab

spycrab May 11, 2019

Author Contributor

Outside of the scope of the PR IMO.

Show resolved Hide resolved Source/Core/DolphinQt/CMakeLists.txt Outdated
Show resolved Hide resolved Source/Core/DolphinQt/CMakeLists.txt Outdated
Show resolved Hide resolved Source/Core/UICommon/VideoUtils.cpp

@spycrab spycrab force-pushed the spycrab:cmake_win2019 branch from e3805b7 to 6f05b5d May 9, 2019

Show resolved Hide resolved Source/CMakeLists.txt Outdated
Show resolved Hide resolved Source/CMakeLists.txt Outdated
@@ -9,6 +9,11 @@
#include <string>
#include <vector>

#ifdef _WIN32
// TODO: Horrible hack, remove ASAP!

This comment has been minimized.

Copy link
@stenzek

stenzek May 11, 2019

Contributor

Wild guess, it's to do with the CreateDirectory macro. I'd propose renaming the function instead.

Show resolved Hide resolved Source/Core/Common/CMakeLists.txt Outdated
Show resolved Hide resolved Source/Core/DolphinQt/CMakeLists.txt Outdated
@spycrab

This comment has been minimized.

Copy link
Contributor Author

commented May 11, 2019

@NarryG

I use portable mode for development purposes. I like having a different config so I don't mess with my normal Dolphin config when doing development. Since cmake nukes the entire build folder rather than just the output files (like "clean" in a normal VS project does), this isn't possible without adding my own build-step to copy the output files. Not a major issue, but something to note.

This issue is actually caused by Visual Studio, not by CMake. For some reason, whenever a CMake file changes it gets completely reconfigured and regenerated from scratch. I guess they delete the directory contents as one step of that

@NarryG

This comment has been minimized.

Copy link
Contributor

commented May 11, 2019

@NarryG

I use portable mode for development purposes. I like having a different config so I don't mess with my normal Dolphin config when doing development. Since cmake nukes the entire build folder rather than just the output files (like "clean" in a normal VS project does), this isn't possible without adding my own build-step to copy the output files. Not a major issue, but something to note.

This issue is actually caused by Visual Studio, not by CMake. For some reason, whenever a CMake file changes it gets completely reconfigured and regenerated from scratch. I guess they delete the directory contents as one step of that

Odd. Microsoft does what Microsoft does. I can easily work around it. Was just something of note to bring up.

Outside of that, from my standpoint, everything has been working well. It is annoying that VS has to do those huge regenerations compared to what it had to do with an SLN, but it's manageable on my system. Not sure what someone developing on a lower-powered system would think of it though.

@spycrab spycrab force-pushed the spycrab:cmake_win2019 branch from 6f05b5d to 2d8c0b3 May 11, 2019

@spycrab spycrab force-pushed the spycrab:cmake_win2019 branch from 2d8c0b3 to ba83cec May 11, 2019

@altimumdelta

This comment has been minimized.

Copy link

commented May 14, 2019

To be sure, so we can just rebase WIP PR's without much hassle after this gets merged, until the existing vcxproj removal?

@spycrab

This comment has been minimized.

Copy link
Contributor Author

commented May 14, 2019

@altimumdelta Yes that shouldn't pose a problem.

@spycrab spycrab merged commit ec73406 into dolphin-emu:master May 14, 2019

10 checks passed

default Very basic checks passed, handed off to Buildbot.
Details
lint Build succeeded on builder lint
Details
pr-android Build succeeded on builder pr-android
Details
pr-deb-dbg-x64 Build succeeded on builder pr-deb-dbg-x64
Details
pr-deb-x64 Build succeeded on builder pr-deb-x64
Details
pr-freebsd-x64 Build succeeded on builder pr-freebsd-x64
Details
pr-osx-x64 Build succeeded on builder pr-osx-x64
Details
pr-ubu-x64 Build succeeded on builder pr-ubu-x64
Details
pr-win-dbg-x64 Build succeeded on builder pr-win-dbg-x64
Details
pr-win-x64 Build succeeded on builder pr-win-x64
Details

@spycrab spycrab deleted the spycrab:cmake_win2019 branch May 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.