Arch Linux User Repository

@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).

Will update to 5.0 when it is released.

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 :)

@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.

@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, 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.

@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.

@Shatur Well, I guess I'll have to create a clone of this repo and provide my own patches, then. Perhaps you can put your own build-customization into another pkg. Let the users decide to customize inste...

What build customization do you meant? All of them are disabled by default. Except the fix for GenerateClangDatabase.

UE can be mostly compiled with -j# but some things cannot be built on first run that way and need -j1. I usually run a -j# then again until they succeed.

I just successfully built it on 24 cores without any issue.

Not sure where there is some 30-thread limitation... I also don't see any CPU-specific stuff, considering Intel and AMD builds will run on one another fine. >_>

It was there. I removed this stuff.

Nice work on fixing GenerateClangDatabase and the mono+ccache work. Appreciate the true/false values too. ;)

The mono and ccache patches were already here, I just disabled it by default.

@Shatur, Well, I guess I'll have to create a clone of this repo and provide my own patches, then. Perhaps you can put your own build-customization into another pkg. Let the users decide to customize instead... AUR would benefit from review methods. :)

UE can be mostly compiled with -j# but some things cannot be built on first run that way and need -j1. I usually run a -j# then again until they succeed. Not sure where there is some 30-thread limitation... I also don't see any CPU-specific stuff, especially considering Intel and AMD builds will run on one another fine because they both comply with x86 architecture. Even if vendor-specific flags are used, compilers generate non-vendor-specific in almost all cases. We'd be back in the sc3n3 days to expect otherwise. >_> It looks like you were looking at the default configuration of UE for thread/core utilization during runtime compilation, which should be undone. 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.

Nice work on fixing GenerateClangDatabase and the mono+ccache work. Appreciate the true/false values too. ;)

I updated the PKGBUILD. Here is what I did:

1. Switched to "Installed build" generation (https://docs.unrealengine.com/4.26/en-US/ProductionPipelines/DeployingTheEngine/UsinganInstalledBuild/). This is a preferred method of distributing the engine binaries. It takes much less space on disk (because it packages only required stuff) and this is how it packaged for Windows by Epics. The previous build method is mainly used for engine development. It also saves compilation time since UBT no longer checks for the engine code changes.
2. I removed the patch for system compiler support because it causes issues with current clang (12). Also I'm not sure if it possible to apply it to the "Installed build". But the patches in Git history and it can be reintorduced later.
3. I removed the patch that multiplies number of threads for UBT. This is unnecessary because it can be controlled by the MAKEFLAGS=-j<threads_count> environment variable. It also removes hardcoded maximum number of threads (30) and removes project buiding with native CPU instructions. It's not a good idead to build project that bound to the specific CPU by default (for example, if it was compiled on Intel, it will not work on AMD). Let's let users decide, they can easily specify all this stuff locally.
4. Applied a patch that fixes GenerateClangDatabase for Linux. The search mechanism was Windows-specific.
5. I have disabled the mono and ccache patches by default, because it will require user intervention, who cannot read the PKGBUILD carefully. Also, the dependencies for these patches are now dynamically added.
6. I changed patches switches to true / false to make it more obvious for users.
7. Installation path now also an option.
8. Minor PKGBUILD refactoring.

@zerophase, unfortunately, AUR do not have a rereview mechanism, so I did not have the opportunity to discuss the changes with you first :(

So feel free to disagree with any change and undo / remove / rework any commit that I did.

BTW, anyone that want to use UE5 now can simply change the used branch in line 52 to 5.0.0-early-access-2.

@Shatur, Thank you for pointing that out doc out, I'm most definitely interested in it. I wasn't entirely aware of non-Epic means of redistribution of binaries aside from copy-paste. :)

@zerophase, I have some suggestions:

1. Engine/Source/Programs/UnrealBuildTool/Modes/GenerateClangDatabase.cs currently have a hardcoded path to clang for Windows. How about patch it to fix database generation on Linux? Here is the changes: https://pastebin.com/mQYftFnA
2. We could use "Installed build" way to create a package. It will take much less space (~31GB unpacked). Should be done via automation tool, take a look: https://docs.unrealengine.com/4.26/en-US/ProductionPipelines/DeployingTheEngine/UsinganInstalledBuild/ (e.g. just run UnrealEngine/Engine/Build/BatchFiles/RunUAT.sh BuildGraph -target="Make Installed Build Linux" -script=Engine/Build/InstalledEngineBuild.xml -clean -set:WithDDC=false -set:HostPlatformOnly=true after Setup.sh instead of executing build manually)
3. Disable using system compiler to avoid hardcoding clang version in PKGBUILD.