fsprojects / FsLexYacc

Lexer and parser generators for F#
http://fsprojects.github.io/FsLexYacc/
MIT License
206 stars 69 forks source link

Check for output already built ignores -o flag #213

Open daz10000 opened 2 months ago

daz10000 commented 2 months ago

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

nojaf commented 1 month ago

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