[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] system-type cygwin with window-system w32

From: Daniel Colascione
Subject: Re: [PATCH] system-type cygwin with window-system w32
Date: Mon, 18 Jul 2011 03:10:11 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]