>> sdesc: "catgets message catalog API; gencat" > >Is the package name also "catgets"? Though in this particular case, >"catgets: catgets message catalog API; gencat" doesn't look too weird.
It is. The repetiveness sounds a little awkward, but is entirely logical, because the second "catgets" is from another namespace. It's like a movie database saying, "name: Nixon; description: Biography of Nixon" >split this into "libcatgets" that contains >just the runtime DLL, and "libcatgets-devel" that contains the necessary >headers, the static libs (if any), and the gencat utility. Except that there's no DLL; it's all a development package. libcatgets.a is so small and infrequently used that the added complexity of a DLL just isn't worth it. >why not simply submit a patch to newlib that implements those >functions? I'm pretty sure that would be a waste of time; that if Newlib people didn't object to this on philosophical grounds (that newlib should remain a lean core and people who need the frills should add them on), they would object on style grounds. The glibc catgets function drags with it a dozen other glibc facilities that aren't in newlib. For example, the obstack memory allocator, the argp command line option processor, the getopt_long_r recursion-safe version of getopt_long. I'm not willing to spend another 6 hours reworking all that so it fits nicely into newlib (OTOH, I might be willing to contribute 6 hours toward porting glibc to Cygwin!). -- Bryan Henderson Phone 408-621-2000 San Jose, California