"Dimitrie O. Paun" dimi@intelliware.ca 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().