In 5.7.1 when using an <Option /> in BuildGraph and setting the value to the relative path to a file there is a behavior change where the value of the <Option> is turned into the absolute path to the file than the passed-in string.
For example from the provided reproduction case in 5.7.1 the value of the option “ProjectFile” becomes “D:\src\lyra-57\Lyra\Lyra.uproject”, but in 5.6.1 the value of the option is unchanged “Lyra\Lyra.uproject”.
Is there a way to ensure that a passed in value to an <Option /> remains the provided string in 5.7.1?
Steps to Reproduce
A minimal reproduction case is attached. Run the following, setting the ProjectFile to a file that exists on disk:
.\RunUAT.bat BuildGraph -Script="repro.xml" -set:ProjectFile="Lyra/Lyra.uproject" -Target="NoOp"
In 5.6.1 the value of the ProjectFile option is logged unchanged, in 5.7.1 it is converted into an absolute file reference (if the file exists).
Reproduction BuildGraph:
<?xml version='1.0' ?>
<BuildGraph xmlns="http://www.epicgames.com/BuildGraph" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.epicgames.com/BuildGraph ../Schema.xsd" >
<Option Name="ProjectFile" DefaultValue="" Description="Path to the project file. Can be used instead of specifying ProjectName and ProjectPath separately."/>
<Agent Name="Default Agent" Type="NoOp">
<Node Name="NoOp">
<Log Message="ProjectFile $(ProjectFile)" />
</Node>
</Agent>
</BuildGraph>
It seems that this only happens if the name of the option is “Project*”.
It looks like the new behavior may have been introduced in CL 44345166 (https://github.com/EpicGames/UnrealEngine/commit/603c4db56c576953dbcfa87a05a624e16f94c38d).
There’s a workaround, by naming the option something else.
As a heads up this may affect the behavior (subtly) of Engine/Build/Graph/Tasks/BuildAndTestProject.xml which accepts a “ProjectFile” option or other BuildGraph that uses a similar approach.
This was an intentional change, but I didn’t know it would impact licensees. ProjectFile, ProjectName, ProjectDir are now intended to be reserved keywords with the full path semantic. We added them so that they would be available for the scripts that need them (such as the new IncrementalValidate script) even in cases where only -project flag is present.
Sorry for the unintended impact on your scripts; Is the rename solution sufficient for your case?
Yes, we can rename options and properties to work around this. Would it be possible to have BuildGraph include a Warning or Error when setting a <Option /> that will conflict with the reserved keywords? That would have at least made the change more obvious and easier to debug.
That does look like it could potentially break anything using/including the current BuildGraphs, or anything modelled after the current BuildGraphs…
Status on the warning or error: Yes, we should be able to implement a warning or error when declaring an Option or Parameter with a reserved keyword. I’m still checking on ETA for when we can get that done.
[Content removed] a sufficient workaround for affected licensees when integrating to 5.7?
just got this when i clicked into this from my email, looks like some code errors in the forum?
I could see anything that extends/includes BuildAndTestProject or is a direct copy of it with things added, might possibly lead to problems, as whatever gets called with those parameters might not like absolute paths, or someone might be resolving an absolute path out of it already.. I’d have to audit it to see if there’s any actual breakage, but at a glance, I agree with Lucian that BuildAndTestProject would be affected, and maybe others, so someone extending that could be affected.
I wasn’t able to get the warning implemented yet, and the issue has not been reported in the months since January, so I’m dropping the plan to add the warning. We can reevaluate and get it done if this comes up as a continuing problem for developers.
