[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & l
Conrad T. Pino
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Wed, 25 May 2005 11:05:57 -0700
> 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
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.