version script for libkdeui

[Lubos Lunak]

On Monday 15 of March 2004 16:50, Luciano Montanaro wrote:
> On Monday 15 March 2004 15:03, Lubos Lunak wrote:
> > On Sunday 14 of March 2004 03:36, Luciano Montanaro wrote:
> > > 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.
> >
> >  Damn. I'll have to write the script for --enable-nmcheck myself then ;).
>
> Can you explain a bit more? What is --enable-nmcheck supposed to do?

 Just run $topsrcdir/admin/nmcheck libkdecore.la $srcdir/libkdecore.nmcheck . 
--enable-nmcheck should do that automatically, but I added it only to 
am_edit, as I didn't know the wonders of unsermake at that time yet.

> Maybe I can still help. Although I suspect you want me to sieve through
> the headers to find and mark internal methods...

 No, a script to search the *.h files and output list of all exported symbols 
would be enough ;). Nevermind, that shouldn't be that difficult, and KDE4 is 
still some time away.

> >  That's actually exactly my point. Gcc currently can't hide a whole
> > class. The linker can. And this we'll stay to be the case until everybody
> > upgrades to gcc-3.4(hopefully it'll be fixed there). So by using the
> > macros the sources will be prepared for such compilers, and it'll be
> > clear what's public and what's not, while a script converting this info
> > to a linker script would provide (and keep up to date) this information
> > for people without such compiler.
>
> But these macros should be used for methods of classes whose interface is
> intended to be exported, and a namespace to mark internal classes.
> Hiding a whole class would be a relatively small work, hiding a conspicuous
> number of symbols, while finding internal methods in otherwise exported
> interfaces would need patience and deeper knowledge of the classes. So, to
> test the waters, I'd start with the namespace work.

 Not even Qt has it that detailed, either a class is exported or not. I doubt 
it'd be worth the trouble.

> >  Is the performance difference measurable?
>
> I can't perceive on my home computer. I'll try to get some number when I
> get back near it, next weekend.
>
> I'll try to "LD_DEBUG=statistics konqueror" a few times with and without
> the version scripts enabled. Is there some better test out there?

 'time konsole -e echo' ? No better idea, it's the time that ultimately 
matters though, isn't it?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/