kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.

> 
> - 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