Re: [Kicad-developers] wxwidgets fork progress

[Wayne Stambaugh]

Yes, this needs to be fixed.

On 02/12/2018 07:04 PM, Michael Kavanagh wrote:
I think the docs need to be updated to reflect these changes: 
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx


Cheers,
Michael

On 31 January 2018 at 15:24, Wayne Stambaugh > wrote:


OK, these patches have be reduced to historical footnotes.  Thanks
everyone for the feedback.

Cheers,

Wayne

On 1/30/2018 5:04 PM, Adam Wolf wrote:
 > You can remove the boost patches.  They are only of historical
 > concern, and they'll live in Git for any future archaeologist who
 > cares.
 >
 > Adam
 >
 > On Tue, Jan 30, 2018 at 3:20 PM, Jeff Young > wrote:
 >> Yeah, I didn’t patch my boost either.  (I can’t remember if I
MacPorts’d it
 >> or Homebrew’d it, but I didn’t do anything beyond that.)
 >>
 >>
 >> On 30 Jan 2018, at 21:13, Bernhard Stegmaier
>
 >> wrote:
 >>
 >> Wayne,
 >>
 >> I don’t think so.
 >>
 >> I use a stock MacPorts boost since long before you removed boost
from KiCad
 >> build.
 >> This might not be representative, but I didn’t see any problems.
 >>
 >> I had a quick look into Adams build scripts and I didn’t see
that he is
 >> building his own boost (with the patches) somewhere.
 >>
 >>
 >> Regards,
 >> Bernhard
 >>
 >> On 30. Jan 2018, at 21:58, Wayne Stambaugh > wrote:
 >>
 >> Bernhard,
 >>
 >> What about the macos boost and context patches?  Do we still need to
 >> keep them?
 >>
 >> Thanks,
 >>
 >> Wayne
 >>
 >> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
 >>
 >> Wayne,
 >>
 >> yes, from my side you can delete them.
 >> Even if deleted they are in git anyway, so we can restore them
if really
 >> needed.
 >> I’ll try to change documentation ASAP.
 >>
 >>
 >> Regards,
 >> Bernhard
 >>
 >> On 29. Jan 2018, at 19:15, Wayne Stambaugh 
 >> >> wrote:
 >>
 >> Bernhard,
 >>
 >> Am I safe deleting the macos patches from the source repo or do
I need
 >> to hold off until the dust has settle on the new wx repo?
 >>
 >> Thanks,
 >>
 >> Wayne
 >>
 >> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
 >>
 >> The full original soname patch seems to fix the issue in my
builds (I
 >> did apply only half of it to our fork because of the comments in
 >> wxWidgets trac).
 >> I pushed it to the fork.
 >> The next build should pick it up automatically and be good
again… sorry
 >> for not having checked this before.
 >>
 >> I also did set the bug to “Fix Committed”.
 >>
 >>
 >> BTW @Adam:
 >> There are still 2 wxPython macOS patches:
 >> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the
overlay
 >> stuff for wxWidgets.
 >> (2) I don’t know about the “…_multiarch.patch”. You don’t apply
it as
 >> far as I can see and it seems to be fine without?
 >>   => Still needed?
 >>
 >>
 >> Regards,
 >> Bernhard
 >>
 >>
 >> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
 >> 
>
 >> >> wrote:
 >>
 >> Just a short status…
 >> I just tried the compile_wx.sh script and it generally seems to
be fine.
 >>
 >> But, I can see that obviously the wxPython installer duplicates libs
 >> instead of symlinking them.
 >> Maybe the original soname patch we had is needed for that one to
work
 >> correctly.
 >> I’ll check…
 >>
 >>
 >> Regards,
 >> Bernhard
 >>
 >>
 >> On 29. Jan 2018, at 00:32, Adam Wolf

 >> >
 >> >> wrote:
 >>
 >> I think I see it now.  I can probably fix this tonight.  Thanks!
 >>
 >> Adam
 >>
 >> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
 >> 
 >> > >>
 >> wrote:
 >>
 >>    Quick look into the build… seems to pull in wrong 

Re: [Kicad-developers] wxwidgets fork progress

[Michael Kavanagh]

I think the docs need to be updated to reflect these changes:
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_osx

Cheers,
Michael

On 31 January 2018 at 15:24, Wayne Stambaugh  wrote:

