wait, do you have incremental linking or something like that explicitly enabled? that definitely could explain this.
aha, there we have it.. I get repro when I enable incremental linking.. at Epic no-one has incremental linking enabled
ok, I have submitted a fix for this on our devline. It will most likely not be backported anywhere and I might have to fight to get this into 5.6 since we have locked the release down.
Since binaries are backward compatible you can take code from latest Github in ~2 hours and build the binaries locally.. that should work fine.
this was the fix but it could be a bit hard to take it in isolation.. better to take it all
https://github.com/EpicGames/UnrealEngine/commit/a8fbe8545f567b7ce84b0f77ae55ad3b3abb4596
Thanks a lot Henrik!
We’re indeed using incremental linking.
I’d be interested to know why no one uses incremental linking at Epic. Do you advise against it, especially under UBA ? If that means downloading extremely large dlls and exes on the agents… yeah
That is a good question. It was turned because of
- Files are getting larger.. and Fortnite is really struggling with pdb/exe/dll sizes in general
- Because of pch and large unity files the incremental linking often get more or less entirely invalidated and then the link time actually is longer than linking from scratch.
so in some situations it is nice to use incremental linking.. but the disadvantages outweighed the advantages in our case.
Thanks Henrik, Julian,
Do you have any further recommandations/ideas about the PATH WITHOUT ROOT issue?
I’ve looked at the code in Uba tools and it looks like maybe it can be an easy fix, but I don’t know the general architecture of Uba inside out. Maybe Uba is just missing another root path in its internal list, that would account for our DNE plugins which are stored in an unconventional place, because of our patch (previously shared)?
My goal is to determine if I can modify our patch somewhat easily, or if we need to completely drop it and use AdditionalPluginDirectories instead (larger endeavor).
[mention removed] I’m not sure if you have any feedback regarding the above?
As a more general statement, I’d tend to urge folks to move away from larger divergence in tooling as it can lead to other unpredictable behaviour in dependent systems, but I can appreciate that it’s a larger effort to sunset said divergence in favour of AdditionalPluginDirectories.
oh sorry, I missed that one…
So the PATH WITHOUT ROOT means that there are references out to files that are not registered as roots to the build system.. this means that the cache entries will contain local paths which are likely not compatible with other machines unless they have identical paths.. This is how the cache system works.. it turns absolute paths into relative paths from closest root.
Sometimes, some modules refer out to external things.. in that case you must declare that in the .build.cs file. It is currently limited to only one root but you set it with “ExtraRootPath”
So looking at SuperLuminal.build.cs as an example.. it adds the “SuperLuminal” root and then register the local path to it… this means that we can go in the other direction on another machine when downloading from cache.
See if you can figure out what this is. To me it looks like DNEDialogue has some external dependencies that needs this ExtraRootPath.
Good luck 
/h
Thanks, I’ll look into it when we switch to 5.6 then, as ExtraRootPath is not available to us right now. But yeah that’s the issue: our plugins are stored in an unexpected place.
I believe you also did some work to share cache artifacts even when the absolute root path is different between machines?
Something else I forgot to report: in some source files we had fishy include directives that ended with a space after the filename. On native msvc/clang-cl this is not an issue because we didn’t notice them for years, but under UBA the compiler spits a file not found error.
#include "SomeFile.h "
>I believe you also did some work to share cache artifacts even when the absolute root path is different between machines?
Just quickly weighing in here, this is done via the -vfs option in UBT.
Julian
Will test the extra space after includes, thanks