"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Oh no, I didn't mean a getopt-specific library. I was just under the > impression that you didn't want the tools (such as wrc) be linked > with libwine, since I've noticed that port.h disables the usage > of certain functions for which we already have alternative implementations > in libwine (like strcasecmp). But that was just a cursory look, > maybe I misread that.
No, it's the general idea, but the fact is that at this point most tools link with libwine anyway. That's one of the things I'm planning to change with a separate portability library. > But also, IIRC, I've submitted something > adding a getopt_long to libwine, but you opted for the current scheme: > > http://www.winehq.com/hypermail/wine-patches/2002/12/0063.html > > Sure, it was just the shell :), but would building on that work for you? Yes, that's the way to do it, except it has to be implemented, not stubbed out. The idea is that port.[ch] provides an emulation of the missing functions so that people writing the code don't need to worry about whether they exist or not. But if the replacement is broken then we very much want the caller to be aware of that; which is why I put the #ifdefs in wrc so that it's explicit that long options don't work if configure didn't find getopt_long(). -- Alexandre Julliard [EMAIL PROTECTED]
