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 _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
