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

DolphinQt: Add support for a Steam Runtime build #10462

Merged
merged 9 commits into from
Jun 7, 2022

Conversation

OatmealDome
Copy link
Member

@OatmealDome OatmealDome commented Feb 18, 2022

This PR adds an easy flag to disable/enable things necessary for a Steam build, and makes changes to DolphinQt to create a build that will run in the Steam Runtime.

I built and tested this PR with Steam Runtime version 1, scout, using the revision currently being used in general availability with the Steam client (which is what Valve recommends for games).

Building

Building Dolphin for the Steam Runtime is just like building for a regular Linux system. However, it must must be done within the Steam Runtime environment to prevent system libraries leaking into the application. A chroot environment or Docker container can be used, as outlined here.

Some extra CMake flags are required to produce a Steam Runtime build, as some libraries included in the runtime are too old. The recommended cmake configuration command is:

cmake .. -G Ninja -DCMAKE_C_COMPILER="gcc-9" -DCMAKE_CXX_COMPILER="g++-9" -DENABLE_EVDEV=OFF -DENABLE_LLVM=OFF -DUSE_SHARED_LIBPNG=OFF -DSTEAM=ON -DENABLE_SDL=ON -DCMAKE_PREFIX_PATH=/path/to/qt

Running

Running a build can occur on any Linux machine. However, it is not possible to run Dolphin within the chroot environment or the Docker container used for building, due to libusb initialization on startup.

First, make sure the scout runtime is installed. This can be done by copying and pasting the following into the address bar

Then, run the build:

./steam-runtime/run.sh ./dolphin-emu

Acknowledgements

Thanks to delroth, Techjar, and Warepire for their help getting DolphinQt working.

@OatmealDome OatmealDome marked this pull request as draft February 18, 2022 19:22
@OatmealDome OatmealDome marked this pull request as ready for review February 20, 2022 23:36
@OatmealDome OatmealDome changed the title CMakeLists: Add support for a Steam Runtime build DolphinQt: Add support for a Steam Runtime build Feb 21, 2022
@leoetlino
Copy link
Member

This is going to massively bloat Externals/ -- currently the Qt submodule already wastes 0.5GB of space on macOS and Linux.

Would it be possible to pull in the Qt libs at build time using CMake rather than a submodule (similar to how MoltenVK is downloaded only when necessary)?

@OatmealDome
Copy link
Member Author

@leoetlino I think it should be possible. A separate git repository would probably need to be created for this, though (I can set one up on my account for now)

@OatmealDome
Copy link
Member Author

@leoetlino I had a look at turning the submodule into an ExternalProject, but it seems that the git clone step is executed only on build time, so finding Qt fails when CMake runs. Not sure there's a workaround for this, but maybe I missed something.

@leoetlino
Copy link
Member

Looks like there are alternatives to ExternalProject if you just want to clone a repo at configure time (rather than at build time): https://stackoverflow.com/a/51311151/1636285

Forgot that CMake would need to find Qt at configure time and so downloading Qt at build time would be too late, my bad.

@AdmiralCurtiss
Copy link
Contributor

As far as I know, the modern CMake way to do this is FetchContent.

@OatmealDome
Copy link
Member Author

@leoetlino @AdmiralCurtiss I had no idea this existed - thanks! I've updated the PR to use FetchContent.

@shuffle2
Copy link
Contributor

shuffle2 commented Mar 16, 2022

What is the story with SteamOS and packaging Qt (is it based on debian/ubuntu, idk)? If you are building Qt from source, maybe just start with a Qt6 ?
edit: oh, from the PR comment, I take it SteamOS is based on Ubuntu 12.04? lol...

@OatmealDome
Copy link
Member Author

@shuffle2 Not SteamOS, but the Steam Runtime. The Steam Runtime provides a stable environment with common libraries and tools which can be built against. When a native Linux application is downloaded from Steam, the client downloads the Steam Runtime and runs the application in it. It's not distro-specific.

More info here: https://partner.steamgames.com/doc/store/application/platforms/linux and https://github.com/ValveSoftware/steam-runtime#introduction.

The new SteamOS on the Deck is Arch-based, but I think the older ones are Debian or Ubuntu based.

