[waffle] [PATCH 16/33] third_party/threads: import c11 threads emulation wrappers

[Jose Fonseca]

On 21/07/14 17:45, Emil Velikov wrote:
> On 17/07/14 05:40, Chad Versace wrote:
>> Emil,
>>
>> I'm finished reviewing for today, and am stopping here at patch 16. I'll
>> resume reviewing tomorrow.
>>
>> I see that you're collecting reviewed-by tags and cleanups on versioned
>> brancehs (for-upstream-3.*). I will defer cherry-picking patches off the
>> mailing list onto master; and instead will wait for you to send merge
>> requests, because I assume that was your intended workflow. If you want
>> to do things differently, let me know.
>>
> Hi Chad,
>
> I do not mind either way (cherry-picking or sending pull requests), I mostly
> work this way to have a form of an incremental build-up based on the feedback
> received.
>
> Changes in for-upstream-3.2:
>   - addressed your initial comments
>   - dropped patch 10 (add -fPIC for the whole of waffle)
>   - updated patch 17 (introduce third_party/threads) to build with PIC
>   - squashed two warnings in the threads library (separate commits so that I
> can get them back in mesa)
>   - cleaned/simplified up the cmocka build to make it possible to make it
> buildable in cross-builds and/or windows
>
> A bit more work on separate branches
>   - cleaned up a few cmocka warnings, sent the fixes upstream - not merged yet
>   - de-duplicated the platform specific tests in gl_basic_test, having fun with
> porting run_testsuite() - fork(), waitpid()... to win32
>   - moved libEGL from link dependency to dlopen() at runtime - got bored of
> reading MS documents
>   - added basic wgl support for piglit - might not be as straight forward as I
> expected, see below for more
>
> Brian, Jose,
>
> Short summary at my next obstacle and my current ideas/possible solutions
>
> piglit, glut and waffle:
>   1) waffle abstracts windows and gl management and is capable of returning the
> native objects (window, ctx...)
>   2) but does not do any input -> piglit + waffle uses linux (posix/unix?)
> specific input code.
>
>
>   1) My present WGL code does not have the *.get_native() hooks. Currently
> beating them into shape.
>
>   2) AFAICS there are ways to address the input issue
>   a) rip out the glut completely and write Windows specific code for the input
> handling. I have close to zero experience in this area, any suggestions ? What
> would happen with other platforms using glut like MacOS ? Is it even possible
> to do that today ?
>   b) rip out the glut GL parts but keep the input code in. Seems slightly messy
> and I'm not sure it will even work.
>
> Any ideas/suggestions on point 2 above ?

I think that mixing GLUT with other stuff is a bad idea.

Otherwise -- whether to add some input support to waffle or not -- is a 
design choice that Chad needs to make.

On one hand most similar frameworks (GLUT, GLFW) tend to have input too. 
One the other hand.  For GL testing (piglit/apitrace) probably it 
doesn't make much difference either way.

At least for piglit/apitrace input is not really a must: in the "-auto" 
input is ignored, and in the non "-auto" mode we could simply put a 
Sleep() function instead of a wait-for-key, which would probably be good 
enough for most cases. (We could also read input from stdin, which can 
be done with portable C)


> Last but not least - which approach would be the best for getting the WGL code
> integrated upstream ?
>   1) one big code blob
>   2) commit one - empty skeleton, two - widows_create, three - window_show...
>   3) keep the series as is - small and gradual changes
>   4) other ?
>
> I'm leaning towards the third option, yet we're talking about ~25 commits.
> Perhaps the second would be a reasonable compromise ?

Small and gradual changes are indeed nice to review. To commit them as 
is or squash is up to Chad -- I'm fine either way.

Jose