[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: back-config, ucdata
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> At 07:07 PM 4/26/2004, Howard Chu wrote:
> >Another obstacle I've tripped over - we need the ucdata
> loaded before we can
> >start processing any LDIFs. It seems to me that we should
> just hardcode the
> >ucdata tables into liblunicode. Maybe ucgendat should spit
> out the data in C
> >source format, so that the arrays can be compiled in. Comments?
>
> That would resolve a number of issues with ucdata files
> (such as possible inability for files to be read when
> created on the same system).
>
> Also, using compiled tables would allow them to be integrated
> directly into -lldap, and facilitate -lldap implementation of
> LDAPprep and SASLprep.
Since we have libldap and libldap_r, it might be better (avoiding unnecessary
duplication) to put it into liblber, or turn it into a shared library.
> I'd be open to distributing the derived C file (in addition to
> tools which create it) so that it wouldn't have to be re-generated
> everywhere (which is generally a hassle).
I've changed the liblunicode Make rules to accomodate this. I haven't moved
ucgendat into build though, it's still in liblunicode.
> That is, maybe we should have build/ucdata tool which generated
> libraries/libldap/ucdata.c. However, CVS (and releases) would
> include libraries/libldap/ucdata.c so that build/ucdata would not
> need to be built/ran by user.
ucdata.c now #include's uctable.h to get the relevant data.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support