[Top][All Lists]

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

RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & l

From: Conrad T. Pino
Subject: RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Date: Wed, 25 May 2005 11:05:57 -0700

Hi Derek,

> From: Derek Price
> Actually, because of errors similar to the ones you've been seeing on
> Solaris, it sounds like GNULIB will be defining similar gl_stat and
> gl_lstat macros.  I will either make the canonicalize module use those
> and depend on the stat module or we can define both stat and gl_stat for
> the windows port.

The hard part is the "stat" token which is both a function name and a
structure name which the macro processor can't distinguish and both are
substituted which is the root of the problem we saw on Solaris.  It makes
the Windows function "wnt_stat" arguments look odd on casual inspection.
The preprocessor is a blunt instrument in a language supporting multiple
name speaces.

Using "typedef struct stat struct_stat;" before the "#define stat ..."
helps a lot with this issue.  I prefer this since functions and typedefs
occupy the same name space.

> >Does GNULIB include the Windows platform in it's charter?
> Sometimes.  How are your arm wrestling skills?  :)

I was afraid of that "sometimes" part.  I've watched you get into the ring
and it's a pretty site only if you're into blood sports. :)

> >If yes, what's your take on the resistance to Windows native API calls?
> Windows native API call resistance was pretty strong last time I came up
> against it, but GNULIB team members were willing to suggest compromises
> that at least compiled on Windows.

Sounds like pushing sand up a hill or herding cats.  I'll pass for now.

> >Since our Windows support is "client" mode only do loops matter?
> Yes, to the extent that the Windows client will support a local
> repository.  It may be true that the loops are impossible on Windows
> since links are not processed in the same way.

We address this topic later in this message thread.

> Regards,


> Derek


reply via email to

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