kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 30/04/2015 19:43, Wayne Stambaugh a écrit :
> On 4/30/2015 1:38 PM, jp charras wrote:
>> Le 30/04/2015 18:53, Wayne Stambaugh a écrit :
>>>
>>>
>>> On 4/30/2015 7:28 AM, jp charras wrote:
>>>> Le 29/04/2015 15:11, Wayne Stambaugh a écrit :
>>>>> Blair,
>>>>>
>>>>> Thanks for testing this.  I am curious if the boost::geometry issue has
>>>>> been fixed.  I looked at the change log and there were a bunch of bug
>>>>> fixes in the geometry library.  Although the bug report JP filed was not
>>>>> among them.  Hopefully they solved this problem.  If someone could
>>>>> verify that, I would appreciate it.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Wayne
>>>>>
>>>>
>>>> The crash happens in 1.58, with my test program (the one I sent to the
>>>> boost::polygon maintainer).
>>>>
>>>>
>>> Sigh!!!  I guess it was wishful thinking.  It's been over two years
>>> since this bug was filed and all we have is an acknowledgement that it
>>> is indeed a problem.  After the stable release, maybe we need to look at
>>> alternate polygon libraries.
>>
>> There are not a lot of these libs (at least for FOSS).
>> The last, not yet used or tested, (with an acceptable license) I know is
>> CGAL.
> 
> Is there some test condition for the polygon that causes the crash that
> we can use to at least prevent the crash?  I know it's less than ideal
> but at least we can warn the user to change their clearances slightly
> and refill the zone rather than allow Pcbnew to crash and potentially
> cause data loss.

I don't know.
The only one thing I noticed is the fact the risk is lowered when
circles are approximated by 15, 17 or 18 segments instead of 16.

But it is not null.

> 
>>
>> I am using Clipper for some operations not handled by Boost, but when
>> combining polygons, the result is strange.
>>
>> This bug is really annoying, but to tell the True, the issue with
>> boost::context (on Windows, not supporting gcc) is for me a lot more
>> annoying.
>>
> 
> For all the hype about Boost, they are not very cooperative when it
> comes to fixing things.  I'm starting to regret that made kicad so
> dependent on Boost.  Removing it now would probably be more work than
> providing our own Boost patches.
> 

As long we are using only headers, Boost is acceptable and we can patch it.

This is the fact we have to build some libraries, and mainly a library
written in assembler which creates 90% of issues, because the building
process is not compatible with gcc (for asm files) and is not compatible
with mingw/msys2 for building tools, which is very dangerous for the
near future.
Therefore, this is mainly these libraries which have to be removed, not
the full .hpp headers.

But I agree, the less Boost is used, the better.


-- 
Jean-Pierre CHARRAS