(Also, isn't Dolphin incompatible with Qt6? I have no experience with creating Qt applications)

@shuffle2
Copy link
Contributor

shuffle2 commented Mar 16, 2022

@shuffle2 Not SteamOS, but the Steam Runtime. The Steam Runtime provides a stable environment with common libraries and tools which can be built against. When a native Linux application is downloaded from Steam, the client downloads the Steam Runtime and runs the application in it. It's not distro-specific.

OK, but for this discussion it basically means we cannot rely on Steam OS and/or Runtime to provide a recent version of Qt, so we must build it ourselves, right?

(Also, isn't Dolphin incompatible with Qt6? I have no experience with creating Qt applications)

see #9669 (specifically #9669 (comment) ) - it's not hard to enable qt6 compat, but we are currently blocked on debian packaging of qt6 taking a long time.

I'm just wondering if:

  1. some trouble for Steam port can be saved by directly going to Qt6 there (presumably won't have to worry update it for a long time / reduce git size of submodule)
  2. Qt build for Steam could be reused for other *nix targets. Maybe this can be a workaround for distros being so late to ship Qt6.

Not saying Qt6 stuff needs to be tied to Steam support in any way, just suggesting that it might make things easier in the long run, but idk 🤷‍♂️

@OatmealDome
Copy link
Member Author

@shuffle2

OK, but for this discussion it basically means we cannot rely on Steam OS and/or Runtime to provide a recent version of Qt, so we must build it ourselves, right?

Yes, I had to build it myself. The Runtime doesn't ship with a copy of Qt.

Qt build for Steam could be reused for other *nix targets. Maybe this can be a workaround for distros being so late to ship Qt6.

During testing for this PR, I at one point ran Dolphin outside of the Runtime (with the Runtime-compiled Qt and Manjaro system libraries) and it crashed.

@shuffle2
Copy link
Contributor

During testing for this PR, I at one point ran Dolphin outside of the Runtime (with the Runtime-compiled Qt and Manjaro system libraries) and it crashed.

Sounds funky!

@delroth
Copy link
Member

delroth commented Mar 18, 2022

Similar to my comment on #10516, let's try to avoid hiding too much magic/implicit behavior behind a STEAM_RUNTIME flag. Stuff like "not linking with libpng" should be separate options that we happen to enable on the SteamRT builder by default.

We probably still want some flag to have cmake copy the right files to generate an "app bundle" for SteamRT, but that flag should be additional behavior, not controlling behavior re: dependencies and such. Does this make sense?

@OatmealDome
Copy link
Member Author

OatmealDome commented May 15, 2022

I solved the FileSystemTests failure while under the steamrt in cd6f27d1, but I'm honestly not sure why reshuffling the code like that fixes it.

The problem appears to involve accessing free'd memory in FstEntry.name during SaveFst(). A valgrind output can be found here.

@OatmealDome
Copy link
Member Author

OK, I think this is about ready now. Addressed all comments, cleaned up the commits, and the unit tests no longer fail when running them within the runtime.

I've been uploading builds made with this PR to Steam and they seem to work fine.

@JMC47
Copy link
Contributor

JMC47 commented May 28, 2022

@dolphin-emu-bot rebuild

@@ -607,6 +607,12 @@ if (CMAKE_SYSTEM_NAME STREQUAL "Linux" AND STEAM)
BUILD_WITH_INSTALL_RPATH true
INSTALL_RPATH "\$ORIGIN/lib"
)

add_custom_command(TARGET dolphin-emu POST_BUILD
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this isn't done all the time? Is Qt managed by the system or do we have a special build like on Windows?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no Qt present in the steamrt, so yes, we provide our own build. It's not in a submodule, though. I believe we will just have it on the builder.

@@ -593,6 +593,22 @@ else()
install(TARGETS dolphin-emu RUNTIME DESTINATION ${bindir})
endif()

if (CMAKE_SYSTEM_NAME STREQUAL "Linux" AND STEAM)
# Set that we want ORIGIN in FLAGS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could possibly use BUILD_RPATH_USE_ORIGIN though that wouldn't allow you to disable the tags...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I tried that earlier and it used RUNPATH?

const auto it = std::find_if(old_parent->children.begin(), old_parent->children.end(),
GetNamePredicate(split_old_path.file_name));
if (it != old_parent->children.end())
{
*new_entry = *it;
new_entry->data = it->data;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it doesn't matter but this is different behavior than before because all of the FstEntry isn't copied. It'd be nice to keep the copy constructor behavior. What was the ut failure?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

data, children, and name (which we don't care about because it's the old name) are all the members of this struct.

Any test that attempted using Rename would crash when running it within the steamrt. I posted a valgrind output in a comment above.

@JMC47
Copy link
Contributor

JMC47 commented Jun 7, 2022

Looks like reviews have essentially finished. I asked a couple of times if anyone else had any qualms and/or concerns, and no one has spoken up. Let us get the ball rolling.

@JMC47 JMC47 merged commit daf8e3d into dolphin-emu:master Jun 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.