Download

UBT and undocumented switches - I need help

Hey fellas,

I’ve had some trouble getting UBT to work properly in all cases, such as foldernames with spaces and projects in symlinks. So, one fine morn I decided to dig into its source and see what I could do about it. Hoo boy, was I in for a ride.
UBT is a right mess, and I’m appalled and shocked at some of the code in it. It’s a story for another day (and I’ll probably do a proper writeup on it fairly soon), but the end result is that I’m currently rewriting large portions of UBT with the intent of improving the CLI handling and general performance of the program.

However, I’ve run into a bit of a snag. Many of the options (actually, practically all of them) in UBT are undocumented, and I’ve discovered more about the different operation modes it can enter than I’d ever wanted to x) There are a few of these that I simply can’t wrap my head around completely for lack of examples and external data, and I really need someone who knows their ins and outs to answer some questions. If you know UBT like the back of your hand, please god help - I’m confused about the following bits (off the top of my head and the // TODO list):

  • How does UBT handle building of multiple targets using the “-targets” switch? Do you have an example of an input file for this mode? How does it function with other options?
  • Can UBT build for multiple platforms in one run? Some code suggests this, some does not.
  • Can the “-define” switch appear more than once? Does it point to a folder, a file, something else?
  • What does “-ignorejunk” even do?
  • What does “onlyplatformspecificfor” do?
  • Is “nohotreloadfromide” telling UBT to not accept hot reloads from the IDE, or that this invocation is not a hot reload from the IDE?
  • What does “autosdkonly” do?

I have way more stuff I’m confused about than this, and some methods I want to know more about as well. Please, help a poor idiot get his **** straight :stuck_out_tongue: If you want to see what I’ve done so far, the branch is available here on GitHub (requires engine access, of course): https://github.com/Nihlus/UnrealEngine/tree/ubt-bettercli

Plans are still in flux, but I’m intending to do a big refactor of UBT shortly. It is a mess, you’re right. It gets pulled in a lot of different directions for esoteric features and platform-specific special cases, and they often aren’t factored in with a consistent vision. I have grand plans for restoring it to its former glory though!

To answer your questions:

Support for building multiple targets in one run is pretty broken right now. I’m not sure it ever worked 100%; there are way too many global/static variables to encapsulate this right now. This is something I want to fix soon though.

Yes, that should work. IIRC it’s at odds with how we usually pass arguments in UE4 because the parameter is separated into its own argument (eg. “-define A=1 -define B=2”)

The junk manifest is a utility to ensure that out of date intermediates and build products get cleaned up. It’s needed less now than it used to be, because we ensure that we don’t load out of date editor binaries by validating against the .modules files in the output directories. The -ignorejunk flag is just there to skip checking for and deleting that stuff.

Originally, I think the purpose of that flag was to build each specific target platform orthogonally. We don’t use it any more, and it’s on the list to be deleted.

It’s telling UBT not to try and detect a running editor and generate a hot-reload DLL (one with a numeric suffix).

The “AutoSDK” feature is something we use internally to ensure that people have the correct platform SDKs installed. It allows a platform that you’re building for to call a batch file to validate and install the correct SDK for a branch (which is in a folder synced from source control). IIRC, the -autosdkonly flag is used to invoke UBT from the editor and update any necessary SDKs at editor load time.

Hi Ben,

Thank you very much for the information! If you’re about to start refactoring UBT, we should probably collaborate on that so as not to do double work :slight_smile: I’ve already done a substantial amount of work on unifying the command-line options in one place, as well as normalizing style problems and dividing up large methods into smaller ones. I’ve actually got an almost-finished report on my changes typed up, if you want to get an overview of all of the changes.