kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

> 
> We best include the patch in our source tree. To be fair, it won't be
> hard to maintain that patch as it's unlikely they'll change that
> assembler code, and swapping from one assembler flavour to another isn't
> exactly difficult, it's just a syntax change.

Maybe CERN would have enough leverage to push this patch through.  It
might be worth a try rather than trying to maintain a ever expanding
patch set for Boost which becomes a maintenance issue.

> 
> Alternatively, we could investigate setjmp/longjmp pairing to do the
> context switching and patch that onto Boost.

This is my preference if it's doable.  Putting assembly code in a C++
library or program leaves a lot to be desired not the least of which is
portability.

Wayne

> 
> Best Regards,
> 
> Brian.