Ben Reser wrote:
>On Fri, Feb 27, 2004 at 07:41:56AM +0100, Branko ??ibej wrote:
>
>
>>>I really dislike having binaries up that don't work. If it doesn't work
>>>it shouldn't be posted. People depending on the bindings for viewcvs
>>>are going to upgrade under the presumption that everything they need is
>>>ready to upgrade...
>>>
>>>
>>>
>>>
>>That's what the issue tracker is for.
>>
>>
>
>That's funny but I don't think the average user is giong to look at the
>issue tracker to see that some binary package is broken. Furhter, it's
>not in the issue tracker. Never was. We got it fixed and taken care of
>without needing to put it in there.
>
>
Well for goodness' sake, where else are they going to look? We have a
bug in one module in 1.0.0; It's been fixed on the mainline, and will be
fixed in 1.0.1, and the fact will be apparent from the 1.0.1 CHANGES
file. In the meantime, the issue tracker is the only place where bugs
against released versions can be logged, so perhaps there should _be_ an
issue about this, with a 1.0.1 milestone, marked as resolved with a
pointer to the two patches.
This is how we've done things before, this is how 99% of the projects I
know do things.
>>The patch is Python-specific; Python defines PY_LONG_LONG, so I'd expect
>>we'd always map 64-bit types to that.
>>
>>
>
>No it isn't. It applies to both the Python and the Perl bindings. You
>just don't happen to have Perl bindings on Windows.
>
>
Oh, right, I was confused by the python-specific %typemap; the %apply of
course affects all bindings. Sorry.
Anyway, the patch still won't handle all Unices supported by APR correctly.
>However, PY_LONG_LONG is just a macro for long long.
>
As a matter of fact, it's not. PY_LONG_LONG is a macro fot _some_ 64-bit
type. It may be defined to "long long" on your platform, but not on
mine; e.g., there _is_ no "long long" on Windows.
> The problem is
>that causes a warning because on LP64 systems APR_INT64_T is *NOT* a
>long long but just a long.
>
>
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 28 00:59:46 2004