On 16/04/18 14:32 +0200, Klaus Wenninger wrote:
> On 04/16/2018 01:52 PM, Jan Pokorný wrote:
>> On 29/03/18 11:13 -0500, Ken Gaillot wrote:
>>> 4. Public API symbols: for example, crm_meta_name() ->
>>> pcmk_meta_name(). This would be a huge project with huge impact, and
>>> will definitely not be done for 2.0.0. We would immediately start using
>>> the new convention for new API symbols, and more slowly update existing
>>> ones (with compatibility wrappers for the old names).
>> Value added here would be putting some commitment behind the "true
>> public API" when the symbols get sifted carefully, leaving some other
>> naming prefixes reserved for private only ones (without any commitment
>> whatsoever).
> Like e.g. pcmk_* & pcmkpriv_*  (preferably something shorter
> for the latter) ?

Yes, something like that (pcmk_* vs. anything not starting with "pcmk_"
might suffice), which would allow for compiling library(ies) twice
-- once for public use (only "public API" symbols visible), once
for pacemaker's own usage (libpcmk_foo_private.so, everything non-static
visible).  That might be a first step towards something supportable,
start with literally nothing in the public version, gradually grow the
numbers, with almost no hassle other than adding symbols to an external
list and/or renaming formerly private-only symbols so as to match the
regexp/glob.  All native executables would naturaly link against
libpcmk_foo_private versions.  Later on, these can be merged or
otherwise restructured.


Attachment: pgprD265u_74B.pgp
Description: PGP signature

Developers mailing list

Reply via email to