We use BuildGraph to build and package plugins for Unreal Engine. We build against the pre-built engine from the launcher so that our plugin is ABI compatible, and to avoid developers needing to recompile the plugin after installing it.
As part of this build process, we build, cook and run a test project via Gauntlet to make sure that the built plugin works in an actual project. Our build process is distributed over multiple build machines, and as Zen is more and more “the default”, we need to be able to use the Zen import/export tasks in BuildGraph so that we can ensure that the cooked content from one node can be exported and then imported on the node that does the package/stage step. We don’t want to run cook and package in the same build job, as Android for Google Play and Quest shares the same cooked content (there is one cook job), but differs in the final package step (where it changes INI settings to target different types of Android devices).
However, the engine installed via the launcher does not contain the `zenlaunch.exe` binary, which makes the Zen import/export tasks fail in BuildGraph. There are a number of workarounds to this, but all of them would require us to proxy in our own `zenlaunch.exe` alternative to make the tasks work, since our build tooling is open source and we can’t just distribute the actual `zenlaunch.exe` to build nodes (since it is non-redistributable as per the engine EULA). It would make our lives far far easier if the installed engine in the launcher could ship with this binary instead; then we don’t need to do any kind of workaround.
This affects at least 5.7 and 5.8, and I believe 5.6 as well (though I don’t know if Zen is the default there). If this is going to be fixed in 5.8, let me know if there’s a possibility of it being addressed in a 5.7 patch release or whether I need to think about a workaround for that engine version (if it’s fixed in 5.8, we might just turn off the test that requires cook/package for 5.7).
[Attachment Removed]