kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I've been following this thread for a few days and honestly I'm not
excited about anything proposed thus far.  Tom's latest patch solves the
immediate problem of the MinGW64 build issues but creates build on other
platforms that Boost supports (although I don't know how well they are
supported).  We would also be responsible for maintaining the library
forever which goes against the whole point of using a library like
boost.  It will also completely kill MSVC support for those devs who are
doing their own thing.  Not that that is an issue but we would be
throwing them completely under a bus because we don't allow msvc
specific code in kicad.

I know a lot of effort has been put forth and that is not lost on me but
I'm not sure anything presented thus far is a viable long term solution
for the project.  I'm not rejecting it completely it's just not as
elegant of a solution as I was hoping for.  It seems like a lot of work
to fix the one platform where boost context doesn't work.  What I would
like to see happen is one of two things.

1) Fix the boost context library 64 bit windows gnu assembly files so
that it works and create a patch which can be sent upstream to boost and
the msys2 project.  The 32 bit windows gas file version works fine as do
the linux and osx versions.  I'm assuming the other supported boost
platforms work as well (arm, mips?, etc.).  Since version 1.60 boost is
supply gas files for windows builds so it appears they have changed
their mind about this.  I'm guessing they would be more receptive to
patches now that they are providing the gas files for windows builds.  I
know the msys2 devs are more than happy to apply patches that fix known
bugs so that would solve our short term problem.

or

2) Dump the context switching design and fall back to a message based
approach which is more in line with how most event base GUI libraries
are designed.

Cheers,

Wayne

On 1/22/2016 6:03 AM, "Torsten Hüter" wrote:
> Hi,
>  
> Chris:
>>> I really think that if we're going to have to support this, it should be
>>> something conceptually simpler, like an emulation of coroutines using a
>>> set of threads and locks.
> 
> I've tried that, but there are side effects with 3rd party libraries (wxWidgets, OpenGL),
> so that is not a solution in my opinion. I found with my research, that no convincing 
> C/C++ context switching library is existing, when it should work on all major platforms and with
> the constraint that the tool code shouldn't be modified.
> 
> So I also think using assembler in one header is not the ideal but a very good solution,
> it addresses the two most important goals (a) Bugfix for Windows/Msys2 and (b) removes the
> dependency on boost::context. 
> 
> Tom:
> Thank you very much for this patch.
> 
> I've tried it shortly with my test, it runs so far well (up to 500 coroutines on my system). There are some
> minor things (compiler warnings, missing doxygen comments, open fixme comments) - I can work on that if you like.
> 
> Thanks,
> Torsten
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>