[PyKDE] module versioning and ISO types (size_t, ptr_diff_t, ...)

[Phil Thompson]

On Wednesday 21 January 2004 7:06 pm, Gerard Vermeulen wrote:
> Hi,
>
> I am somewhat confused with respect to sip's new module version, like
>
> %Module qtnetwork 0
>
> In PyQt-3.10, this module has been extended with new classes. Since, its
> interface has changed doesn't it mean that the 0 should be a 1?

Yes, but...

The value is used by SIP v4 (not v3) which hasn't been "officially" released 
yet. I will maintain the version number once the final v4.0 is released.

(Note that I reserve the right to completely forget to increment the version 
number from time to time - but if I do it's a bug.)

> In addition, comparing those version numbers
> (I suppose that is the
>                         /* Check the versions are compatible. */
>                         if (im -> im_version >= 0 || em -> em_version >= 0)
>                                 if (im -> im_version != em -> em_version)
>  in siplib.c)
> is moderately useful, because if for instance PyQwt has been built for a qt
> module that includes all features and it imports a qt module that has
> certain features disabled, the 'import' and 'export' tables do not match,
> leading to disaster. It also means that one is lucky if modules built on
> system X work with modules built on system Y.
>
> Wouldn't it be safer to calculate a hash number based on the class tables
> and/or the function and method declarations? If the probability of
> collision between the hash numbers is very small,  (im_hash == em_hash)  is
> a good test of compatibility.

Given my anticipated failure to change the version number when necessary, your 
suggestion is a good one - patches welcome :)

> Secondly, I would make a case that sip passes ISO C types like size_t,
> ptrdiff_t on from the sip specification files to the generated C++ code.
> The reason is that size_t can be an 'unsigned int' (Linux) or an
> 'unsigned long' (HPUX).  Of course,  PyQwt could try to figure out
> what type size_t exactly is, but if sip pretends to wrap C libraries
> it may as well do it.

Agreed - patches welcome :)

Phil