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:  kean
                Type:  defect        |                       Status:
            Priority:  high          |  reviewing
           Component:  build system  |                    Milestone:
            Keywords:                |  Sprint-20131015
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  UnAssigned => kean


Comment:

 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.

 A suitable fix would be to check if code with `Py_hash_t` compiles
 successfully at configure time, and if not, `typedef` it to the `long`
 type. This typedef can occur in `pydnspp_common.h` itself for now as it is
 central enough. But instead of the version test, check the result of the
 test in `configure`. This ticket was created for doing that.

 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.

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