[waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

[Jose Fonseca]

Sorry for the late reply.  I missed you first email somehow.

----- Original Message -----
> Hi all,
> 
> Another round of interesting bits and bulbs.
> 
> The email came out a bit longer than expected, although it provides a decent
> list of possible solutions. Let me know which one you'll go with.
> 
> Four topics sorted by priority - high to low (based on my humble opinion)
> 
> * ChoosePixelFormat - close yet quite different across platforms.
> 
>   - glXChoosePixelFormat    - depends on display (matches waffle's model).
>   - CGLChoosePixelFormat    - no dependencies.
>   - {wgl,}ChoosePixelFormat - depends on a device_context/existing window.
> 
>   Options:
>     - Create a window, choose format, destroy window.
>           No guarantee that the function will behave the same for another
>           window/device_context.
> 
>     - or, create window, choose format, reuse window on
>     waffle_window_create()
>           Sanest solution. If windows is not created just make one (i.e.
>           waffle_config_choose is not executed before waffle_window_create).
> 
>     - or, store the attributes, and invoke ChoosePixelFormat as
>       waffle_window_create is executed.
>           What if code-flow depends on waffle_config_choose's return value ?
> 
>     - or rework waffle API ... (no, please no)
> 
>   Suggestion:
>     "Cache" the window, and reuse it on waffle_window_create.
> 
> 
> * CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
> 
> 
> * Thread-safe and Co.
> AFAICS it's used to provide thread independent waffle error info. Have I
> missed something ?
> 
>    - strerror_r is depreciated in favour of strerror_s. MS claims that the
>      former is not TS, while *nix man page disagrees.
> 
>    - Current mingw-w64 build does not work on Win XP - missing strerror_s.
>      Fix landed in mingw-w64 trunk ~a few weeks ago.
> 
>        - Back-port commit and build things with custom mingw_w64
>        - or, port the commit over to waffle ?
> 
>   Suggestion:
>     Port over to waffle.
> 
> 
> * Library dependencies, etc. (low priority)
> libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency,
> ship them in the zip or leave it to the user/dev ?
> 
>   Library:
>     libgcc_s
>       __emutls_get_address
>       __udivdi3
>       __umoddi3

I personally use --static-libgcc and -static-libstdc++ to avoid DLL dependencies on MINGW. But for example the MinGW binaries for Qt depend on them.  It's probably not a big issue either way.  We could put an CMAKE option to control this.


>   Options:
>     - Static link libgcc_s, generally not bad idea
>     - or, rework waffle ?
>           Split merged_version or move to (major << 8 | minor) for the
>           wcore_config_attrs_version_* helpers - will nuke the last two.
>           No idea how to nuke __emutls_get_address.
> 
>   Suggestion:
>     Split to separate major/minor.
> 
> 
>   Library:
>      libwinpthread-1
>        pthread_key_create
>        pthread_mutex_lock
>        pthread_mutex_unlock
>        pthread_once
>        pthread_setspecific
> 
>   Options:
>      - Static link
>      - or, rebuild mingw-w64-gcc with --enable-threads=win32
>      - or, rework current code (open to suggestions)?

I'm pretty disapointed MinGW introduced this dependency.  I actually reverted my MinGW compilers to gcc-4.6 to avoid getting caught by this.

Either way, I wouldn't worry too much about this.  Sooner or later somebody will manage to get MSVC builds.

At very least we must provide MSVC import libaries, as MSVC linker can't link to DLL directly.

>   Suggestion:
>     The above list states my order of preference.
> 
> 
> Any feedback would be great. Meanwhile I will send out a few misc/cleanup
> patches :)
> 
> Cheers,
> Emil
> 

Jose