Excuse me, wrong conclusions would lead me to create confusion in upstream of real wine which this repository does not represent in many ways as 'downstream fork' (later info). I need mind you that even i am a person capable to use and see Github commit history which reveals this to be totally 'yours' (this aka 'Valve' dev community from this 'fork' project) actions fault - real wine is innocent.
See this: https://github.com/ValveSoftware/wine/commit/fd582e8b15ce81532facee0f41f970176b1316d8#diff-90d08e583c4c9c6f391b2ae90f819f600a6326928ea9512c9e0c6d98e9f29ac2

TLDR; Valve 'fork' has changed how wine build system works out of source from upstream of wine
(extra notice; this Github project repository 'fork' doesnt link and or identify as a fork correctly not even towards to official wine mirror on Github but as own standalone project!): Please see example list that this is not there: https://github.com/wine-mirror/wine/forks?page=1

To fix project repository to be as real fork i suggest highly to read Github policy and follow up how to make forks: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo

So people could be talking in future events this to even being a real 'fork' of 'wine' in the first place.
Shortly this is currently 'Frankenstein hacks of - (old) wine with fake version numbering - project on Github'.

"Bleeding edge" so called 'fork' of wine' has existing issues like as example here;
Super old ffmpeg which no one sane would use in year 2025 (https://github.com/ValveSoftware/wine/issues/280), out dated OpenCL headers tried to find use etc.
Real vanilla wine versions of 9.1x even didnt have same build errors of looking out of dated library calls.

I returned to use real wine 10.15.

Thanks though for Valve and dev community greatly example funding and supporting for dxvk developer from Germany and vkd3d-proton and others for achieve huge Linux gaming improvements on past years for users and to steer people in better choices in life.

I repeat; amateur level mistakes.

This repository is not intended to be built outside of the Proton build system. If that's not what you're looking for, upstream Wine may be a better fit. I've maintained a very early Proton wine fork in the past, and everything has vastly improved since then. And others like GE or Tkg surfaced to do a much better job of maintaining and testing new patches for Proton wine, so I stopped working on it.

That said: You can still cherry pick the patches into your own "real" fork if you think some are interesting. For Proton wine it's more interesting to have a software base compatible with games and various (even very old) Steam Runtime versions. That may just not work if every library provided by Proton and this wine would be bleeding edge.

Also, the history of this fork is a bit different than you may assume. Back when it started, there was just an unmaintained auto-mirror of wine - not really an official project (and I think, this hasn't changed). And the wine project isn't even hosted on Github.

And you should think about your expectations about autogen.sh again: That is a release tool. Even the original wine project forces you to use it if you are developing with it and prepare releases. Since this fork of wine isn't meant to be released stand-alone, the Proton super project is responsible for doing that. You even found the commit for it.

But I agree that Valve could add a prominent header to the readme pointing out that this fork needs to be used from within the Proton dev environment and is not meant to be built alone. This could reduce a lot of comments like yours.

I think it's fair to say the Valve devs are far from amateurs – they are deeply involved in upstream Wine development, you even thank them for their involvement. But there is no constructive feedback in your post. So maybe the 'amateur' label points in a different direction... ;-)

Thank you for your message.. but

"autogen.sh again: That is a release tool. Even the original wine project forces you to use it if you are developing with it and prepare releases. "

*Deep Sigh of disbelief*

Not true sir please the commit proved this exact thing as false.
Example of vanilla sources: https://gitlab.winehq.org/wine/wine

I need repeat. Build system is modified in this project* which keeps my original point valid as per by your message as "valid constructive feedback" and now two senior people now confused and crumpled here with multiple false informations as they dont see the issue themselves.

*=I am not taking part:
*What to use this project for
*Should i be using this
*Proton
*Development of this
*Who using this
*How use this
*What you eat
..

I am just only pointing real valid issue:
*QUICK START is out of date (Why? ValveSoftware/wine made modifications to build system introducing autogen.sh and removing original configure script with all these COMPARED to original vanilla wine)

This could reduce a lot of comments like yours.

Okay I wont comment anymore with anything here as this is nonsense unthankful against help. I already now written way more than that one liner fix. This is useless issue section of open source.

Even usage of old ffmpeg linking issue is still valid but was just closed like that - not to show to be an issue anymore. I know, looks better. Shiny. Project is going forward yehey!

If you dont mind i will take your titles and drop them to junior level from senior officially with these level mistakes as talking is like with outsourced pc support "have you tried reboot your pc again / go away"

I think we’re going in circles here.

Yes, Proton’s Wine build system is modified compared to upstream – that’s intentional and the reason why this repo cannot be treated as a drop-in replacement for vanilla Wine. Missing configure and requiring autogen.sh is part of that difference. It’s not a mistake but by design.

That said, I do agree with your actual point: the Quick Start section could be updated to reflect this more clearly. Having that spelled out in the README would avoid confusion for others in the future.

As for the rest – titles, senior/junior levels etc. – I don’t think that helps anyone here. Let’s keep the focus on the technical part, which is: improving documentation so users know what to expect from this fork.