Using public headers to write ABI vscripts

[Alexander Bokovoy]

On Fri, Aug 31, 2012 at 12:54 PM, Alexander Bokovoy <ab at samba.org> wrote:
> On Fri, Aug 31, 2012 at 12:28 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>> On Fri, 2012-08-31 at 09:54 +0300, Alexander Bokovoy wrote:
>>> 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()).
>>
>> Getting rid of lazy_initialize_passdb() seems like a good way to break
>> that.  It makes little sense anyway, we already have
>> initialize_password_db(), which must be called anyway to get the
>> pdb_tevent_cxt initialised for pdb_ldap/smbldap idle events.
> yep.
>
> I'll split them up then and turn libpdb and libsmbldap to public libs.
> Guenther and Andreas did suggest the same too.
Stableabi branch is now updated to include these changes:
https://git.samba.org/?p=ab/samba.git/.git;a=shortlog;h=refs/heads/stableabi

I found another way to hide the symbols without breaking
lazy_initialize_passdb().
-- 
/ Alexander Bokovoy