← Back to team overview

kicad-developers team mailing list archive

Re: Rev 2784 broken

 

On 02/02/2011 02:48 PM, Dick Hollenbeck wrote:
> On 02/02/2011 01:54 PM, Jerry Jacobs wrote:
>> On 2/2/11 8:50 PM, Dick Hollenbeck wrote:
>>>> make: *** [all] Error 2
>>>> I saw Dick changed some of this code and now the OS X build is broken
>>>> with wxWidgets 2.9.2 svn
>>>>
>>>> Regards,
>>>> Jerry Jacobs
>>> $ wx-config --list
>>>
>>>      Default config is gtk2-unicode-release-2.8
>>>
>>>    Default config will be used for output
>>>
>>>    Alternate matches:
>>>      base-unicode-debug-2.8
>>>      base-unicode-release-2.8
>>>
>>>
>>> ==================
>>>
>>> Jerry,
>>>
>>> Every so often this is going to pop up as long as you continue to use the 8
>>> bit wxString.  I don't mind it if you don't.  It is a result of wxString()
>>> honoring a constructor in one mode that it does not in another build mode.
>>>
>>> Jean-Pierre says we should only support UNICODE mode.  I do not agree with
>>> him on that subject, mostly because the default build mode of wxWidgets
>>> 2.9.x on Linux is "UTF8 encoded 8 bit mode", and this is a new schmancy mode
>>> other than ANSI mode, and other than UNICODE mode.
>>>
>>>
>>> We definitely need as many wxString build modes as we they can think of.
>>> Someone once said that hindsight is 20/20, but here I doubt that.  Another 6
>>> or 8 wxString modes would be even better   :)
>>>
>>>
>>> If you can occasionally ring this bell, and not get frustrated, we will
>>> always be able to work through it.  I note that this is the 2nd time this
>>> month you've had to ring the bell.
>>>
>>> Again, I don't mind if you don't.
>>>
>>> Dick
>> white:~ jerry$ wx-config --list
>>
>>      Default config is osx_cocoa-unicode-static-2.9
>>
>> Don't scream to soon that it is a compiler problem... maybe it is a real 
>> wxWidgets problem (again), and we have to poke the people at wx maybe?
>>
>> I only build in Unicode mode.
> Well we still have no clear understanding, I do need your compiler version
> please.
>
> Thanks.
>
> Dick

OK, my best guess at this point is that wxString( const char * ) constructor
does not exist in 2.8.8, which is what I use normally.  This was finally
added in 2.9.x, which is a good thing, but it should have been there since
day one. 

So this DIFFERENCE

    i.e. the new-ness of wxString( const char* )

can cause different tolerances regarding the ambiguity errors you have been
seeing and I have not been seeing.

Now all I have to do is remember this, without screaming.  :)


Dick





References