[Python-Dev] more-precise instructions for "Python.h first"?

[David Abrahams]

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