Using public headers to write ABI vscripts

[Andrew Bartlett]

On Fri, 2012-08-31 at 09:38 +0300, Alexander Bokovoy wrote:
> On Fri, Aug 31, 2012 at 9:06 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Fri, 2012-08-31 at 08:31 +0300, Alexander Bokovoy wrote:
> >> Hi Andrew,
> >>
> >> On Wed, Aug 29, 2012 at 7:54 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> > I've been working on a patch to use the mksyms.awk approach to get a
> >> > list of public headers and symbols from our public headers files, and
> >> > use that instead of just the regular-expression abi_match.
> >> >
> >> > https://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/abi-public-headers
> >> >
> >> > It would be great to get this in to 4.0, but I'm having some waf
> >> > challenges I'll need to get past.  The challenge relates to the grouping
> >> > from the build ordering, because we need a vscript for libreplace (very
> >> > early) but vscripts can depend on pild-generated headers.  We may need
> >> > to rely on pure dependencies rather than also the groups.
> >> >
> >> > This came up because I had to bump the ldb ABI (it needed a bump for the
> >> > behaviour change, but it spiked my interest) when adding a private,
> >> > internal symbol.
> >> I'm also working in this area though my needs are bit different at the moment.
> >>
> >> https://git.samba.org/?p=ab/samba.git/.git;a=shortlog;h=refs/heads/stableabi
> >> has number of patches that attempt to introduce API namespaces.
> >>
> >> I need stable mapping between API namespace and version node name
> >> associated with it that spans across multiple releases (instead of
> >> SAMBA_<VERSION> default symbol changing every release without actual
> >> semantical and ABI change) for certain important private libraries.
> >
> > I'm a bit confused.  In what sense is a library that is being linked
> > from outside our build process still private?
> libpdb is required to link against if you are passdb module. FreeIPA
> provides its ipasam module and it needs to link against libpdb to be
> useful in smbd.It is consumed purely by smbd and thus still considered
> private but the source code lives outside samba source tree and thus
> public.

I really don't like this half-public-half-private thing.  Either this is
a public library, or a private library, it shouldn't be both.  We
certainly shouldn't be installing public headers for a private library
like we currently do.

Certainly an external package should *never* be linking directly into
our private library folder. 

We have other libraries that we do not make strong promises regarding
ABIs for, but which we must provide external access (samba-util comes to
mind).  These we still declare as public. 

> > I don't like the idea of public users of our private libraries.  If we
> > wish to declare a library open for public use, shouldn't it just be
> > given a version number and be declared as public?
> libpdb includes all sorts of things, not only API that is used by the
> modules. For example, all statically compiled pdb modules are compiled
> into libpdb.

Then we need to rework things so that we provide a public library that
is externally useful and acceptable, containing only the bare minimum
that writing an external passdb module would need.  That may mean having
a different private library that handles the registration (and therefore
potentially static linking) of the passdb modules. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org