discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSCharacterSet bloat?


From: Derek Zhou
Subject: Re: NSCharacterSet bloat?
Date: 24 Jan 2006 10:53:10 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Richard Frith-Macdonald <richard@brainstorm.co.uk> writes:

> On 23 Jan 2006, at 22:40, Derek Zhou wrote:
> 
> > If that is not too big, can we merge them into base or make?
> 
> Of course we could ... but I can see no reason to do so, any more
> than we should merge gcc into the base or make package.(less in  fact
> ... gcc is generally useful).
gcc (or any lib that gnustep depends on) is public known free
software, while the utility to produce the characterset is not even
mentioned on gnustep.org
  
> Perhaps you want to do something worthwhile here though ... I can see
> some value if you want to produce a new utility to reliably download
> charset data from the unicode website, convert it to the format in
> which it is used in the base library, compare it with the built-in
> data, and produce a warning if the base library is no longer up to
> date.  That would save us the effort of doing it manually once every
> few years.

I haven't take a look at the current utility to compile the
characterset, but assuming that works, modify it to automate the
download from unicode.org, compare with current installed characterset
and update if necessary shoudn't be too hard. However, to be able to
update a live GNUstep system, I have to seperate the characterset from
the binary, so it goes back to my original argument, that is seperation
between code and data is a good thing. A good example is linux use to
have some firmware embedded in the code, now linux load firmware at
run time. Also, there maybe legal concern here: By linking in
unicode.org's data into the binary, gnustep may become a derivative
work of unicode.org. Using them as separate data files should be much
safer. Just my 2 cents.  

Derek




reply via email to

[Prev in Thread] Current Thread [Next in Thread]