kicad-developers team mailing list archive

[Andrew Lutsenko <anlutsenko@xxxxxxxxx>]

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 <anlutsenko@xxxxxxxxx>
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 <stambaughw@xxxxxxxxx>
> 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 <stambaughw@xxxxxxxxx
>> > <mailto:stambaughw@xxxxxxxxx>> 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
>> >     <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> >     > <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>> wrote:
>> >     >
>> >     >     On 7/31/2018 1:13 PM, Seth Hillbrand wrote:
>> >     >     >
>> >     >     >
>> >     >     > Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh
>> >     >     > <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> >     <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> >     >     <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> >     <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>:
>> >     >     >
>> >     >     >     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@xxxxxxxxxxxxxxxxxxx
>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> >     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>> >     >     Unsubscribe : https://launchpad.net/~kicad-developers
>> >     <https://launchpad.net/%7Ekicad-developers>
>> >     >     <https://launchpad.net/%7Ekicad-developers>
>> >     >     More help   : https://help.launchpad.net/ListHelp
>> >     >
>> >
>>
>