Originally posted by Hi-Angel
View Post
Lot of things other project can do wine cannot due to having to replicate the behaviours of MSVC on GCC or needing ablity to build code back on MSVC to test stuff.
Originally posted by Hi-Angel
View Post
Yes you can alter using #pragma GCC optimize where it using particular standards. Doing to cover the areas demanding gnuxx then you find out that using standard mode in gcc for c89, c99 and c11 either the standard problems or gcc has problems with what wine requires but it works fine as long as you stick to the gnu versions. So quite painful.
Originally posted by Hi-Angel
View Post
I can example after example. Every case you had a group of users claiming this is better of this stack of applications merge it. But after enough stubbornness and sticking to rules as wine does normally a developer who take correct method re-implements and that feature gets merged into wine better than it ever was.
Wine is test driven development. This means if you break test with your patches and are unable to demo that under windows that is the right behaviour so the test was wrong your code will be rejected and it will not matter what other merits you think the code has its now dead in the water. This is why wine project has a staging branch these days for unable merged patches working to get to conditions to be merged..
Compiler standard selection is all about allow testing and replicating required behavours.
Now of course due to be test driven development lot of the developers don't exactly know why they are doing something with wine. All they know is they are doing it so they don't break tests. I do more support so having to explain to people why their patches are being stone walled is something I have to-do at times. Also having to explain wine compiler choices. The person who taught me most of this is the wine project official history writer. Yes it kind of strange to need to talk the historian to work out why stuff is done the way it is. Heavy test driven makes lot of wine project selections a matter of historic record of where something was tested and it failed do going that way was forbid and if it tested now and proven to work that forbid status can be removed.
So wine demos the price of being test driven to the point of removing most personal options from development. Its a common in most projects that selections are made from personal points of view. Personal points of view inside wine development model 99.9% of the time mean absolutely nothing it can you back that with test results please not when wine project wants test results they want the full wine test-suite to run with no new errors unless they are new tests.
Even code attempted to be submitted by codeweavers(they pay the maintainer his wage) cannot be accepted if it breaking the testsuite. There are no real wiggle room for anyone wanting to patch code in wine on this point. This lack of wiggle room means wine project does not get bogged down in political arguments or attempting to argue with the maintainer most of the time. Yes gallium nine developer did make the mistake of thinking wine issue were political.
Looking for political reasons for wine selection in this is a huge waste of time because they are not there.
Comment