build: improve the Linux aspect of things #75
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Tachi107
force-pushed
the
build-linux
branch
2 times, most recently
from
47c3662
to
f0c8e63
Compare
|
Putting this on hold until #78 is resolved. |
|
Can you set |
Sure. But note that this is not ready yet. |
|
Here's the error I'm currently facing: |
|
Maybe don't use the find module from CMake (used by default if both find and config modules are present), but force the config file from the wxWidgets package? And... more problems :p
|
|
abouvier's Details
|
|
@robertkirkman what version of fmt are you using? |
On Arch Linux we have both progresses further, and then fails with this, which might be equivalent to the error you posted: Details
|
Yes, the error is the same. @abouvier, any clue? |
wxWidgets has a Config file only if built with CMake, but it is not its default build system and thus not widely available. I'll add an extra check for the Config file though.
Oh, I've just discovered that imgui doesn't have a canonical build system, so every distro does things differently... I'll try to find a solution to this.
Thanks, I'll fix this too.
Please fix this in Arch, the exported target should be named |
|
Getting this error while trying to run cmake: Did anyone manage to build with this branch on Arch? I do have the |
To get to the same point as the others (wxwidgets link errors), I did this: https://clbin.com/n1R7j, then compiled with the arguments I mentioned above. Note that this is a "on the fly" edit just for Arch Linux that isn't good for anything else. |
Check added. Could you check if this fixes the build for you? |
I tried both ed4331b and 501e920 and (after applying the mentioned patch) both of them fail with the same error that begins with "undefined reference to wxGLCanvas". here is a full paths list for the current releases of |
|
I think I now understand why the linking is failing... The FindwxWidgets module is not passing the needed linking flags. On my system it is passing This should be fixed in the latest commit. |
|
Unfortunately 7b851bc is still failing for me with the same error. I am updating with |
Does your system ship a CMake Config file for wxWidgets? If so, it is possible that you also have to explicitly link to wx::gl and wx::propgrid. I'll look into this tomorrow |
based on your suggestion I executed Details
I ran the binary again without recompiling and on the second attempt, the game launch was successful and I am in-game. This is the first time I've noticed a build without |
|
@robertkirkman could you confirm me that with 534a6ac the build links successfully? |
working around only fmt7/imgui/pugixml/glm, it does link successfully now and can launch games as well |
This comment was marked as resolved.
This comment was marked as resolved.
Tatsh
reviewed
Aug 28, 2022
Tatsh
reviewed
Aug 28, 2022
| target_link_libraries(CemuBin PRIVATE pugixml pugixml::static pugixml::pugixml) | ||
| target_link_libraries(CemuBin PRIVATE SDL2::SDL2 SDL2::SDL2main) # is SDL2main needed? |
There was a problem hiding this comment.
I have to remove SDL2::SDL2main on Gentoo to get past this line.
Tatsh
reviewed
Aug 28, 2022
|
Right now fmt version incompatibility is the biggest issue. It is not possible (or worth it) to downgrade. |
Tatsh
added a commit
to Tatsh/tatsh-overlay
that referenced
this pull request
Aug 28, 2022
|
I'm sorry, it took me some time to find and test build settings that are exactly the same between the two branches in the two repositories, but get as far as possible in the build process in both, within the constraints under which the failure occurs in
Result of above
Result of above: successful build and link RendererShaderVk.patch
CemuLogging.patch
|
|
@robertkirkman thanks for your really detailed build logs. It really seems that your build is using fmt 9. Do you have it installed on your system? I'm starting to think that the issue is that I forgot to add I'll try to check if this is the case. Edit: yeah, it seems that Edit 2: addressed in 3a3cff9 |
|
Thanks to 0f24b06 the glslang issues should be now gone (hopefully) |
on Arch Linux there is |
|
Awesome, thanks for the feedback! This PR is still a mess (albeit it solves some issues), but I'll soon start to clean things up and make this ready for merging. |
Tachi107
force-pushed
the
build-linux
branch
3 times, most recently
from
0c8fca8
to
ce910ce
Compare
This is a big rework of how dependencies are handled internally. All the calls to CMake functions changing directory-wide properties that were previously used to link to external and internal dependencies have been replaced with their "target_" counterparts. This makes it possible to express more clearly the relationships between different targets and should also make the build script more robust in general. In doing this, I've also made it possible to link to system libraries if so desired; the versioned calls to find_package() will make sure that the found dependencies are compatible with the ones required by Cemu, and will abort the build otherwise. Cemu's internal targets are deeply interconnected, making it hard to fully benefit from a target-based approach. Nonetheless, I did my best to mark PUBLIC dependencies as such, for example when an internal target like CemuGui exposes a dependency as part of its API, i.e. it includes a third party header in one of its public headers. This will significantly help with improving the build experience on Linux, thus helping a bit with the resolution of cemu-project#1.
|
This should be now ready. Compilation works with and without vcpkg (I've not worked around Arch Linux's missing I still have some minor CMake tweaks and cleanups in my local branch, but I'm going to submit them as a separate PR. Thanks to everyone who helped with this! Maintainers, please see the commit message of 9fabba1 for some more information about this PR |
|
Gave this one a try because it's the next logical step for my own PKGBUILD but it still required some tweaks to get going. Quite a few of the "new" dependencies are AUR-only so to me it would make more sense to have them as submodules or have a mix between distro packages and vcpkg (which might already be possible, I haven't tried it yet). That's obviously out of scope, just my view on this. Unfortunately my main benchmark game (BOTW) is a stuttery mess (it freezes for many seconds at times) but that's probably because I was reckless with my edits. Will invesitgate that tomorrow. Anyway, besides that I still think it's ready for merging. Thanks for your work @Tachi107. |
Closed
|
I'm having linking issues with building on openSUSE Tumbleweed, can anyone helpe me? cmake completed, I tried to build with ninja: Sorry for the big log. |
|
There's was another user in our discord who had similar issues on Fedora. Would you perhaps know the reason for it @Tachi107? Is there maybe something wrong with linking to fmt from vcpkg with this commit? |
|
@Crementif he's using vcpkg to build (or at least that's what it seems
from the logs and the build command used), so I have no idea what's
happening :/
@YuriTheHenrique, could you also include the CMake log?
…--
OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
|
|
@Tachi107 Yes, I'm using vcpkg, Here the logs: I can try to building without vcpkg if you wish. |
Using clang++ (12 or 14), I had to comment these lines from "src/Cemu/Logging/CemuLogging.h": GCC works without changes |
These don't look like full logs. Also, you should include CMake's console output.
In theory building without vcpkg currently works (if dependencies are satisfied), so it shouldn't be needed. Anyway I'm not personally interested in fixing vcpkg, nor I know enough about it to understand while it is failing. You may have better luck asking the Cemu's developers, as they say that vcpkg is the supported build method (see #107) |
|
@Tatsh I found out why on Gentoo you needed to remove |
This was referenced Aug 31, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is still a work in progress, and is likely going to conflict with #9 (Cc: @Zopolis4)
With this PR I aim at making Cemu's build script more compatible with how Linux operates, so this mainly means that system dependencies will be used when possible.
I'll split the changes in different commits on purpose, so please don't squash this on merge.
Could potentially fix #1.