[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Yaakov Selkowitz]

On 2016-03-18 18:05, Yaakov Selkowitz wrote:
> On 2016-03-18 17:25, Ken Brown wrote:
>> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>>> On Mar 18 16:58, Ken Brown wrote:
>>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>>
>>>>> If things are not going very wrong, this is basically what you'll
>>>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>>>
>>>> Does this release include Yaakov's overhaul of the feature test macros?
>>>
>>> Sorry, I completely forgot to metion this in my release mail, which
>>> is especially weird because I created this test release to allow testing
>>> the new feature test macros in the first place.  Sorry!
>>
>> The problem I reported in
>> https://www.cygwin.com/ml/cygwin/2015-12/msg00183.html has reappeared.
>> It looks like your fix
>> (https://www.cygwin.com/ml/cygwin/2015-12/msg00199.html) got reverted.
>
> The commit message for removing the include did not indicate what
> prompted it.  However, the include is necessary for BSD compatibility,
> and other software fails to build without it.
>
> I would look into emacs and see what feature test macro(s) they enable
> on *Linux*, and use the same for Cygwin.

Might this be it?

http://git.savannah.gnu.org/cgit/emacs.git/tree/lib/sys_select.in.h

There's some seriously hackish things going on in that file, some of 
them Cygwin specific.  As far as this is concerned, our headers should 
be no different than glibc.

BTW, folks, I'm here to help deal with any fallout from these changes, 
but this is going to be the first answer to such issues: others need to 
stop making hackish, wrong, or outdated assumptions about Cygwin.  Yes, 
that means pushing some patches to undo this mistreatment, but nothing 
new there.  As of today's 2.5.0-0.8, it should only considered a bug in 
our headers when something does not compile if and only if Cygwin is 
treated identically to glibc.

-- 
Yaakov