> OK, these patches have be reduced to historical footnotes.  Thanks
> everyone for the feedback.
>
> Cheers,
>
> Wayne
>
> On 1/30/2018 5:04 PM, Adam Wolf wrote:
> > You can remove the boost patches.  They are only of historical
> > concern, and they'll live in Git for any future archaeologist who
> > cares.
> >
> > Adam
> >
> > On Tue, Jan 30, 2018 at 3:20 PM, Jeff Young  wrote:
> >> Yeah, I didn’t patch my boost either.  (I can’t remember if I
> MacPorts’d it
> >> or Homebrew’d it, but I didn’t do anything beyond that.)
> >>
> >>
> >> On 30 Jan 2018, at 21:13, Bernhard Stegmaier 
> >> wrote:
> >>
> >> Wayne,
> >>
> >> I don’t think so.
> >>
> >> I use a stock MacPorts boost since long before you removed boost from
> KiCad
> >> build.
> >> This might not be representative, but I didn’t see any problems.
> >>
> >> I had a quick look into Adams build scripts and I didn’t see that he is
> >> building his own boost (with the patches) somewhere.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >> On 30. Jan 2018, at 21:58, Wayne Stambaugh 
> wrote:
> >>
> >> Bernhard,
> >>
> >> What about the macos boost and context patches?  Do we still need to
> >> keep them?
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
> >>
> >> Wayne,
> >>
> >> yes, from my side you can delete them.
> >> Even if deleted they are in git anyway, so we can restore them if really
> >> needed.
> >> I’ll try to change documentation ASAP.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >> On 29. Jan 2018, at 19:15, Wayne Stambaugh  >> > wrote:
> >>
> >> Bernhard,
> >>
> >> Am I safe deleting the macos patches from the source repo or do I need
> >> to hold off until the dust has settle on the new wx repo?
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
> >>
> >> The full original soname patch seems to fix the issue in my builds (I
> >> did apply only half of it to our fork because of the comments in
> >> wxWidgets trac).
> >> I pushed it to the fork.
> >> The next build should pick it up automatically and be good again… sorry
> >> for not having checked this before.
> >>
> >> I also did set the bug to “Fix Committed”.
> >>
> >>
> >> BTW @Adam:
> >> There are still 2 wxPython macOS patches:
> >> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> >> stuff for wxWidgets.
> >> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
> >> far as I can see and it seems to be fine without?
> >>   => Still needed?
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>
> >> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
> >> 
> >> > wrote:
> >>
> >> Just a short status…
> >> I just tried the compile_wx.sh script and it generally seems to be fine.
> >>
> >> But, I can see that obviously the wxPython installer duplicates libs
> >> instead of symlinking them.
> >> Maybe the original soname patch we had is needed for that one to work
> >> correctly.
> >> I’ll check…
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>
> >> On 29. Jan 2018, at 00:32, Adam Wolf  >> 
> >> > wrote:
> >>
> >> I think I see it now.  I can probably fix this tonight.  Thanks!
> >>
> >> Adam
> >>
> >> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
> >>  >>  >
> >> wrote:
> >>
> >>Quick look into the build… seems to pull in wrong wxWidgets libs.
> >>The build in question includes some 3.0.0 wxWidgets libraries
> >>which I guess come from wxPython download.
> >>The fork should create 3.0.4 libraries...
> >>
> >>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
> >> >>  >
> >> wrote:
> >>
> >>I just had a quick look and it looks fine.
> >>
> >>Also my first guess is that maybe something got messed up in the
> >>folder hierarchy when copying wxPython/wxWidgets together, so
> >>that e.g. here
> >>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
> >>some wrong wxWidgets (not the one of the fork) gets pulled in.
> >>
> >>Too late here already to check just by review, will try
> >> tomorrow… :)
> >>
> >>On 29. Jan 2018, at 00:00, Adam Wolf
> >> >> 
> >>> wrote:
> >>
> >>Yeah.  

Re: [Kicad-developers] wxwidgets fork progress

[Wayne Stambaugh]

OK, these patches have be reduced to historical footnotes.  Thanks
everyone for the feedback.

Cheers,

Wayne

On 1/30/2018 5:04 PM, Adam Wolf wrote:
> You can remove the boost patches.  They are only of historical
> concern, and they'll live in Git for any future archaeologist who
> cares.
> 
> Adam
> 
> On Tue, Jan 30, 2018 at 3:20 PM, Jeff Young  wrote:
>> Yeah, I didn’t patch my boost either.  (I can’t remember if I MacPorts’d it
>> or Homebrew’d it, but I didn’t do anything beyond that.)
>>
>>
>> On 30 Jan 2018, at 21:13, Bernhard Stegmaier 
>> wrote:
>>
>> Wayne,
>>
>> I don’t think so.
>>
>> I use a stock MacPorts boost since long before you removed boost from KiCad
>> build.
>> This might not be representative, but I didn’t see any problems.
>>
>> I had a quick look into Adams build scripts and I didn’t see that he is
>> building his own boost (with the patches) somewhere.
>>
>>
>> Regards,
>> Bernhard
>>
>> On 30. Jan 2018, at 21:58, Wayne Stambaugh  wrote:
>>
>> Bernhard,
>>
>> What about the macos boost and context patches?  Do we still need to
>> keep them?
>>
>> Thanks,
>>
>> Wayne
>>
>> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>>
>> Wayne,
>>
>> yes, from my side you can delete them.
>> Even if deleted they are in git anyway, so we can restore them if really
>> needed.
>> I’ll try to change documentation ASAP.
>>
>>
>> Regards,
>> Bernhard
>>
>> On 29. Jan 2018, at 19:15, Wayne Stambaugh > > wrote:
>>
>> Bernhard,
>>
>> Am I safe deleting the macos patches from the source repo or do I need
>> to hold off until the dust has settle on the new wx repo?
>>
>> Thanks,
>>
>> Wayne
>>
>> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
>>
>> The full original soname patch seems to fix the issue in my builds (I
>> did apply only half of it to our fork because of the comments in
>> wxWidgets trac).
>> I pushed it to the fork.
>> The next build should pick it up automatically and be good again… sorry
>> for not having checked this before.
>>
>> I also did set the bug to “Fix Committed”.
>>
>>
>> BTW @Adam:
>> There are still 2 wxPython macOS patches:
>> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
>> stuff for wxWidgets.
>> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
>> far as I can see and it seems to be fine without?
>>   => Still needed?
>>
>>
>> Regards,
>> Bernhard
>>
>>
>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
>> 
>> > wrote:
>>
>> Just a short status…
>> I just tried the compile_wx.sh script and it generally seems to be fine.
>>
>> But, I can see that obviously the wxPython installer duplicates libs
>> instead of symlinking them.
>> Maybe the original soname patch we had is needed for that one to work
>> correctly.
>> I’ll check…
>>
>>
>> Regards,
>> Bernhard
>>
>>
>> On 29. Jan 2018, at 00:32, Adam Wolf > 
>> > wrote:
>>
>> I think I see it now.  I can probably fix this tonight.  Thanks!
>>
>> Adam
>>
>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>> >  >
>> wrote:
>>
>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>The build in question includes some 3.0.0 wxWidgets libraries
>>which I guess come from wxPython download.
>>The fork should create 3.0.4 libraries...
>>
>>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
>>>  >
>> wrote:
>>
>>I just had a quick look and it looks fine.
>>
>>Also my first guess is that maybe something got messed up in the
>>folder hierarchy when copying wxPython/wxWidgets together, so
>>that e.g. here
>>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>>some wrong wxWidgets (not the one of the fork) gets pulled in.
>>
>>Too late here already to check just by review, will try
>> tomorrow… :)
>>
>>On 29. Jan 2018, at 00:00, Adam Wolf
>>> 
>>> wrote:
>>
>>Yeah.  The previous build script downloaded a wxpython tarball,
>>which included wxwidgets.
>>
>>All my update did was move the wxpython subdirectory into a git
>>checkout of the wxwidgets tree, and build that way.
>>
>>One quick thing would be to just do a diff between the
>>wxwidgets included with wxpython 3.0.2.0, and the tree.  At
>>this point, nothing would surprise me :)
>>
>>Adam
>>
>>
>>
>>On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier"
>>>  

