Hi Andrew- No bother at all. Sorry for the slow responses. Feel free to keep asking if you don't get an answer.
The recent change was a regression in v5 vs v4. The difference is in where we draw the feature vs. bug fix line. Can you give a bit more information about why 5.0.1 is important vs. 5.1? Unless Wayne wants to jump in give the green light, this feels like a feature that could wait. -Seth Am Mi., 8. Aug. 2018 um 16:16 Uhr schrieb Andrew Lutsenko < anlutse...@gmail.com>: > Hi Seth, > > Sorry to be repeating myself but since I didn't get any response I assumed > this just slipped through everyone's attention. > > I noticed that a fix of very similar scope to mine was pushed to both dev > and 5.0 branches (Re-add missing SWIG zone filler). > Can my patch be pushed to 5.0 too, please? > > Regards, > Andrew > > On Fri, Aug 3, 2018 at 11:03 AM Andrew Lutsenko <anlutse...@gmail.com> > wrote: > >> Awesome, thanks! >> Qa machine seems happy too. >> >> So is there any chance of this getting into 5.0 branch? >> >> I published my plugin earlier here >> https://github.com/openscopeproject/InteractiveHtmlBom >> >> And it generated a fair amount of interest on kicad.info >> https://forum.kicad.info/t/interactive-html-bom-plugin-for-kicad-5-0/11713 >> >> Plugin doesn't require this patch but without it it can't render custom >> shape pads and any graphics on copper/silkscreen. >> Would be great to see this in 5.0.1 but I understand if you only want to >> put critical fixes in that release. >> >> Regards, >> Andrew >> >> On Fri, Aug 3, 2018 at 5:35 AM Wayne Stambaugh <stambau...@gmail.com> >> wrote: >> >>> Andrew, >>> >>> I merged your patch into the development branch of KiCad. Thank you for >>> your contribution to KiCad. >>> >>> Cheers, >>> >>> Wayne >>> >>> On 7/31/2018 5:34 PM, Andrew Lutsenko wrote: >>> > Removing or renaming operator<< does not work because it is used by >>> > boost test suite in qa/geometry/test_fillet.cpp >>> > >>> > But I found an easier solution. There is no need to have friend >>> > declaration in VECTOR2 class at all because it's fields are public >>> anyway. >>> > I removed that declaration but kept operator<< implementation and that >>> > compiles just fine. Tested on debian8 and msys2. >>> > >>> > If this solution is acceptable to you, see my amended patch attached. >>> > >>> > Andrew >>> > >>> > >>> > On Tue, Jul 31, 2018 at 1:01 PM Wayne Stambaugh <stambau...@gmail.com >>> > <mailto:stambau...@gmail.com>> wrote: >>> > >>> > If option 2 is the only option that works, please make sure to set >>> the >>> > minimum swig version in the cmake file that finds swig. I would >>> rather >>> > the config fail then the build fail because an unusable version of >>> swig >>> > is found. >>> > >>> > On 7/31/2018 2:57 PM, Andrew Lutsenko wrote: >>> > > I will test later today both options >>> > > 1. Removing VECTOR2::operator<< or renaming it to str() if it's >>> used. >>> > > 2. Upgrading to swig 3.0.10 from backports. >>> > > >>> > > Hopefully first is doable and would be transparent for users. >>> > > Second one should definitely solve the issue and I feel like >>> > compared to >>> > > other hoops a user has to jump through to make KiCad compile on >>> > debian8 >>> > > this would not be the worst. >>> > > >>> > > Regards, >>> > > Andrew >>> > > >>> > > On Tue, Jul 31, 2018 at 11:32 AM Wayne Stambaugh >>> > <stambau...@gmail.com <mailto:stambau...@gmail.com> >>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> >>> wrote: >>> > > >>> > > On 7/31/2018 1:13 PM, Seth Hillbrand wrote: >>> > > > >>> > > > >>> > > > Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh >>> > > > <stambau...@gmail.com <mailto:stambau...@gmail.com> >>> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>> >>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com> >>> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>>: >>> > > > >>> > > > On 7/31/2018 8:33 AM, Carsten Schoenert wrote: >>> > > > > Am 31.07.18 um 17:50 schrieb Andrew Lutsenko: >>> > > > > ... >>> > > > >> Can swig on the qa machine be updated? Or better yet >>> > can you >>> > > > upgrade to >>> > > > >> debian 9? Debian 9 has swig 3.0.10 and compiles this >>> > just fine. >>> > > > >> Aside from this debian 8 is very old and should be >>> done >>> > > away with >>> > > > anyway >>> > > > >> because of security, old compilers, etc. >>> > > > > >>> > > > > Argumentation by missing security isn't a valid >>> > choice, even >>> > > now the >>> > > > > ELTS team is taking care of security updates, old >>> versions >>> > > can be >>> > > > solved >>> > > > > by using backports, even swig has 3.0.10 in >>> > > jessie-backports. I agree >>> > > > > that GCC wont become any version updates for Jessie. >>> > > > > >>> > > > > But there are still users out there which use Jessie >>> based >>> > > desktops. >>> > > > > >>> > > > >>> > > > I'm siding with Carsten on this. There are people who >>> > prefer >>> > > stable >>> > > > computing platforms and I want to avoid making kicad >>> only >>> > > build on the >>> > > > latest distros. I prefer that we keep as large of a >>> target >>> > > audience as >>> > > > possible. How difficult would it be to change the >>> > > SHAPE_LINE_CHAIN >>> > > > object (actually its the VECTOR2 object that causes >>> the swig >>> > > issue) so >>> > > > that older versions of swig don't choke on it? I >>> would be >>> > > open to that >>> > > > solution. >>> > > > >>> > > > Cheers, >>> > > > >>> > > > Wayne >>> > > > >>> > > > >>> > > > I'm not sure I follow the discussion. I thought Carsten >>> > was saying >>> > > > that jessie-backports does have SWIG 3.0.10 and so we can >>> > upgrade swig >>> > > > on the kicad-qa without changing to a newer debian. >>> > > >>> > > I was operating under the assumption that not every user will >>> > track or >>> > > want to track Debian backports so in this case the user would >>> > still only >>> > > have the older version of swig. The line of code that is >>> > causing swig >>> > > to choke is the VECTOR2 << operator which I'm almost sure is >>> > being used >>> > > for debugging output and therefore could easily be removed >>> without >>> > > issue. I'm not sure that there are not other swig related >>> > issues in the >>> > > SHAPE_LINE_CHAIN implementation this change may not be >>> > enough. If we >>> > > are going to use a version of swig that works with the >>> current >>> > code, we >>> > > should set the cmake find package minimum version of swig to >>> > the correct >>> > > version. I'm fine either way. Others may not be fine with >>> this. >>> > > >>> > > > >>> > > > @Andrew - can you compile your changes on debian 8 using >>> the >>> > swig from >>> > > > backports as Carsten described? If not, then this is moot >>> and >>> > > we'd need >>> > > > to look at a SWIG-specific VECTOR2, an outcome that might >>> be >>> > long-term >>> > > > problematic. >>> > > > >>> > > > -S >>> > > >>> > > _______________________________________________ >>> > > Mailing list: https://launchpad.net/~kicad-developers >>> > <https://launchpad.net/%7Ekicad-developers> >>> > > <https://launchpad.net/%7Ekicad-developers> >>> > > Post to : kicad-developers@lists.launchpad.net >>> > <mailto:kicad-developers@lists.launchpad.net> >>> > > <mailto:kicad-developers@lists.launchpad.net >>> > <mailto:kicad-developers@lists.launchpad.net>> >>> > > Unsubscribe : https://launchpad.net/~kicad-developers >>> > <https://launchpad.net/%7Ekicad-developers> >>> > > <https://launchpad.net/%7Ekicad-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