win_bison random failure extern_stdin:40: ERROR: end of file in string

[lygstate]

https://gitlab.freedesktop.org/mesa/mesa/-/issues/13968

[vzmsk]

This problem arise then in one project multiple instances of flex are running. win_flex use same temporary filenames for all instances: and multiple instances breaks each other.

Adding getpid() in temporary filenames solve this problem

[GitMensch]

That should have been fixed with #91 ?!?
Is this a duplicate of #86 using an old version?

[GitMensch]

Answer: nope, there is no release since 2022, which was the last time that @lexxmark was active on GitHub as well...
So... building should help with that.

For some reason my Appveyor env does not work for that, but https://ci.appveyor.com/project/Croydon/winflexbison/branch/master has recent ones...

@Croydon can you please trigger a new build so that people can test those artifacts?
Should we use those as binaries for a new release?

[Croydon]

@GitMensch Do you have the permissions to go to https://ci.appveyor.com/project/lexxmark/winflexbison/settings/build ?

I believe this setting should be off so that AppVeyor is actually using the appveyor.yml config from the repository.

I hope @lexxmark is doing well, but if he isn't responding anymore at all, then we probably need a fork anyway (upstreaming in Flex and Bison itself would still be the best way).

@GitMensch do you have any way to contact him in another way than GitHub pings?

---

Somewhat off-topic: Could you take another look at #104 @GitMensch ?

[GitMensch]

Which setting? And no, I can't access that (only in my env which currently has an error).
I can do merges and releases here (everything but settings), so I'd say for now it is fine to stay here.

[Croydon]

Which setting?

There is only one setting under this URL. AppVeyor let you specify a VS project file, a custom script directly in the web interface or off which then uses the appveyor.yml file from the repository as it should be.

If it isn't that, then I have no idea what might be blocking the AppVeyor builds here, but we can't change the settings anyway, if you don't have the permissions...

[Croydon]

If we stay here, we can't (at least):

• Fix / change / enable AppVeyor builds
• Fix any GitHub settings
• Publish / fix / change Chocolatey builds

[GitMensch]

For the first part: I could still try to ask Appveyor Support do to that setting (your Appveyor works, so the other settings and config seems fine).
In general we can (and should) also activate the MSVC 2022 build on GitHGub action (another workflow file).

Second... yes. that's true (again, we could check with GH support), but for now there is no error in the settings, is there?

Why can't we do the last item?

[Croydon]

Why can't we do the last item?

I mean, can we? How does Chocolatey publishing works? How is it trigged? Is it automated? Do you have the permissions?

[lygstate]

Why can't we do the last item?

I mean, can we? How does Chocolatey publishing works? How is it trigged? Is it automated? Do you have the permissions?

Chocolatey is a older version, I get mesa works by fallback to an older vesion of winflexbison microsoft/winget-pkgs#312608

[lexxmark]

@vzmsk is right, and it hits win_bison as well: before #91 the m4 input temp file was named with a bare tempnam(NULL, "~m4_in"), which on MSVC hands every process the same candidate name (~m4_in_2). Two parallel runs pick it at the same moment and the second truncates the file the first one's m4 is reading — hence extern_stdin:40: ERROR: end of file in string.

Fixed in master by #91 (thanks @jonnysoe), which adds the pid to the name. That fix is simply unreleased: it is from 2023-03, the last tag v2.5.25 is from 2022-01. Verified on dev — 600 concurrent invocations, no failures — and covered by a regression test (winflexbison.bison_parallel).

Nothing left to fix in code; it needs a 2.5.26 release (#93).