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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