Re: [Kicad-developers] wxwidgets fork progress

[Adam Wolf]

You can remove the boost patches.  They are only of historical
concern, and they'll live in Git for any future archaeologist who
cares.

Adam

On Tue, Jan 30, 2018 at 3:20 PM, Jeff Young  wrote:
> Yeah, I didn’t patch my boost either.  (I can’t remember if I MacPorts’d it
> or Homebrew’d it, but I didn’t do anything beyond that.)
>
>
> On 30 Jan 2018, at 21:13, Bernhard Stegmaier 
> wrote:
>
> Wayne,
>
> I don’t think so.
>
> I use a stock MacPorts boost since long before you removed boost from KiCad
> build.
> This might not be representative, but I didn’t see any problems.
>
> I had a quick look into Adams build scripts and I didn’t see that he is
> building his own boost (with the patches) somewhere.
>
>
> Regards,
> Bernhard
>
> On 30. Jan 2018, at 21:58, Wayne Stambaugh  wrote:
>
> Bernhard,
>
> What about the macos boost and context patches?  Do we still need to
> keep them?
>
> Thanks,
>
> Wayne
>
> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>
> Wayne,
>
> yes, from my side you can delete them.
> Even if deleted they are in git anyway, so we can restore them if really
> needed.
> I’ll try to change documentation ASAP.
>
>
> Regards,
> Bernhard
>
> On 29. Jan 2018, at 19:15, Wayne Stambaugh  > wrote:
>
> Bernhard,
>
> Am I safe deleting the macos patches from the source repo or do I need
> to hold off until the dust has settle on the new wx repo?
>
> Thanks,
>
> Wayne
>
> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
>
> The full original soname patch seems to fix the issue in my builds (I
> did apply only half of it to our fork because of the comments in
> wxWidgets trac).
> I pushed it to the fork.
> The next build should pick it up automatically and be good again… sorry
> for not having checked this before.
>
> I also did set the bug to “Fix Committed”.
>
>
> BTW @Adam:
> There are still 2 wxPython macOS patches:
> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> stuff for wxWidgets.
> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
> far as I can see and it seems to be fine without?
>   => Still needed?
>
>
> Regards,
> Bernhard
>
>
> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
> 
> > wrote:
>
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
>
> But, I can see that obviously the wxPython installer duplicates libs
> instead of symlinking them.
> Maybe the original soname patch we had is needed for that one to work
> correctly.
> I’ll check…
>
>
> Regards,
> Bernhard
>
>
> On 29. Jan 2018, at 00:32, Adam Wolf  
> > wrote:
>
> I think I see it now.  I can probably fix this tonight.  Thanks!
>
> Adam
>
> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>   >
> wrote:
>
>Quick look into the build… seems to pull in wrong wxWidgets libs.
>The build in question includes some 3.0.0 wxWidgets libraries
>which I guess come from wxPython download.
>The fork should create 3.0.4 libraries...
>
>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
>  >
> wrote:
>
>I just had a quick look and it looks fine.
>
>Also my first guess is that maybe something got messed up in the
>folder hierarchy when copying wxPython/wxWidgets together, so
>that e.g. here
>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>some wrong wxWidgets (not the one of the fork) gets pulled in.
>
>Too late here already to check just by review, will try
> tomorrow… :)
>
>On 29. Jan 2018, at 00:00, Adam Wolf
> 
>> wrote:
>
>Yeah.  The previous build script downloaded a wxpython tarball,
>which included wxwidgets.
>
>All my update did was move the wxpython subdirectory into a git
>checkout of the wxwidgets tree, and build that way.
>
>One quick thing would be to just do a diff between the
>wxwidgets included with wxpython 3.0.2.0, and the tree.  At
>this point, nothing would surprise me :)
>
>Adam
>
>
>
>On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier"
>  > wrote:
>
>Sure.
>I’ll have a look tomorrow and try to build
>wxWidgets/wxPython the same way the script does.
>
>On 28. Jan 2018, at 23:44, Nick Østergaard
>  > wrote:
>
>You don't need 

Re: [Kicad-developers] wxwidgets fork progress

[Jeff Young]

Yeah, I didn’t patch my boost either.  (I can’t remember if I MacPorts’d it or 
Homebrew’d it, but I didn’t do anything beyond that.)


> On 30 Jan 2018, at 21:13, Bernhard Stegmaier  wrote:
> 
> Wayne,
> 
> I don’t think so.
> 
> I use a stock MacPorts boost since long before you removed boost from KiCad 
> build.
> This might not be representative, but I didn’t see any problems.
> 
> I had a quick look into Adams build scripts and I didn’t see that he is 
> building his own boost (with the patches) somewhere.
> 
> 
> Regards,
> Bernhard
> 
>> On 30. Jan 2018, at 21:58, Wayne Stambaugh > > wrote:
>> 
>> Bernhard,
>> 
>> What about the macos boost and context patches?  Do we still need to
>> keep them?
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>>> Wayne,
>>> 
>>> yes, from my side you can delete them.
>>> Even if deleted they are in git anyway, so we can restore them if really
>>> needed.
>>> I’ll try to change documentation ASAP.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 29. Jan 2018, at 19:15, Wayne Stambaugh 
 >> wrote:
 
 Bernhard,
 
 Am I safe deleting the macos patches from the source repo or do I need
 to hold off until the dust has settle on the new wx repo?
 
 Thanks,
 
 Wayne
 
 On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
