You already do have public API even if you do not see it as such. Each module has to implement ModuleRules and TargetRules, and all the parameters that are passed to those functions inherently need to be stable or you will break people’s build scripts as they upgrade.
Ideally I’d want to make all my scripts as abstracted as possible. In my current example of copying the binaries (oftentimes DLL for third party libs) into the binary folder, i still have to create “hacks” to determine where is the output directory from the module directory. If you change anything in how the path to my binaries is generated, which you should be able to as these are temporary directories, i need to update my logic as well. There could be more examples but this is one.
You can’t tell me that using something like this is pretty :
public string GetUProjectPath()
{
return Directory.GetParent(ModulePath).Parent.Parent.ToString();
}
AFAIK there is no other clean way for me to determine output directory in my build.cs file, and therefore my module is no longer working independently of its context.
Basically instead of doing string replaces in command line arguments and having a very limited set of variables, let me access a certain set of internals from a part of UBT that is explicitly designed to be a public API. Give me methods to override for Pre/Post build steps and whatever else I would need to customize (selecting which files to include and overriding filters come to mind).
You would get a much better design, with everything pertaining to a module’s build process all in one file, all in one language, all platform agnostic. Note that this is how other popular meta-build systems work.
Honestly, even if you don’t expose anything more than you already do, having it all in c# trumps all just because it will run similarly on all platforms. I’m not sure how I could even make different scripts for different platforms with what you are giving me now.