You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
touch foo.parser.fs
dotnet build -v d
Expected behavior
dotnet build
will runfsyacc
and emitfoo.parser2.fs
output file.Actual behavior
Build process skips running
fsyacc
because the default outputfoo.parser.fs
already existsKnown 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
The text was updated successfully, but these errors were encountered: