xffm, libraries and 'interface'

[edscott wilson garcia]

Maarten:

I've now added the G_MODULE_EXPORT to all exported symbols and created
an IMPORTS file with a perl script. Both the IMPORTS file and the perl
script are in the utils directory. 

regards,

Edscott


El jue, 23-09-2004 a las 07:24, edscott wilson garcia escribió:
> El mié, 22-09-2004 a las 23:03, Maarten Boekhold escribió:
> > > Do you need a list of all symbols exported from the executable to normal
> > > libraries or to module type libraries? 
> > 
> > Both...
> > 
> > > Also, do you need a list of symbols exported from normal libraries to
> > > modules? And from normal libraries to each other? 
> > 
> > Hmmm, from libraries to modules perhaps not, as we could link the 
> > modules against the libraries. But from normal libraries to each other, 
> > perhaps. I suppose it depends on the link order. If we have library A 
> > that references B, and B references A, then there's a circular reference 
> > that you can't resolve with a specific link order. In that case I 
> > suppose we need those symbols in an IMPORTS file.
> > 
> > I haven't yet come across such a situation, so I'm not sure what the 
> > syntax of such an IMPORTS file should be, i.e. I'm not sure if:
> > 
> > IMPORTS
> > the_symbol = thelib.dll.the_symbol
> > 
> > will work. This will require a bit of testing.
> 
> OK. The final formatting of the IMPORTS file can be done by testing. 
> 
> > 
> > > I suspect you will need all.
> > > 
> > > If that is the case, I can change all "extern" statements to 
> > > G_MODULE_IMPORT, and then write a perl parser to create an IMPORTS file
> > > (this will make maintainance easier since symbols are moved around at
> > > times).
> > 
> > I did something similar with the panel, except I created a shell script 
> > that works on G_MODULE_EXPORT (i.e. not G_MODULE_IMPORT). Actually, I 
> > couldnt' work out how to directly extract that from the source, so I 
> > added comments /* EXPORT:symbol */ to the panel source code...
> 
> I believe it might be easier to do with perl.
>   
> > 
> > > Using "G_MODULE_EXPORT" for all exported symbols would be no problem
> > > (AFAIK, in Linux it gets expanded to nothing). In fact, it would make
> > > the G_MODULE_IMPORT scheme described above a bit clearer. Would using
> > > G_MODULE_EXPORT in front of the symbol definitions work instead of
> > > DLLEXPORT?
> > 
> > G_MODULE_EXPORT works fine. G_MODULE_EXPORT expands to the same thing as 
> > DLLEXPORT (in fact I copied this from the gmodule.h file...)
> > 
> > G_MODULE_IMPORT would look more correct, but it expands to 'extern' on 
> > just about every platform I know about, so if you really want, you can 
> > keep the 'extern' declaration.
> 
> OK. I will start adding this to the source. I should probably be done in
> a day or two.
> 
> > 
> > Did I understand from one of your previous mails that you are in the 
> > process of converting lots of these 'normal libraries' to 'modules'? 
> > I.e. move them from ../libs to ../modules?
> 
> Just the libraries that take care of the bookmarks, recent/frequent, and
> trash branches. The idea is to allow the writing up of branches as
> plugins.
> 
> I would also like to convert other libraries to plugins (for startup
> performance reasons) but they are currently quite tangled up. 
> 
> > 
> > Jasper mentioned that he was planning on converting the panel (and 
> > other) plugin interfaces to use GtkPlug/GtkSocket. I don't know (yet) 
> > what that actually is, but if you are reorganizing the modules/libraries 
> >   handling for xffm, it might make sense to have a look at this as well, 
> > to come up with a consistent model across xfce. This would be for 4.4 or 
> > later of course... I was planning to start looking at this as well, see 
> > if I can help jasper out with this.
> 
> This, AFAICT, is so that segv signals in the plugins will not crash the
> panel. We must see how it works in the panel to decide whether
> GtkPlug/GtkSocket would be applicable.
> 
> regards,
> 
> Edscott
> 
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://lunar-linux.org/mailman/listinfo/xfce4-dev
>