[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