Package Details: unreal-engine 5.5.0-0

Git Clone URL: https://aur.archlinux.org/unreal-engine.git (read-only, click to copy)
Package Base: unreal-engine
Description: A 3D game engine by Epic Games which can be used non-commercially for free.
Upstream URL: https://www.unrealengine.com/
Keywords: 3D engine game ue5 Unreal
Licenses: GPL3, custom:UnrealEngine
Submitter: acerix
Maintainer: Shatur
Last Packager: Neko-san
Votes: 76
Popularity: 0.053868
First Submitted: 2016-05-01 18:37 (UTC)
Last Updated: 2024-11-16 03:10 (UTC)

Dependencies (29)

Required by (1)

Sources (6)

Pinned Comments

Neko-san commented on 2022-11-01 02:32 (UTC) (edited on 2023-06-25 01:19 (UTC) by Neko-san)

@juancarlospaco this is easily done on your own system, not in a PKGBUILD, given that building packages runs as root:

sudo groupadd unrealengine-users
sudo usermod -aG unrealengine-users (your-username)
sudo chown -R root:unrealengine-users /opt/unreal-engine
sudo chmod -R 775 /opt/unreal-engine

Permission issues like this are already mentioned on the UE Arch wiki page: https://wiki.archlinux.org/title/Unreal_Engine_4#Installing_from_the_AUR

This is a user system problem; I already did what I could without needing users to do the above by giving the 777 permissions. If it still gives you trouble, you'll have to use the example to solve it or change the install location to somewhere you have user permissions by default (as I cannot do this for you).

zerophase commented on 2021-05-27 08:15 (UTC) (edited on 2021-05-30 08:41 (UTC) by zerophase)

Will update to 5.0 when it is released.

Latest Comments

« First ‹ Previous 1 .. 27 28 29 30 31 32 33 34 35 36 37 .. 82 Next › Last »

Shatur commented on 2021-07-18 15:59 (UTC) (edited on 2021-07-18 16:10 (UTC) by Shatur)

@zerophase, I don't think this is a good idea. UAT is the preferred way for binary deployment. It also doesn't require any additional dependencies. According to my observations, it not only builds the project and removes all unnecessary junk, it also creates a special file that forces UBT not to check the changes in the engine. It just my observation, maybe it does something else! Doing all this stuff manually simply not worth it. And it will be hard to maintain.

Also I do not think that hardcoding the number of threads by default is a good idea :) You can simply use MAKEFLAGS as I do. I bet the users want to have an unmodified version of the engine. Check out our conversation @OdinVex.

--march=native is good for building the engine itself, but building projects using this flag is bad because they will be tied to the CPU it was built on.

zerophase commented on 2021-07-18 15:23 (UTC)

I would go back to using make for building, and just run all of the UAT stuff manually. All you're doing is abstracting package maintenance into the automation system, which requires dependencies to use. I guess just diff the directory differences, and just remove the unneeded files during the package step.

There's a 30 thread limit put in to cap how high the multiplier scales for systems with less cores, while maintaining responsiveness. If you need more than thirty cores, build manually with makepkg, or let paru manage your local PKGBUILD with git. That multiplier is there to speed up compilation, as much as possible, without negatively impacting the responsiveness of said system. It's not our responsibility to maintain the PKGBUILD for your specific system.

-march=native is fine for compiling for most newer cpus, and should only be turned on if you're willing to test it. Works perfectly fine for Haswell and Broadwell cpus. Plus you need to pass a command line argument to enable it. I turned on looking for bugs with other cpus, as it got accepted upstream. Maintaining and patching the Unreal Build System is the solution, not MAKEFLAGS. UBT manages each subproject, and won't necessarily play nice with variables from outside.

OdinVex commented on 2021-06-25 22:55 (UTC) (edited on 2021-06-25 23:15 (UTC) by OdinVex)

