On Tue, Jan 18, 2011 at 2:51 PM, Peter Geoghegan
<peter.geoghegan86@gmail.com> wrote:
> On 18 January 2011 09:31, Dave Page <dpage@pgadmin.org> wrote:
>>> I take it that you didn't see this Dave? I built it against 2.9, which
>>> was itself built using a shell script that's the same as
>>> ./xtra/build-wxgtk, except that I removed the contrib stuff.
>>
>> No, I didn't. FYI, I was building on Mac which tends to have it's own
>> unique set of issues due to the Universal Binaries the platform uses.
>>
>>> Should -fPIC be in our CXXFLAGS? If so, why wouldn't it be?
>>
>> I don't know - should it? We're not building any shared libraries, so
>> does it matter?
>
> I meant for OGL.
Oh, oops. Probably in that case - we should be using whatever
wxWidgets does really though.
>>> I believe that the only things standing between us and a rough 2.9 build are:
>>>
>>> 1. The linker problem above. OGL compiles acceptably.
>>
>> That'll probably fix explainCanvas and explainShape.
>
> I've e-mailed the original developer, so hopefully he'll be able to
> help on my linker problem. I asked the listed maintainer about the
> licensing thing, and I may have been wrong to be skeptical. Changing
> the licensing looks like something that could actually happen.
Oh, cool.
>>> 3. The problem with wx2stc() above. I could have fixed this by copying
>>> and pasting the tiny function which only appears in private.h in 2.9,
>>> but it that would violate the wxWindows licence.
>>
>>
>> <grumble>. So we need to convert from a wxString to a UCS2 char array.
>> http://docs.wxwidgets.org/stable/wx_wxmbconvutf16.html#wxmbconvutf16
>> seems like it might do the trick.
>
> It seems to just be used in wxStyledTextCtrl, which was contrib in
> 2.8. Now it's mainstream. We always used it though. Anyway, the reason
> we don't use what you've linked to, is, I suppose, the same reason why
> they don't in PlatWX.cpp where unicode variants of wx2stc() are
> defined:
>
> // Convert using Scintilla's functions instead of wx's, Scintilla's are more
> // forgiving and won't assert...
I'm really not sure that's an issue for us. Postgres is already strict
about UTF-8 - I don't see why we shouldn't be either (especially as
this only affects regexp searching). Unless it's asserting about
things other than invalid chars or other real problems?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company