Re: wxWidgets 2.9 build

On Sat, Jan 29, 2011 at 6:08 PM, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> We're following the documented way of getting 2.8 and 2.9
> compatibility here. I generally dislike using macros for things like
> this when working in C++.

Similarly, I dislike uglifying code if we can help it - and this seems
like a common enough case to me that a macro isn't the end of the
world to improve readability.

What do others think?

>> Also, did you change all of the variadic calls? I still see a
>> wxLogInfo with a .c_str() parameter in pgadmin/db/pgConn.cpp:169 for
>> example.
>
> No, I didn't. I left it up to my compiler. Note that the wx built-in
> functions like wxLogInfo are defined using macros to construct each
> variant in /wx/log.h . The calls I fixed are to variants of our own,
> similarly defined using macros in sysLogger.h, but with a different
> function signature to the 2.9 wx ones. Ours (which is behaviourally
> identical to wx 2.8's) is:
>
> extern void wxLog##level(const wxChar *szFormat, ...)
> COMPAT_ATTRIBUTE_PRINTF_1 // remember I created the compatibility
> macro COMPAT_ATTRIBUTE_PRINTF_1?

Ahh, yes.

> Obviously the wx guys were aware of the need to change their
> implementation to prevent the c_str() proxy ambiguity thing happening
> to their clients. What do you want to do about it? I'm not aware of
> there being an official way to extend the wx logger functionality.

No, I don't think there is. I guess we'll need to replicate the 2.9
signatures/macros if we're building against 2.9. Ugly, but it should
be fairly self-contained.

>> On VC++ 2008, I get the following warnings:
>>
>> Warning 1       warning C4800: 'const wxChar *' : forcing value to bool
>> 'true' or 'false' (performance
>
> Oh yeah, I know the C4800 warning well. I'm glad to see it, because it
> has revealed that I've introduced a bug, which nicely answers my
> earlier question of "why does sysSettings::Write(const wxString&,
> const wxChar*) take a const wxChar* as its second argument rather than
> just a wxString?". We're calling the wrong overload where we don't
> supply a wxString directly, because C++ prefers converting to a
> built-in type to converting using a class constructor with a wxChar*
> argument. I'm going to change the bool overloads and perhaps others to
> functions with distinct names. Things are obviously too brittle as
> they stand. Objections?

Urgh. But I suppose we'll have to.

>>> or would were it not for OGL and Flex/Bison issues with 2.9.
>>
>> Whats the plan with OGL? I think we should get a list of all the
>> committers to it (excluding the bakefile, which we don't need), and
>> email them, explaining that Julian has given permission to relicence
>> the code, and asking if they'll be kind enough to do the same.
>>
>> Thoughts? Do you want to do that, or should I?
>
> I imagined that you wanted to use your legal resources to make sure
> that it was done the right way,

Our legal resources are, umm, overstretched to say the least. I'm not
sure they'd tell us anything other than to get the authors' permission
anyway.

> but I don't mind doing the ground
> work. Will I go ahead with it? The problem with asking me to do it is
> that I will split hairs to be on the very safe side, which may not be
> necessary. I suppose I can just consult you if I hit a snag.

Well, how about starting by figuring out who we need to contact (and
let's keep that private). Then, between us we can draft an email to
sent to those people, and if any of them respond in a less than clear
fashion, we can figure out how to deal with them individually.

Sound OK?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company