-
Notifications
You must be signed in to change notification settings - Fork 70
Description
Description
fsyacc build incorrectly determines that output is already built, when the output has a non standard name
Repro steps
Please provide the steps required to reproduce the problem
-
create a project
foo.parser.fsy
-
add a build rule to the project that emits an output with a non default name e.g.
<FsYacc Include="foo.parser.fsy">
<OtherFlags>--module Foo.Parser -o Foo.Parser2.fs</OtherFlags>
</FsYacc>
- touch the expected default name
touch foo.parser.fs
- build project
dotnet build -v d
Expected behavior
dotnet build
will run fsyacc
and emit foo.parser2.fs
output file.
Actual behavior
Build process skips running fsyacc
because the default output foo.parser.fs
already exists
Target "CallFsYacc" in file "/home/runner/.nuget/packages/fslexyacc/11.3.0/build/FsLexYacc.targets" from project "/home/runner/work/<foo>.fsproj" (target "Compile" depends on it):
Skipping target "CallFsYacc" because all output files are up-to-date with respect to the input files.
Known workarounds
Don't do something like this and leave an earlier file lying around with the default output :( - sorry this is kind of self inflicted but it took me an hour to work out why the project wouldn't build in CI but would locally. When it checked out under CI, the earlier parser output would get a different timestamp than it had locally and the build would fail in CI and work locally. It was only asking for detailed output that I realized the foo.parser.fs
file was blocking generation. Easy to rename but if the user asks for an explicit -o
output, that should be the test. Might be hard to do in msbuild?
Related information
- linux
- dotnet 7.0.x 8.0.x