Using public headers to write ABI vscripts

[Alexander Bokovoy]

On Fri, Aug 31, 2012 at 9:46 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> 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'm fine if we would declare libpdb and libsmbldap as 'public'.
Cleaning them up and splitting truly internal code is something I can
do.

>> > 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.
I did try that in first revision of the patchset. I quickly got into
circular dependencies hell, unfortunately, as all of pdb modules,
including the statically linked ones, require the same base set of
registration functions that embed statically linked modules (in
lazy_initialize_passdb()).

-- 
/ Alexander Bokovoy