ldb_handler_fold: public or private?

Matthias Dieter Wallnöfer mdw at samba.org
Mon Apr 11 07:18:52 MDT 2011


Just as a reminder: how can we agree on this?

We should really fix this - it doesn't seem to be hard. I would be 
satisfied with an additional "static" (as Jelmer suggests).

Cheers,
Matthias

simo wrote:
> On Tue, 2011-03-22 at 11:03 +1100, Andrew Bartlett wrote:
>    
>> On Mon, 2011-03-21 at 08:43 -0400, simo wrote:
>>
>>      
>>> Well breaking the ABI for free gain us nothing.
>>> I would put a comment on the function, and try to remember to turn it
>>> into a static the next time we make some big ABI change.
>>>
>>> Maybe we can define a macro that will do that automatically ...
>>> Something like:
>>> #if MAJORVER>  X
>>> static
>>> #endif
>>>
>>> So that it will be automatically made static the next time we change ver
>>> even if we do not remember that, and then we can remove the if/endif
>>> block the first time someone notices.
>>>        
>> Simo,
>>
>> I really think this is overkill.  The function should, given the
>> circumstances described, be static.  If it's not in a header, then
>> nobody is using it (if they are, they are broken and deserve to keep
>> both pieces).
>>      
> It cost us nothing to avoid this for a while, that's why I proposed that
> solution.
>
>    
>> Are you also saying that if a function was declared in ldb_private.h,
>> that it also can't be removed?
>>      
> No, you can remove anything you want from private headers, as their
> content shouldn't change the ABI.
>
>    
>> Similarly, the ABI generator doesn't know that we reserve the right to
>> change ldb_modules.h defined functions in a minor version, because we
>> put an exact version check into ldb module loading.
>>      
> Which is something we need to change, rebuilding sssd for every minor
> change of ldb is a pain in the arse, as it forces sssd and libldb to go
> in locksteps for no good reason. We should have a module version we
> change only when there is an actual change needed on the modules side.
>
> And when that happen we should change the Y version imho, this way sssd
> can be made to depend on 1.0.x and needs to be rebuilt only when we
> switch to 1.1.x
>
> Simo.
>
>    



More information about the samba-technical mailing list