This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New catgets/gencat package


Igor Pechtchanski wrote:

I would call this package "libcatgets".  Were you inclined to do it
"right", you'd probably want to 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.  However, the
package is probably so small as to not justify such a split.

"smallness" is not the reason for splitting DLLs out of the main package. Coexistence of multiple versions of the same DLL is.


If you don't expect the DLL interface to change in backwards-incompatible ways (e.g. you don't expect to bump the "DLL number") then don't bother to split the package. This goes if the package is "large" or "small".

Conversely, if you DO think future interface changes are likely, then you might as well set things up now so that you're prepared for the numbered-dll-packages that will become necessary at that later time. And again, that goes regardless of package "size".

OTOH, since Linux has it as part of the standard C library, why not simply
submit a patch to newlib that implements those functions?  Use the newlib
list for this: <newlib at sources dot redhat dot com>.

Geez.


Sometimes I wonder what the purpose of newlib is. If it is to become a full glibc replacement, the why not just use glibc? Is it a licensing thing?

I always *thought* newlib was supposed to be a lean-n-mean, highly portable, suitable-for-embedded/limited systems runtime library...but maybe I was wrong.

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]