Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for output already built ignores -o flag #213

Open
daz10000 opened this issue Jul 14, 2024 · 1 comment
Open

Check for output already built ignores -o flag #213

daz10000 opened this issue Jul 14, 2024 · 1 comment

Comments

@daz10000
Copy link

daz10000 commented Jul 14, 2024

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

  1. create a project foo.parser.fsy

  2. 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>
  1. touch the expected default name

touch foo.parser.fs

  1. 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
@nojaf
Copy link
Collaborator

nojaf commented Aug 5, 2024

This seems reasonable to fix, are you interested in sending a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants