kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/15/2013 2:03 PM, Dick Hollenbeck wrote:
> On 10/15/2013 12:13 PM, Wayne Stambaugh wrote:
>> On 10/15/2013 11:51 AM, Brian Sidebotham wrote:
>>> On 15 October 2013 16:07, Maciej Sumiński <maciej.suminski@xxxxxxx
>>> <mailto:maciej.suminski@xxxxxxx>> wrote:
>>>
>>>     On 10/15/2013 03:33 PM, Lorenzo Marcantonio wrote:
>>>
>>>         On Tue, Oct 15, 2013 at 02:18:19PM +0100, Brian Sidebotham wrote:
>>>
>>>             As Dick says, this completely breaks cross-compilation of Boost.
>>>
>>>
>>>         Well, can't say it is a good thing... as a workaround maybe
>>>         supplying
>>>         precompiled (preassembled!) object for that couple of file could be
>>>         useful, too.
>>>
>>>
>>>     I am just wondering - don't those files included in the CERN branch
>>>     (http://bazaar.launchpad.net/~__cern-kicad/kicad/testing/__files/head:/common/system/
>>>     <http://bazaar.launchpad.net/~cern-kicad/kicad/testing/files/head:/common/system/>)
>>>     solve the problem? If no - what is wrong with them, maybe we can
>>>     introduce some modifications?
>>>     I was able to build the KiCad using these files on every supported
>>>     platform (actually the tool framework and the push and shove router
>>>     depends on them).
>>>
>>>     Regards,
>>>     Orson
>>>
>>>
>>> Hi Orson,
>>>
>>> Those files are basically the patch provided on the Boost bug tracker I
>>> originally linked to as far as I can tell.
>>>
>>> Having read all of that conversation now I think in order to support
>>> boost::context in KiCad that patch is the only way we're going to get it
>>> to build under MinGW. Olli from the Boost project looks to have
>>> misunderstood the original bug report which is "Boost::Context doesn't
>>> build with MinGW!" - instead he's contorted it in an attempt to blame a
>>> problem in the MinGW linker. Binutils (and thus GNU AS) is part of
>>> MinGW, it's a part of the toolchain so requiring MASM is just a fallacy.
>>
>> I read the bug report as well and it makes me wonder if using Boost is
>> really a good idea.  This kind of behavior is one of sadder comments on
>> open source software development.  Someone offers up a solution to a
>> problem and person with the commit access can't deal with it for what
>> ever reason.  Does Boost have a lead developer or development team that
>> can help resolve issues like this or is it every developer has their own
>> little fiefdom?  They still haven't fixed the polygon issues JP raised
>> over 8 months ago and I looked at the change log for the upcoming 1.55
>> release and it still is not addressed.
> 
> 
> 
> It is one thing not to fix a bug.  It is a whole larger problem when a bug fix comes in as
> a patch and it is rejected.

Maybe there's some bad blood between the developers that we are unaware
of or something silly like that.  As an outside observer looking at the
patch and the bug report, it would seem like a no brainer to commit it.
 All rejecting this patch does is decrease Boost's user base.  Not a
good thing when you are an open source project.

> 
> The first one is understandable, the second one is simply strange, since you have binutils
> in the build environment anyways.
> 

That's why I asked about the pecking order at Boost.  Maybe there is
someone a higher level such as a project leader we could raise this
issue to get a resolution.  If someone was doing this in KiCad, I would
want to know about it.