BIND 10 #2026: [kean] detect Py_hash_t in ./configure and define it internally if not

[BIND 10 Development]

#2026: [kean] detect Py_hash_t in ./configure and define it internally if not
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  UnAssigned
            Priority:  high          |                       Status:
           Component:  build system  |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20131015
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by kean):

 * owner:  kean => UnAssigned


Comment:

 Replying to [comment:4 muks]:
 > What the description suggests is detecting the presence of `Py_hash_t`
 instead of doing this version check hack. As an example, the current code
 will fail for future major versions of Python.
 I don't think it's a "hack" at all. Whether or not a new major version of
 Python comes along is meaningless, we only support Python 3.

 > In general, we should avoid testing for operating systems, versions and
 such if we are able to test for bugs, issues and features directly. It
 will handle regressions, issues with new platforms, etc.
 In general, I agree. In this specific case I do not. We only support
 Python 3, the issue is only extant in minor versions < 2, so the test as
 it currently stands is perfectly valid. It also keeps the issue
 centralized, as opposed to spread across different languages and systems.
 To put the change in configure means that pydnspp_common.h has to change
 to pydnspp_common.h.in, and get generated by configure with the
 appropriate typedef. That's a lot of churn in the source for something I
 just don't see as being a problem.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2026#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development