kicad-developers team mailing list archive

["Torsten Hüter" <torstenhtr@xxxxxx>]

Hi Wayne,

for a short term solution also an older Boost version can be used for Windows - or Tom's patch - it's at least not a blocker. 
I'm guessing Tom could do more productive stuff :)

For the long term solution it's of course possible to drop the coroutines completely and use the well known event-driven finite-state machines (https://en.wikipedia.org/wiki/Event-driven_finite-state_machine) - I think that's what you're meaning with the second suggestion. 

I can do this job, because I've implemented a lot of them in various languages - but this needs more time and I'd have to touch more files. The tool framework uses already an event system and most tools with coroutines look to me simplistic (they have an init part, an event loop and some finishing instructions).
Makes of course only sense, if we have an agreement, would an example be helpful?

Thanks,
Torsten 

>> 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.