David Abrahams <dave@boost-consulting.com> writes: > The current rule doesn't work for me, 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? I can't think of a less strict rule that is still comprehensible. I did not comprehend the wording that you first proposed, since it referred to preconditions that are fuzzy (what is xxxx.h?) If you come up with a wording of a less strict rule, I can try to guess whether that rule would also work, on the systems I care about. In drafting such wording, keep in mind that the primary motivation for this rule is LFS support, where Python wants to select the 64-bit API (aka "large file") on systems that support that. So any system header that could potentially be affected by LFS selection can only be included after LFS selection has been done. Regards, Martin
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