@Shatur, It is almost always a plugin, such as under Marketplace. We have to make everything, so we'll usually j# once, maybe twice, then j1. I just wish UE could spend a day going through themselves to allow j# and simply fix compile-order for j1-required pieces and allow plugin developers to specify an override for j just in case. It'd alleviate about 5 minutes of work each, for ours. (The waiting and going back and forth. My compiles usually take about 4-6 minutes, but I've got some decent hardware.)

Shatur commented on 2021-06-25 22:25 (UTC) (edited on 2021-06-25 22:34 (UTC) by Shatur)

@OdinVex :D No issues. Yes, we now have a stock build with some options disabled by default. The engine is now properly packaged for distribution and takes much less space.

I've always had to customize the pkgbuild to undo that bit but I don't mind too much.

This is weird... Could you try the latest version? I also had problems when I called make -j8. But if I call a specific target, for example make -j8 UnrealEditor, then everything works correctly. But in the new method, make itself is not called directly. If you still need to control this, then use the variable MAKEFLAGS.

OdinVex commented on 2021-06-25 22:17 (UTC) (edited on 2021-06-25 22:21 (UTC) by OdinVex)

@Shatur, I may need to eat foot here, I could have sworn those were being added. The business with BuildConfiguration.xml modifications and such. prepares knife and fork for foot And no, j# will not always work. Sometimes things change (plugins for example) and they break with j# and need j1. Stock is make, not specific make. I've always had to customize the pkgbuild to undo that bit but I don't mind too much.

Shatur commented on 2021-06-25 22:12 (UTC) (edited on 2021-06-25 22:13 (UTC) by Shatur)

I'll just create a repo for stock-build for my own team and just use that.

But we use stock-build too...

We use make because we use all of UE.

If you need to change the engine itself - yes, this is a good idea. BTW, if you want to build with -j# - simply build every target separately - it will work corerctly.

I really don't understand you :)

Shatur commented on 2021-06-25 22:07 (UTC) (edited on 2021-06-25 22:13 (UTC) by Shatur)

@OdinVex, Sorry, but I don't understand your suggestion about it. We had patches that forces specific CPU instructions for building projects (-march=native), number of cores (can be done from the user side using MAKEFLAGS) and hardcoded number of maximum threads. I simply removed all this custom stuff.

OdinVex commented on 2021-06-25 22:03 (UTC) (edited on 2021-06-25 22:07 (UTC) by OdinVex)

@Shatur, I'm talking about your number 3's changes for cores/threads. If you want to increase the limit, fine, dynamically patch the code for the host CPU, maybe, otherwise I don't see any valid reason to change it. I'll just create a repo for stock-build for my own team and just use that. We use make because we use all of UE.

Shatur commented on 2021-06-25 21:55 (UTC) (edited on 2021-06-25 22:02 (UTC) by Shatur)

@Shatur, UE is meant to be compiled almost entirely with j1 because of plugins, third-party to the engine and market/user. Historical problems with UE not forcibly overriding j for specific stuff and plugins not always being able to specify it too. Some versions pass wonderfully, some don't. Rare, but it happens. Perhaps an option to ask if we'd like extra pass on compilation after each compilation might suffice for you to change the default behavior? UE has historically managed j itself where appropriate. A bit tired, not really looking at what commits were there or not before, only gave a quick glance at the Changes.

I can't reproduce your issue. Also this is how it was before my changes. BTW, Unreal handles threads correctly if it compiles one target at a time. I assume that you are using make -j# (building all targets at a time), if yes - you shouldn't. New method also handles it correctly.

Not sure where there is some 30-thread limitation...

Take a look at BuildConfiguration.xml, MaxProcessorCount field.

I'm firmly against commit 0017ada0056f, it has nothing to do with being Intel/AMD-specific or anything, just about how many threads/cores are used to compile when compiling shaders during IDE runtime, etc. This is something that belongs in user-builds, not a pkg.

Look closely, -march = native instructs the compiler to generate CPU-specific code. It also unnecessary because users can use MAKEFLAGS.

OdinVex commented on 2021-06-25 21:48 (UTC) (edited on 2021-06-25 21:56 (UTC) by OdinVex)

@Shatur, UE is meant to be compiled almost entirely with j1 because of plugins, third-party to the engine and market/user. Historical problems with UE not forcibly overriding j for specific stuff and plugins not always being able to specify it too. Some versions pass wonderfully, some don't. Rare, but it happens. Perhaps an option to ask if we'd like an extra pass on compilation after each compilation might suffice for you to change the default behavior of a project which has the potential to give end users issues just because you want this? (Not saying I don't want it, I usually do j# continuously until it builds, but it is non-default and can break compilation until all things compile. Users shouldn't need to debug a pkg install that fails (and the pkg may think it succeeded when it failed) and then attempt to each time modify the pkgbuild until they figure out how many j#s it takes for everything to compile because of some project or plugin or piece of code requires j1. Maybe someday a whitelisting of 'known to be compatible with j#' sections can be added, I'd be in full support of that but for now, maybe just ask the user and give the option of a j# or j1 compile AND ask the user if it failed and if they'd like to try again and which method to use. Most compatible and most compromising, I think. UE has historically managed j itself where appropriate, but overriding it can fail some things. A bit tired, not really looking at what commits were there or not before, only gave a quick glance at the Changes.

« First ‹ Previous 1 .. 27 28 29 30 31 32 33 34 35 36 37 .. 82 Next › Last »