kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

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