On 7/18/11 1:53 AM, Eli Zaretskii wrote:
>> S_ISCTG and such aren't being defined under Cygwin, causing compilation
>> errors.  There's probably a better way to deal with the underlying problem.
> 
> Yes, the files in lib/sys_stat.in.h is supposed to do that already.
> I'm curious why it didn't work for you.

I didn't look into why it didn't work.  I can do some investigation, but
I'm not very familiar with how gnulib stuff actually works.

> I'd prefer a separate file common to w2 and Cygwin-on-w32, if that's
> needed.  w32fns.c tries to be as similar to xfns.c as possible, so
> putting there stuff that's not relevant would be a disadvantage.

Fair enough.  I'll move some code around; would you object to having
w32.c, cygw32.c, and ntw32.c and corresponding headers?

>>>> +#define t(...)                                          \
>>>> +    ({                                                  \
>>>> +      fprintf (stderr, "T:%s:%u: ",                     \
>>>> +               __FUNCTION__, __LINE__);                 \
>>>> +      fprintf (stderr, __VA_ARGS__);                    \
>>>> +      fputc ('\n', stderr);                             \
>>>> +    })
>>>> +
>>>
>>> What is this stuff about?
>>
>> Debug scaffolding --- in this case, generally useful, I think, at least
>> as a replacement for the numerous bespoke tracing macros scattered
>> everywhere in the code.
> 
> Fine, but (a) please see if there's no macro already available that
> can be used instead; 

I didn't see anything suitable.

and (b) let's have this a separate changeset.

Fair enough, though I'll keep it in the patch for now just to make
debugging easier.  (gdb under Cygwin is problematic at best, IME.)

>>> This is based on reviewing only a part of the patch, I will have more
>>> later.  The patch is very large and complicated, and the lack of a
>>> ChangeLog that describes the changes, particularly those which move
>>> code between different files, does not help...
>>
>> Of course. It's a work in progress --- a first stab, really.  Once I
>> clean up the code a bit, I'll put it into a form that's easier to consume.
> 
> My point was that there are several issues here that need to be
> discussed before you invest too much energy into them.  So please
> consider starting these discussion sooner rather than later, and the
> additional information I didn't find in the ChangeLog would be
> instrumental at that time.

Sure, but there's also something to be said for building a prototype as
well.