> The full original soname patch seems to fix the issue in my builds (I
> did apply only half of it to our fork because of the comments in
> wxWidgets trac).
> I pushed it to the fork.
> The next build should pick it up automatically and be good again… sorry
> for not having checked this before.
> 
> I also did set the bug to “Fix Committed”.
> 
> 
> BTW @Adam:
> There are still 2 wxPython macOS patches:
> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> stuff for wxWidgets.
> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
> far as I can see and it seems to be fine without?
>   => Still needed?
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
>>  
>> >
>> >> wrote:
>> 
>> Just a short status…
>> I just tried the compile_wx.sh script and it generally seems to be fine.
>> 
>> But, I can see that obviously the wxPython installer duplicates libs
>> instead of symlinking them.
>> Maybe the original soname patch we had is needed for that one to work
>> correctly.
>> I’ll check…
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>>> On 29. Jan 2018, at 00:32, Adam Wolf >> 
>>> >> >
>>> >> >> wrote:
>>> 
>>> I think I see it now.  I can probably fix this tonight.  Thanks!
>>> 
>>> Adam
>>> 
>>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>>> 
>>> > 
>>> >>
>>> wrote:
>>> 
>>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>>The build in question includes some 3.0.0 wxWidgets libraries
>>>which I guess come from wxPython download.
>>>The fork should create 3.0.4 libraries...
>>> 
On 29. Jan 2018, at 00:05, Bernhard Stegmaier

 > 
 >>
 wrote:
 
I just had a quick look and it looks fine.
 
Also my first guess is that maybe something got messed up in the
folder hierarchy when copying wxPython/wxWidgets together, so
that e.g. here
  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
some wrong wxWidgets (not the one of the fork) gets pulled in.
 
Too late here already to check just by review, will try
 tomorrow… :)
 
>On 29. Jan 2018, at 00:00, Adam Wolf
> 
> 

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Wayne,

I don’t think so.

I use a stock MacPorts boost since long before you removed boost from KiCad 
build.
This might not be representative, but I didn’t see any problems.

I had a quick look into Adams build scripts and I didn’t see that he is 
building his own boost (with the patches) somewhere.


Regards,
Bernhard

> On 30. Jan 2018, at 21:58, Wayne Stambaugh  wrote:
> 
> Bernhard,
> 
> What about the macos boost and context patches?  Do we still need to
> keep them?
> 
> Thanks,
> 
> Wayne
> 
> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>> Wayne,
>> 
>> yes, from my side you can delete them.
>> Even if deleted they are in git anyway, so we can restore them if really
>> needed.
>> I’ll try to change documentation ASAP.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 29. Jan 2018, at 19:15, Wayne Stambaugh >> 
>>> >> wrote:
>>> 
>>> Bernhard,
>>> 
>>> Am I safe deleting the macos patches from the source repo or do I need
>>> to hold off until the dust has settle on the new wx repo?
>>> 
>>> Thanks,
>>> 
>>> Wayne
>>> 
>>> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
 The full original soname patch seems to fix the issue in my builds (I
 did apply only half of it to our fork because of the comments in
 wxWidgets trac).
 I pushed it to the fork.
 The next build should pick it up automatically and be good again… sorry
 for not having checked this before.
 
 I also did set the bug to “Fix Committed”.
 
 
 BTW @Adam:
 There are still 2 wxPython macOS patches:
 (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
 stuff for wxWidgets.
 (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
 far as I can see and it seems to be fine without?
   => Still needed?
 
 
 Regards,
 Bernhard
 
 
> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
>  
> >
> >> wrote:
> 
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
> 
> But, I can see that obviously the wxPython installer duplicates libs
> instead of symlinking them.
> Maybe the original soname patch we had is needed for that one to work
> correctly.
> I’ll check…
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 00:32, Adam Wolf > 
>> > >
>> > >> wrote:
>> 
>> I think I see it now.  I can probably fix this tonight.  Thanks!
>> 
>> Adam
>> 
>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>> 
>> > 
>> >>
>> wrote:
>> 
>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>The build in question includes some 3.0.0 wxWidgets libraries
>>which I guess come from wxPython download.
>>The fork should create 3.0.4 libraries...
>> 
>>>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
>>>
>>> > 
>>> >>
>>> wrote:
>>> 
>>>I just had a quick look and it looks fine.
>>> 
>>>Also my first guess is that maybe something got messed up in the
>>>folder hierarchy when copying wxPython/wxWidgets together, so
>>>that e.g. here
>>>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>>>some wrong wxWidgets (not the one of the fork) gets pulled in.
>>> 
>>>Too late here already to check just by review, will try
>>> tomorrow… :)
>>> 
On 29. Jan 2018, at 00:00, Adam Wolf

 >
>> wrote:
 
Yeah.  The previous build script downloaded a wxpython tarball,
which included wxwidgets.
 
All my update did was move the wxpython subdirectory into a git
checkout of 

Re: [Kicad-developers] wxwidgets fork progress

[Adam Wolf]

That patch may be needed to build on older macOS versions and older
targets.  I am not worried about removing it--it hasn't been in builds for
a long time.

Good work Bernhard.

Adam

On Jan 29, 2018 12:11 PM, "Bernhard Stegmaier" 
wrote:

> The full original soname patch seems to fix the issue in my builds (I did
> apply only half of it to our fork because of the comments in wxWidgets
> trac).
> I pushed it to the fork.
> The next build should pick it up automatically and be good again… sorry
> for not having checked this before.
>
> I also did set the bug to “Fix Committed”.
>
>
> BTW @Adam:
> There are still 2 wxPython macOS patches:
> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> stuff for wxWidgets.
> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as far
> as I can see and it seems to be fine without?
>   => Still needed?
>
>
> Regards,
> Bernhard
>
>
> On 29. Jan 2018, at 13:47, Bernhard Stegmaier 
> wrote:
>
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
>
> But, I can see that obviously the wxPython installer duplicates libs
> instead of symlinking them.
> Maybe the original soname patch we had is needed for that one to work
> correctly.
> I’ll check…
>
>
> Regards,
> Bernhard
>
>
> On 29. Jan 2018, at 00:32, Adam Wolf 
> wrote:
>
> I think I see it now.  I can probably fix this tonight.  Thanks!
>
> Adam
>
> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier" 
> wrote:
>
>> Quick look into the build… seems to pull in wrong wxWidgets libs.
>> The build in question includes some 3.0.0 wxWidgets libraries which I
>> guess come from wxPython download.
>> The fork should create 3.0.4 libraries...
>>
>> On 29. Jan 2018, at 00:05, Bernhard Stegmaier 
>> wrote:
>>
>> I just had a quick look and it looks fine.
>>
>> Also my first guess is that maybe something got messed up in the folder
>> hierarchy when copying wxPython/wxWidgets together, so that e.g. here
>>   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>> some wrong wxWidgets (not the one of the fork) gets pulled in.
>>
>> Too late here already to check just by review, will try tomorrow… :)
>>
>> On 29. Jan 2018, at 00:00, Adam Wolf 
>> wrote:
>>
>> Yeah.  The previous build script downloaded a wxpython tarball, which
>> included wxwidgets.
>>
>> All my update did was move the wxpython subdirectory into a git checkout
>> of the wxwidgets tree, and build that way.
>>
>> One quick thing would be to just do a diff between the wxwidgets included
>> with wxpython 3.0.2.0, and the tree.  At this point, nothing would surprise
>> me :)
>>
>> Adam
>>
>>
>>
>> On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" 
>> wrote:
>>
>>> Sure.
>>> I’ll have a look tomorrow and try to build wxWidgets/wxPython the same
>>> way the script does.
>>>
>>> On 28. Jan 2018, at 23:44, Nick Østergaard  wrote:
>>>
>>> You don't need to revert it. I can just choose the latest workin hash in
>>> the jenkins job. I would rather we fix it somehow. :)
>>>
>>> @Bernhard, the build scripts in question are
>>> https://github.com/wayneandlayne/KiCadMacOSPackaging
>>>
>>> Maybe you can have a got at it?
>>>
>>> 2018-01-28 23:41 GMT+01:00 Nick Østergaard :
>>>
 I assume this is the bug you are talking about:
 https://bugs.launchpad.net/kicad/+bug/1745868

 2018-01-28 23:14 GMT+01:00 Adam Wolf :

> I was able to get the wxwidgets stuff switched over but there's a bug
> in the big tracker saying it didn't work.  I will continue to look into it
> as I can.  I should be over this illness by the end of this week, it looks
> like.
>
> I can revert the packaging change so the next builds will work again.
>
> Sorry folks, I have lost weeks and weeks of productivity and am trying
> to do my best.
>
> Adam
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>

>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
> 

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Wayne,

yes, from my side you can delete them.
Even if deleted they are in git anyway, so we can restore them if really needed.
I’ll try to change documentation ASAP.


Regards,
Bernhard

> On 29. Jan 2018, at 19:15, Wayne Stambaugh  wrote:
> 
> Bernhard,
> 
> Am I safe deleting the macos patches from the source repo or do I need
> to hold off until the dust has settle on the new wx repo?
> 
> Thanks,
> 
> Wayne
> 
> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
>> The full original soname patch seems to fix the issue in my builds (I
>> did apply only half of it to our fork because of the comments in
>> wxWidgets trac).
>> I pushed it to the fork.
>> The next build should pick it up automatically and be good again… sorry
>> for not having checked this before.
>> 
>> I also did set the bug to “Fix Committed”.
>> 
>> 
>> BTW @Adam:
>> There are still 2 wxPython macOS patches:
>> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
>> stuff for wxWidgets.
>> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
>> far as I can see and it seems to be fine without?
>>   => Still needed?
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier >> >> wrote:
>>> 
>>> Just a short status…
>>> I just tried the compile_wx.sh script and it generally seems to be fine.
>>> 
>>> But, I can see that obviously the wxPython installer duplicates libs
>>> instead of symlinking them.
>>> Maybe the original soname patch we had is needed for that one to work
>>> correctly.
>>> I’ll check…
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
>>> 
 On 29. Jan 2018, at 00:32, Adam Wolf 
 >> wrote:
 
 I think I see it now.  I can probably fix this tonight.  Thanks!
 
 Adam
 
 On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
  
 >> wrote:
 
Quick look into the build… seems to pull in wrong wxWidgets libs.
The build in question includes some 3.0.0 wxWidgets libraries
which I guess come from wxPython download.
The fork should create 3.0.4 libraries...
 
>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
> 
> >> wrote:
> 
>I just had a quick look and it looks fine.
> 
>Also my first guess is that maybe something got messed up in the
>folder hierarchy when copying wxPython/wxWidgets together, so
>that e.g. here
>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>some wrong wxWidgets (not the one of the fork) gets pulled in.
> 
>Too late here already to check just by review, will try tomorrow… :)
> 
>>On 29. Jan 2018, at 00:00, Adam Wolf
>>
>>> >> wrote:
>> 
>>Yeah.  The previous build script downloaded a wxpython tarball,
>>which included wxwidgets.
>> 
>>All my update did was move the wxpython subdirectory into a git
>>checkout of the wxwidgets tree, and build that way.
>> 
>>One quick thing would be to just do a diff between the
>>wxwidgets included with wxpython 3.0.2.0, and the tree.  At
>>this point, nothing would surprise me :)
>> 
>>Adam
>> 
>> 
>> 
>>On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier"
>> 
>> >> wrote:
>> 
>>Sure.
>>I’ll have a look tomorrow and try to build
>>wxWidgets/wxPython the same way the script does.
>> 
>>>On 28. Jan 2018, at 23:44, Nick Østergaard
>>> 
>>> >> wrote:
>>> 
>>>You don't need to revert it. I can just choose the latest
>>>workin hash in the jenkins job. I would rather we fix it
>>>somehow. :)
>>> 
>>>@Bernhard, the build scripts in question are
>>>https://github.com/wayneandlayne/KiCadMacOSPackaging 
>>> 
>>>>> >
>>> 
>>>Maybe you 

Re: [Kicad-developers] wxwidgets fork progress

[Wayne Stambaugh]

Bernhard,

Am I safe deleting the macos patches from the source repo or do I need
to hold off until the dust has settle on the new wx repo?

Thanks,

Wayne

On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
> The full original soname patch seems to fix the issue in my builds (I
> did apply only half of it to our fork because of the comments in
> wxWidgets trac).
> I pushed it to the fork.
> The next build should pick it up automatically and be good again… sorry
> for not having checked this before.
> 
> I also did set the bug to “Fix Committed”.
> 
> 
> BTW @Adam:
> There are still 2 wxPython macOS patches:
> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> stuff for wxWidgets.
> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
> far as I can see and it seems to be fine without?
>   => Still needed?
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier > > wrote:
>>
>> Just a short status…
>> I just tried the compile_wx.sh script and it generally seems to be fine.
>>
>> But, I can see that obviously the wxPython installer duplicates libs
>> instead of symlinking them.
>> Maybe the original soname patch we had is needed for that one to work
>> correctly.
>> I’ll check…
>>
>>
>> Regards,
>> Bernhard
>>
>>
>>> On 29. Jan 2018, at 00:32, Adam Wolf >> > wrote:
>>>
>>> I think I see it now.  I can probably fix this tonight.  Thanks!
>>>
>>> Adam
>>>
>>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>>> > wrote:
>>>
>>> Quick look into the build… seems to pull in wrong wxWidgets libs.
>>> The build in question includes some 3.0.0 wxWidgets libraries
>>> which I guess come from wxPython download.
>>> The fork should create 3.0.4 libraries...
>>>
 On 29. Jan 2018, at 00:05, Bernhard Stegmaier
 > wrote:

 I just had a quick look and it looks fine.

 Also my first guess is that maybe something got messed up in the
 folder hierarchy when copying wxPython/wxWidgets together, so
 that e.g. here
   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
 some wrong wxWidgets (not the one of the fork) gets pulled in.

 Too late here already to check just by review, will try tomorrow… :)

> On 29. Jan 2018, at 00:00, Adam Wolf
>  > wrote:
>
> Yeah.  The previous build script downloaded a wxpython tarball,
> which included wxwidgets.
>
> All my update did was move the wxpython subdirectory into a git
> checkout of the wxwidgets tree, and build that way.
>
> One quick thing would be to just do a diff between the
> wxwidgets included with wxpython 3.0.2.0, and the tree.  At
> this point, nothing would surprise me :)
>
> Adam
>
>
>
> On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier"
> > wrote:
>
> Sure.
> I’ll have a look tomorrow and try to build
> wxWidgets/wxPython the same way the script does.
>
>> On 28. Jan 2018, at 23:44, Nick Østergaard
>> > wrote:
>>
>> You don't need to revert it. I can just choose the latest
>> workin hash in the jenkins job. I would rather we fix it
>> somehow. :)
>>
>> @Bernhard, the build scripts in question are
>> https://github.com/wayneandlayne/KiCadMacOSPackaging
>> 
>>
>> Maybe you can have a got at it?
>>
>> 2018-01-28 23:41 GMT+01:00 Nick Østergaard
>> >:
>>
>> I assume this is the bug you are talking about:
>> https://bugs.launchpad.net/kicad/+bug/1745868
>> 
>>
>> 2018-01-28 23:14 GMT+01:00 Adam Wolf
>> > >:
>>
>> I was able to get the wxwidgets stuff switched
>> over but there's a bug in the big tracker saying
>> it didn't work.  I will continue to look into it
>> as I can.  I should be over this illness by the
>> end of this week, it looks like.
>>
>> I can revert the packaging change so the next
>> builds will work 

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

The full original soname patch seems to fix the issue in my builds (I did apply 
only half of it to our fork because of the comments in wxWidgets trac).
I pushed it to the fork.
The next build should pick it up automatically and be good again… sorry for not 
having checked this before.

I also did set the bug to “Fix Committed”.


BTW @Adam:
There are still 2 wxPython macOS patches:
(1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay stuff 
for wxWidgets.
(2) I don’t know about the “…_multiarch.patch”. You don’t apply it as far as I 
can see and it seems to be fine without?
  => Still needed?


Regards,
Bernhard


> On 29. Jan 2018, at 13:47, Bernhard Stegmaier  wrote:
> 
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
> 
> But, I can see that obviously the wxPython installer duplicates libs instead 
> of symlinking them.
> Maybe the original soname patch we had is needed for that one to work 
> correctly.
> I’ll check…
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 00:32, Adam Wolf > > wrote:
>> 
>> I think I see it now.  I can probably fix this tonight.  Thanks!
>> 
>> Adam
>> 
>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier" > > wrote:
>> Quick look into the build… seems to pull in wrong wxWidgets libs.
>> The build in question includes some 3.0.0 wxWidgets libraries which I guess 
>> come from wxPython download.
>> The fork should create 3.0.4 libraries...
>> 
>>> On 29. Jan 2018, at 00:05, Bernhard Stegmaier >> > wrote:
>>> 
>>> I just had a quick look and it looks fine.
>>> 
>>> Also my first guess is that maybe something got messed up in the folder 
>>> hierarchy when copying wxPython/wxWidgets together, so that e.g. here
>>>   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>>> some wrong wxWidgets (not the one of the fork) gets pulled in.
>>> 
>>> Too late here already to check just by review, will try tomorrow… :)
>>> 
 On 29. Jan 2018, at 00:00, Adam Wolf > wrote:
 
 Yeah.  The previous build script downloaded a wxpython tarball, which 
 included wxwidgets.
 
 All my update did was move the wxpython subdirectory into a git checkout 
 of the wxwidgets tree, and build that way.
 
 One quick thing would be to just do a diff between the wxwidgets included 
 with wxpython 3.0.2.0, and the tree.  At this point, nothing would 
 surprise me :)
 
 Adam
 
 
 
 On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" > wrote:
 Sure.
 I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way 
 the script does.
 
> On 28. Jan 2018, at 23:44, Nick Østergaard  > wrote:
> 
> You don't need to revert it. I can just choose the latest workin hash in 
> the jenkins job. I would rather we fix it somehow. :)
> 
> @Bernhard, the build scripts in question are 
> https://github.com/wayneandlayne/KiCadMacOSPackaging 
> 
> 
> Maybe you can have a got at it?
> 
> 2018-01-28 23:41 GMT+01:00 Nick Østergaard  >:
> I assume this is the bug you are talking about:
> https://bugs.launchpad.net/kicad/+bug/1745868 
> 
> 
> 2018-01-28 23:14 GMT+01:00 Adam Wolf  >:
> I was able to get the wxwidgets stuff switched over but there's a bug in 
> the big tracker saying it didn't work.  I will continue to look into it 
> as I can.  I should be over this illness by the end of this week, it 
> looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to 
> do my best.
> 
> Adam
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Just a short status…
I just tried the compile_wx.sh script and it generally seems to be fine.

But, I can see that obviously the wxPython installer duplicates libs instead of 
symlinking them.
Maybe the original soname patch we had is needed for that one to work correctly.
I’ll check…


Regards,
Bernhard


> On 29. Jan 2018, at 00:32, Adam Wolf  wrote:
> 
> I think I see it now.  I can probably fix this tonight.  Thanks!
> 
> Adam
> 
> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"  > wrote:
> Quick look into the build… seems to pull in wrong wxWidgets libs.
> The build in question includes some 3.0.0 wxWidgets libraries which I guess 
> come from wxPython download.
> The fork should create 3.0.4 libraries...
> 
>> On 29. Jan 2018, at 00:05, Bernhard Stegmaier > > wrote:
>> 
>> I just had a quick look and it looks fine.
>> 
>> Also my first guess is that maybe something got messed up in the folder 
>> hierarchy when copying wxPython/wxWidgets together, so that e.g. here
>>   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>> some wrong wxWidgets (not the one of the fork) gets pulled in.
>> 
>> Too late here already to check just by review, will try tomorrow… :)
>> 
>>> On 29. Jan 2018, at 00:00, Adam Wolf >> > wrote:
>>> 
>>> Yeah.  The previous build script downloaded a wxpython tarball, which 
>>> included wxwidgets.
>>> 
>>> All my update did was move the wxpython subdirectory into a git checkout of 
>>> the wxwidgets tree, and build that way.
>>> 
>>> One quick thing would be to just do a diff between the wxwidgets included 
>>> with wxpython 3.0.2.0, and the tree.  At this point, nothing would surprise 
>>> me :)
>>> 
>>> Adam
>>> 
>>> 
>>> 
>>> On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" >> > wrote:
>>> Sure.
>>> I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way 
>>> the script does.
>>> 
 On 28. Jan 2018, at 23:44, Nick Østergaard > wrote:
 
 You don't need to revert it. I can just choose the latest workin hash in 
 the jenkins job. I would rather we fix it somehow. :)
 
 @Bernhard, the build scripts in question are 
 https://github.com/wayneandlayne/KiCadMacOSPackaging 
 
 
 Maybe you can have a got at it?
 
 2018-01-28 23:41 GMT+01:00 Nick Østergaard >:
 I assume this is the bug you are talking about:
 https://bugs.launchpad.net/kicad/+bug/1745868 
 
 
 2018-01-28 23:14 GMT+01:00 Adam Wolf >:
 I was able to get the wxwidgets stuff switched over but there's a bug in 
 the big tracker saying it didn't work.  I will continue to look into it as 
 I can.  I should be over this illness by the end of this week, it looks 
 like.
 
 I can revert the packaging change so the next builds will work again.
 
 Sorry folks, I have lost weeks and weeks of productivity and am trying to 
 do my best.
 
 Adam
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
 Unsubscribe : https://launchpad.net/~kicad-developers 
 
 More help   : https://help.launchpad.net/ListHelp 
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
 Unsubscribe : https://launchpad.net/~kicad-developers 
 
 More help   : https://help.launchpad.net/ListHelp 
 
>>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 

___
Mailing list: 

Re: [Kicad-developers] wxwidgets fork progress

[Adam Wolf]

I think I see it now.  I can probably fix this tonight.  Thanks!

Adam

On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier" 
wrote:

> Quick look into the build… seems to pull in wrong wxWidgets libs.
> The build in question includes some 3.0.0 wxWidgets libraries which I
> guess come from wxPython download.
> The fork should create 3.0.4 libraries...
>
> On 29. Jan 2018, at 00:05, Bernhard Stegmaier 
> wrote:
>
> I just had a quick look and it looks fine.
>
> Also my first guess is that maybe something got messed up in the folder
> hierarchy when copying wxPython/wxWidgets together, so that e.g. here
>   WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
> some wrong wxWidgets (not the one of the fork) gets pulled in.
>
> Too late here already to check just by review, will try tomorrow… :)
>
> On 29. Jan 2018, at 00:00, Adam Wolf 
> wrote:
>
> Yeah.  The previous build script downloaded a wxpython tarball, which
> included wxwidgets.
>
> All my update did was move the wxpython subdirectory into a git checkout
> of the wxwidgets tree, and build that way.
>
> One quick thing would be to just do a diff between the wxwidgets included
> with wxpython 3.0.2.0, and the tree.  At this point, nothing would surprise
> me :)
>
> Adam
>
>
>
> On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" 
> wrote:
>
>> Sure.
>> I’ll have a look tomorrow and try to build wxWidgets/wxPython the same
>> way the script does.
>>
>> On 28. Jan 2018, at 23:44, Nick Østergaard  wrote:
>>
>> You don't need to revert it. I can just choose the latest workin hash in
>> the jenkins job. I would rather we fix it somehow. :)
>>
>> @Bernhard, the build scripts in question are
>> https://github.com/wayneandlayne/KiCadMacOSPackaging
>>
>> Maybe you can have a got at it?
>>
>> 2018-01-28 23:41 GMT+01:00 Nick Østergaard :
>>
>>> I assume this is the bug you are talking about:
>>> https://bugs.launchpad.net/kicad/+bug/1745868
>>>
>>> 2018-01-28 23:14 GMT+01:00 Adam Wolf :
>>>
 I was able to get the wxwidgets stuff switched over but there's a bug
 in the big tracker saying it didn't work.  I will continue to look into it
 as I can.  I should be over this illness by the end of this week, it looks
 like.

 I can revert the packaging change so the next builds will work again.

 Sorry folks, I have lost weeks and weeks of productivity and am trying
 to do my best.

 Adam

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxwidgets fork progress

