[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: klibfactory cleanup
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-09-24 14:03:58
[Download RAW message or body]

On Mon, Sep 24, 2001 at 03:42:37PM +0200, Harri Porten wrote:
> On Mon, 24 Sep 2001, Simon Hausmann wrote:
> 
> > 
> > The thing I don't like about encoding the component name into the entry point
> > symbol is that (aside from any platform/linking issues) it looks like 
> > redundant information to me. It means for the developer that he has to 
> > specify that very name in three different variants: Once as libfooname.la 
> > in the Makefile.am, once as libfooname in the .desktop file and once as 
> > strange extern "C" init_libfooname() method. Not really easy to use, 
> > compared to for example Qt's approach, where you specify the component 
> > name only one very single time: In the .pro file. In your source you just 
> > write Q_EXPORT_FOO( MyBlah ) and that's about it.
> > 
> > 
> > Yes yes, call me a nitpicker about this tiny little detail in our API ;-)
> 
> How about
> 
> #define KDE_EXPORT_COMPONENT_FACTORY( factory ) \
>    extern "C" void *kde_init#factory() { return new factory; }
> 
> ?

And how do you find out the kde_init<Factory> symbol name when all you know
is the dsoname? :-} (factory argument can be "MyFoo" while the libname is
"libblah", where only the latter you know from the dlopen'ing side)

Do I understand things correctly that it comes down to the question if
we want to be able to statically link components and if we want to run
on platforms unsupported by Qt? ;-)


Simon

[prev in list] [next in list] [prev in thread] [next in thread]