martin@v.loewis.de (Martin v. L=F6wis) writes: > 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?) I'm asking you to tell me. Maybe it's pyconfig.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. That's a helpful nugget. So which Python header(s) are responsible for LFS selection? --=20 Dave Abrahams Boost Consulting www.boost-consulting.com
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