Doug Turner wrote:
>> Once we freeze XPCOM, can we start versioning the shared library as well?
>
> I hope so. I have a xpcom libray install in /usr/lib. I have clue what
> version it is. I have seen makefile hacks to determine what version it
> might be. Unacceptable. Maybe you can weigh in here. How hard would
> it be to add versioning in an xp way?
I think the only truly XP way to do it would be to follow NSPR's example
and rename the library with each major revision. I'd prefer to use
unix's soname feature which will allow us to distinguish between minor
releases of the same major release branch of a library but I don't know
if that feature exists for win32 or classic mac.
>> Are there any plans for creating a separate lib for the "non-core"
>> parts of XPCOM? I vaguely recall another thread on this long ago but
>> I can't seem to find it.
>
> Yes, there is plenty of talk about moving many of the helper functions
> like, nsCOMPtr, get_Service, and the string class into a static libary
> that both xpcom and third partys can link to. This would all the third
> party to no have to link to xpcom and therefore be independant. What do
> you think?
I guess my questioning was more along the lines of Smirl's in the sense
of wanting to remove the external dependencies from the core xpcom
library. Btw, is there an official definition for the "core" xpcom
library? I always saw the core as just what's needed to handle
components: xpidl, xpcom/base, xpcom/components and xpcom/proxy . io &
ds are important to have XP but I'm just not sure they belong in the
core xpcom library.
- cls
