version script for libkdeui

[Luciano Montanaro]

On Saturday 13 March 2004 21:06, Lubos Lunak wrote:
> Dne so 13. března 2004 17:23 Luciano Montanaro napsal(a):
> > I have spent some time trying to build a version script for the kdeui
> > library, like those currently available for libkjs and libkhtml.
> > It contains all the classes which are in the NOINST includes,
> > plus a few that seem to be marked as private.
> >
> > I am trying the library just now, and it does not seem to have any
> > bad effect. Using the script, 313 "T" symbols are hidden in the library,
> > out out of 5435. That's not much. I'd like to try the same for libkio and
> > libkdecore. Do you think the effort is worth it?
>
>  No. You'd have to update the files until the end of your life ;). 

If the version scripts had to be perfectly accurate, yes. Is that really 
needed? The approach is similar to that used for the khtml and kjs modules,
and yes, I agree it is more of a stopgap measure than anything else.

>  I suggest writing a script that will read all to-be-installed *.h files,
> check for KDE_EXPORT/KDE_NO_EXPORT, and build the file from that. 

If the includes already used the KDE_EXPORT/KDE_NO_EXPORT macros, there would 
be no need for version scripts (or very little). The KDE_NO_EXPORT macro
expands to __attribute__((visibility("hidden"))), while KDE_EXPORT expands to
__attribute__((visibility("visible"))) (which, by the way, is not documented 
in the Gcc documentation. Is it ever used? I suspect not...) so the effect
should be the same as putting the symbol in the local list. The symbols that 
can't be hidden this way are the vtable and typeinfo symbols for the various 
classes, which, if I remember correctly, are quite interesting things to 
hide. Am I missing something else? 

> Given that the kdemacros.h file even gives specific instructions where to 
> put all the macros in the various kinds of type definitions, the script
> could be even quite simple. It'd most probably also require adding the
> macros also to all the places in the .h files though.

Maybe library internal or private classes could be put in a separate 
namespace. This way, the version script could be just:

{
local:
  extern "C++" {
    KdeInternal::*;
  };
};

or something similar.
Anyway, using the macros and namespace could be better also from a "program  
documentation" point of view, but it is also a lot more work.

Luciano

PS. I am now trying a version script also for libkdecore. This one trims ~300
symbols from an overall of ~3500. However, I discovered that some of the 
"internal" symbols are in fact used by other libraries in kdelibs (at least 
in kio).

-- 
Luciano Montanaro //
                \X/ mikelima at virgilio.it