← Back to team overview

kicad-developers team mailing list archive

Re: MASM Boost dependency on Windows

 

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.

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








Follow ups

References