kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Cirilo,

I finally got around to pushing all of your patches.  Thank you for
fixing this.

Cheers,

Wayne

On 3/8/2017 9:56 PM, Cirilo Bernardo wrote:
> I think I've got something that works now.  The _D patch attached fixes
> the UTF8 issues in kicad2step provided the patch to the wxWidgets
> header (also attached) is applied.  If the wx patch is not applied then
> the kicad2step code is technically fixed in kicad but will not work due
> to wx - however, the build is not broken on any platform/toolchain.
> 
> The wx patch (or something similar to it) will hopefully be applied by
> the wxWidgets team but in the meantime we can patch the wx/app.h
> header on our Windows builds. Patching of this header file does not
> require any recompilation of wx components and the patch should be
> entirely transparent to all existing projects which use
> wxIMPLEMENT_APP_CONSOLE. The wx patch has been tested on
> both MinGW32 and MinGW64 and has no effects on any other
> platform/toolchain.
> 
> - Cirilo
> 
> On Thu, Mar 9, 2017 at 9:50 AM, Cirilo Bernardo
> <cirilo.bernardo@xxxxxxxxx> wrote:
>> On Thu, Mar 9, 2017 at 7:53 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>> On 3/8/2017 3:18 PM, Cirilo Bernardo wrote:
>>>> On Thu, Mar 9, 2017 at 3:18 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>> Cirilo,
>>>>>
>>>>> For what it's worth, it almost seems like it would have been less work
>>>>> to just export the step file directly from pcbnew rather than the effort
>>>>> you made to get all of this to work.  I do have a few comments below.
>>>>>
>>>>> On 3/8/2017 8:33 AM, Cirilo Bernardo wrote:
>>>>>> I'm confident that I can now fix all remaining non-ASCII
>>>>>> filename issues in KiCad *and* use the correct initialization
>>>>>> macro in kicad2step (wxIMPLEMENT_APP_CONSOLE).
>>>>>>
>>>>>> This will require some coordination in order to avoid
>>>>>> breaking the automatic build for Windows.
>>>>>>
>>>>>> Step A: Implement the patch attached to fix the wxWidgets
>>>>>> header 'wx/app.h'.
>>>>>
>>>>> Did you cherry pick this patch from upstream wxWidgets?  If not, did you
>>>>> test it to ensure that it did not break anything else?  I don't know if
>>>>> it makes sense or not to create a pull request with the msys2 project to
>>>>> patch wxWidgets.  I don't want to be responsible for breaking existing
>>>>> code but I would rather not have to maintain my own custom build of
>>>>> wxWidgets on msys2 either.  Also, if this isn't cherry picked from
>>>>> wxWidgets, you probably should file a bug report with this patch as a
>>>>> potential fix.
>>>>>
>>>>
>>>> The patch is not from wxWidgets but I've posted to the appropriate
>>>> open wxWidgets ticket. There is a side effect that the patch will
>>>> break the build of any wxWidgets console app which uses
>>>> wxIMPLEMENT_APP_CONSOLE *and* does not already pass the
>>>> -municode flag to the GCC linker.
>>>>
>>>> I've just got some feedback on wxWidgets that the patch won't
>>>> work because MinGW32 doesn't provide wmain() and the devs
>>>> aren't keen on making people use the -municode flag on MinGW64.
>>>
>>> I kind of see their point.  I figured it was a long shot but it was
>>> worth a try.
>>>
>>>>
>>>>
>>>>>>
>>>>>> Step B: Push the *_C patch to fix UTF8 problems in kicad2step
>>>>>> and ensure that kicad2step and idf2vrml build with the already
>>>>>> patched wx header. Ignore previous related patches; this _C
>>>>>> patch has them all.
>>>>>
>>>>> Will this patch break kicad2step and idf2vrml without the patch above
>>>>> applied to wxWidgets?
>>>>>
>>>>
>>>> Yes; without the wxWidgets patch passing -municode will break
>>>> kicad2step and idf2vrml ('wmain not defined'). If we still support
>>>> Win32 then these patches aren't helpful at all at this point.
>>>>
>>>> There is one more scheme I can investigate which might work on
>>>> MinGW32 as well. Sorry about all the noise. I hope I can find a
>>>> solution which fixes the problem in wxWidgets so we're not left
>>>> with ugly workarounds.
>>>
>>> Please investigate.  Your current solutions are not the most desirable
>>> option.  If it's a last resort, then maybe we can live with it but it
>>> would be nice not have a custom wxWidgets on mingw if we don't have to.
>>>
>>> I wonder if this issue applies to all externally launched applications
>>> (python scripts, xsltpoc, etc.) on mingw not just kicad2step and idf2vrml.
>>>
>>
>> I agree; we don't want a custom wx on MinGW32/64; having an OCE hack
>> is bad enough.
>>
>> I'm looking into this and currently setting up MinGW32 as well so I can
>> test my solutions more before proposing another patch. I'm still hoping a
>> simple patch to the wx/app.h header is all that is needed. I've implemented
>> a workaround in idf2vrml and kicad2step as a proof of concept, but it's
>> an ugly and cumbersome workaround.
>>
>> The issue affects all external wxConsoleApps.  I'm also aware of a few
>> of my own tools like dxf2idf which do not use wxConsoleApp but are
>> nonetheless broken in the same way. If there is no great urgency to
>> fix the problem I may take a week or two to review all our external apps
>> and fix them up.
>>
>> - Cirilo
>>
>>>>
>>>> - Cirilo
>>>>
>>>>>>
>>>>>> Once that is done, all the major filename problems in MinGW
>>>>>> will be fixed and I will continue to fix up the IDF tools which
>>>>>> seem to be rarely used but do contain UTF8 problems.
>>>>>>
>>>>>> - Cirilo
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp