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

[Emil Velikov]

On 04/06/14 21:18, Jose Fonseca wrote:
> 
> 
> ----- Original Message -----
>> On Sun, May 25, 2014 at 08:00:49PM -0700, Jordan Justen wrote:
>>> On Sun, May 25, 2014 at 2:43 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>> wrote:
>>>> On 25/05/14 21:35, Jordan Justen wrote:
>>>>> On Sat, May 24, 2014 at 12:28 PM, Emil Velikov
>>>>> <emil.l.velikov at gmail.com> wrote:
>>>>>> * 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
>>>>>>
>>>>>>   Options:
>>>>>>     - Static link libgcc_s, generally not bad idea
>>>> sigh, a bit of a typo here - the above should read:
>>>>
>>>> - Static link libgcc_s - generally _a bad_ idea
>>>
>>> Doesn't gcc/binutils automatically do this when you compile/link?
>>>
>>>>> What are the licensing implications?
>>>>>
>>>> That's possibly the main reason why I'm inclined to go with rework. I've
>>>> never
>>>> been good at the legal/licensing terms.
>>>>
>>>>> I think libgcc would be covered by this exception, right?
>>>>> https://urldefense.proofpoint.com/v1/url?u=https://www.gnu.org/licenses/gcc-exception-3.1-faq.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=0dWLL1eK7zXGaHLwGR8JQNvgR0iR%2BeSjmnMVBlMUMwU%3D%0A&s=f5e6e804df74284b34407c9df79fcd092ac004d7341177df10dd1859df58f389
>>>>>
>>>>> If so, it seems like static linking might not be a problem.
>>>>>
>>>> IIUC you are correct. waffle is gpl-compatible (2-clause BSD), and no
>>>> gpl-incompatible software is used during the "Compilation Process", thus
>>>> we
>>>> are "Eligible".
>>>
>>> It sounds they only mean to prevent non-GPL compatible code from
>>> getting into the internals of the GCC complication process. So, in
>>> other words, you can't have a proprietary GCC plugin, and also use the
>>> exception to link to libgcc, etc.
>>>
>>> But, it seems like even proprietary code could use the exception to
>>> link to libgcc as long as it was just being compiled by GCC.
>>>
>>>>>>     - 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
>>>>>
>>>>> What are the licensing implications?
>>>>>
>>>>> It doesn't look as good as the libgcc case.
>>>>>
>>>> The library is a combination of X/MIT and 3-clause BSD. Which afaics is
>>>> rather
>>>> vague on the topic of static linking the library and distribution of the
>>>> final
>>>> binary(ies). My guess is that we ought to be safe but IANAL.
>>>
>>> This wasn't my concern. I was concerned the library might have been
>>> GPL licensed, and thus the waffle DLL wouldn't be usable with a
>>> proprietary application.
>>>
>>> Chad, would you be okay with releasing the windows waffle DLL and
>>> noting that it is partially covered by X/MIT, 3-clause BSD and
>>> 2-clause BSD?
>>
>>
>> If Waffle needs a stacked license to support Win32, that's ok with me.
>> Liberal licenses in the BSD, MIT, and Apache family are all acceptable.
>>
>> I am not a lawyer either, so I do not know if statically linking the
>> parts you speak of are safe to do so. I think you should make your
>> initial decision based on its technical merits. Then, after the
>> technical, decision is made but before you've invested too much time in
>> it, all of us (you, Jordan, me, Jose) should analyze any license issues.
>>
>> FWIW, I prefer to avoid runtime dependency hell by statically linking
>> small, problematic components. But my opinion is of limited value here,
>> because I'm unfamiliar with the problem domain of mingw and MSVC.
> 
> FWIW, my opinion is that we shouldn't get too distracted by licensing and what release binaries should look like.  It is not something that needs to be decided now, or ever: ultimately, that decision can be pushed to the final user.  They might prefer mingw, they might prefer msvc for easy of debugging, or because they want to statically link, etc.
> 
> IMHO the most important is getting waffle to build and run on Windows on some form.
> 
Fair enough. Curious why did this get so much attention, perhaps the option
"leave it to the user/dev" was not clear enough in my original email.

-Emil

> Jose
>