[David Abrahams] > ... > I can't make sure that my users can't run into problems without > understanding everything about Python and Posix which causes the rule > to exist in the first place (and I don't), and continuously monitoring > Python into the future to make sure that the distribution of Posix > configuration information across its headers doesn't change in a way > that invalidates previous assumptions. Well, we're in the same boat: we can't ensure that Python users can't run into problems without knowing everything about how the union of all flaky platform headers (not just POSIX) will work for all time either. We do know that, historically, we've been able to hack around all problems that have arisen by sticking Python.h first. There's no guarantee that will always work, though. > The current rule doesn't work for me, It doesn't work for us either, at least not on principle. It just happens to have "been enough" in practice so far. > but I'd like to be following _some_ sanctioned rule to reduce the > chance of problems today and in the future. I'm making an educated > guess that the rule is much more-sweeping than Python development > needs it to be. Isn't there some Python internal configuration header > which can be #included first and which will accomplish all the same > things as far as system-header inclusion order is concerned? Sorry, I don't know. I do know that changes to the headers are usually followed by problems on some handful of systems that can't be predicted in advance. I'll note that life is much easier if you drop support for all systems other than Win32 <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4