[Adam Wolf]

Yeah.  The previous build script downloaded a wxpython tarball, which
included wxwidgets.

All my update did was move the wxpython subdirectory into a git checkout of
the wxwidgets tree, and build that way.

One quick thing would be to just do a diff between the wxwidgets included
with wxpython 3.0.2.0, and the tree.  At this point, nothing would surprise
me :)

Adam



On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier" 
wrote:

> Sure.
> I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way
> the script does.
>
> On 28. Jan 2018, at 23:44, Nick Østergaard  wrote:
>
> You don't need to revert it. I can just choose the latest workin hash in
> the jenkins job. I would rather we fix it somehow. :)
>
> @Bernhard, the build scripts in question are https://github.com/
> wayneandlayne/KiCadMacOSPackaging
>
> Maybe you can have a got at it?
>
> 2018-01-28 23:41 GMT+01:00 Nick Østergaard :
>
>> I assume this is the bug you are talking about:
>> https://bugs.launchpad.net/kicad/+bug/1745868
>>
>> 2018-01-28 23:14 GMT+01:00 Adam Wolf :
>>
>>> I was able to get the wxwidgets stuff switched over but there's a bug in
>>> the big tracker saying it didn't work.  I will continue to look into it as
>>> I can.  I should be over this illness by the end of this week, it looks
>>> like.
>>>
>>> I can revert the packaging change so the next builds will work again.
>>>
>>> Sorry folks, I have lost weeks and weeks of productivity and am trying
>>> to do my best.
>>>
>>> Adam
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Sure.
I’ll have a look tomorrow and try to build wxWidgets/wxPython the same way the 
script does.

> On 28. Jan 2018, at 23:44, Nick Østergaard  wrote:
> 
> You don't need to revert it. I can just choose the latest workin hash in the 
> jenkins job. I would rather we fix it somehow. :)
> 
> @Bernhard, the build scripts in question are 
> https://github.com/wayneandlayne/KiCadMacOSPackaging 
> 
> 
> Maybe you can have a got at it?
> 
> 2018-01-28 23:41 GMT+01:00 Nick Østergaard  >:
> I assume this is the bug you are talking about:
> https://bugs.launchpad.net/kicad/+bug/1745868 
> 
> 
> 2018-01-28 23:14 GMT+01:00 Adam Wolf  >:
> I was able to get the wxwidgets stuff switched over but there's a bug in the 
> big tracker saying it didn't work.  I will continue to look into it as I can. 
>  I should be over this illness by the end of this week, it looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to do 
> my best.
> 
> Adam
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

That seems to be the same error as when the former so-name patch was not 
applied and original wxWidgets build stuff rewrites library names.
The bundle is corrupt then, because the bundling code fails to create symlinks 
and copies libs instead multiple times.

If you can send me where to find the current state, I can have look into it 
tomorrow.
I could imagine that it has to do with how wxPython is built… I have seen 
similar library rewrite stuff in some python build scripts (which the patch 
doesn’t fix).

However, shouldn’t make any difference, the fork contains all the stuff we had 
in the patches before.


Regards,
Bernhard

> On 28. Jan 2018, at 23:41, Nick Østergaard  wrote:
> 
> I assume this is the bug you are talking about:
> https://bugs.launchpad.net/kicad/+bug/1745868 
> 
> 
> 2018-01-28 23:14 GMT+01:00 Adam Wolf  >:
> I was able to get the wxwidgets stuff switched over but there's a bug in the 
> big tracker saying it didn't work.  I will continue to look into it as I can. 
>  I should be over this illness by the end of this week, it looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to do 
> my best.
> 
> Adam
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxwidgets fork progress

[Nick Østergaard]

You don't need to revert it. I can just choose the latest workin hash in
the jenkins job. I would rather we fix it somehow. :)

@Bernhard, the build scripts in question are
https://github.com/wayneandlayne/KiCadMacOSPackaging

Maybe you can have a got at it?

2018-01-28 23:41 GMT+01:00 Nick Østergaard :

> I assume this is the bug you are talking about:
> https://bugs.launchpad.net/kicad/+bug/1745868
>
> 2018-01-28 23:14 GMT+01:00 Adam Wolf :
>
>> I was able to get the wxwidgets stuff switched over but there's a bug in
>> the big tracker saying it didn't work.  I will continue to look into it as
>> I can.  I should be over this illness by the end of this week, it looks
>> like.
>>
>> I can revert the packaging change so the next builds will work again.
>>
>> Sorry folks, I have lost weeks and weeks of productivity and am trying to
>> do my best.
>>
>> Adam
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Which bug?


Bernhard

> On 28. Jan 2018, at 23:14, Adam Wolf  wrote:
> 
> I was able to get the wxwidgets stuff switched over but there's a bug in the 
> big tracker saying it didn't work.  I will continue to look into it as I can. 
>  I should be over this illness by the end of this week, it looks like.
> 
> I can revert the packaging change so the next builds will work again.
> 
> Sorry folks, I have lost weeks and weeks of productivity and am trying to do 
> my best.
> 
> Adam
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxwidgets fork progress

[Nick Østergaard]

I assume this is the bug you are talking about:
https://bugs.launchpad.net/kicad/+bug/1745868

2018-01-28 23:14 GMT+01:00 Adam Wolf :

> I was able to get the wxwidgets stuff switched over but there's a bug in
> the big tracker saying it didn't work.  I will continue to look into it as
> I can.  I should be over this illness by the end of this week, it looks
> like.
>
> I can revert the packaging change so the next builds will work again.
>
> Sorry folks, I have lost weeks and weeks of productivity and am trying to
> do my best.
>
> Adam
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] wxwidgets fork progress

[Adam Wolf]

I was able to get the wxwidgets stuff switched over but there's a bug in
the big tracker saying it didn't work.  I will continue to look into it as
I can.  I should be over this illness by the end of this week, it looks
like.

I can revert the packaging change so the next builds will work again.

Sorry folks, I have lost weeks and weeks of productivity and am trying to
do my best.

Adam
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp