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

[Conrad T. Pino]

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,

Ditto,

> Derek

Conrad