Re: WIP citrus patch
Matthew Dillon wrote:
> :> Hi all,
> :> for those of you wondering about the recently added files,
> :> I'm working on integrating the Citrus framework from NetBSD.
> :> The patch at http://leaf.dragonflybsd.org/~joerg/citrus4.diff
> :> is the current stage, but it is *not* final. This needs an
> :> libc major bump, which will be used to clean certain other
> :> parts of libc up too. Consider this mail as FYI if you don't
> :> completely know what you are doing :)
> :>
> :> After applying the patch, if you want to test it, remove the
> :> empty files from src/include, otherwise Bad Things Happen(tm).
> :>
> :> Joerg
> :
> :Noted, massive job, and and *Very welcome* work for the
> :'internationalists' among us. Thank you!
> :
> :Homepage is here for anyone not familiar:
> :
> :http://citrus.bsdclub.org/index.html
> :
> :Bill
>
> Nice URL reference. It looks like exactly what we want.
Joerg Sonnenberger's initiative - I was just the 'historian' ;-)
>
> A couple of us have been talking about how to do a major libc bump
> gracefully. At the moment I think that since we will be doing major
> work on several areas of libc that will require the version bump,
> we should probably rename the current libc source hierarchy libc4 and
> dup the CVS tree to create a libc5, and then be able to select one or
> the other for the buildworld (with it defaulting to libc4). Not both,
> just one or the other :-) (because the /usr/include files need major
> work too). This way a subset of developers who want to track the
> new work and who know how to deal with libc blowing up the whole
> system can, and everyone else can stick with libc4.
>
> Joerg is investigating the Makefile framework required to make this
> happen.
>
> -Matt
Sounds practical.....
An International Telecoms career, content-hopping life-style,
multi-lingual wife, and the observation that no ethnic group has
(yet) been granted a patent on brains or coding skills, make i18n very
dear to my heart.
So far, 'userland' tools in, for example, Zope/Plone (see our precisa.ch)
have sufficed. But the F/OSS community of coders need something closer
to the bone if we are to effectively share work on 'system' infrastructure.
- Especially to ease building those userland apps more efficiently in
future.
At the same time, I note that 'citrus' is itself an under-resourced project,
(as are most such) so keeping the i18n-relevant toolset 'modular'
seems very wise.
- As with 'X' - It may someday have to be swapped for a different one
or made optional. 'libi18n' breakout from libc{x} even...
I don't code C, but docs and research I *can* do .. just ID the need.
Bill
討論串 (同標題文章)
完整討論串 (本文為第 4 之 7 篇)：