From: Evan S. <ev...@dr...> - 2006-04-15 17:49:32
|
On Apr 15, 2006, at 12:08 PM, Tim Ringenbach wrote: > Since we're on this topic.. > One thing that always confused me was how headers with the same > name worked > If I'm in a prpl and that prpl has a util.h, and Gaim's core also > has a util.h, how do I know which one I'm #including? > Probably the first one in the search order. So how do I include both? > > Since this wasn't used as an argument, I'll assume there's a way > that works fine. That's the same point Mark made to me elsewhere. It's a much more generally applicable ponder than the reasons I elucidated... > Also, why is the framework being staticly compiled? I'm not sure > how it all works on OSX, but that sounds like that has one big suck > point in that you can't add 3rd party prpls like you can with gaim. > Unless you don't disable plugins, but just build all the ones that > come with Gaim staticly. > I'm also not sure if you mean you compiled the whole thing as a > single dylib, or a single static library. I'm not sure how you'd build statically without disabling plugins... that's an interesting idea. In any case, with plugins disabled (#undef GAIM_PLUGINS) you can still load additional plugins -- you have just have to call their gaim_init_foo_plugin() somewhere. Since a good Adium plugin hooking into Libgaim is going to have non-Gaim parts, the Adium plugin's initializer can call this... that's how our external IRC prpl plugin currently works. It's being "statically compiled" (or so I thought the term was) primarily as a binary size consideration. We have to include every Gaim dependency in a way that Adium-lIbgaim can use, so the Gaim 'binary' itself actually includes all the used code from gettext, glib, libgcrypt, libgpg-error, libiconv, and libj2k, with libgadu, meanwhile, and libtor thrown in for their appropriate specific plugins. These libraries, and Gaim and plugins, have to be compiled for two architectures, OS X ppc and OS X i386. That part doesn't have to be static -- the Libgaim binary reports (via file) as: Libgaim: Mach-O fat file with 2 architectures Libgaim (for architecture i386): Mach-O dynamically linked shared library i386 Libgaim (for architecture ppc): Mach-O dynamically linked shared library ppc It looks like I was using the wrong word, based on that reporting -- I'm compiling the whole thing as a single dylib, not a single static library. The Gaim build settings via config.h include #undef GAIM_PLUGINS, though, and I thought that meant I was compiling them statically based on what i was observing. Could you please explain the difference? Compiling each plugin as a .so ("dynamic compilation," I thought of it as) and including them somewhere you can add to the plugin search paths works just fine -- this is how Adium 1.0svn was doing it for the last month or so, a change I made specifically to support 3rd party prpls as you describe. Once I realized what I said in my first paragraph above -- that you can just have it run the gaim_init_foo_plugin() function -- I switched it back to the all-in- one-file compilation for the core + dependencies + plugins, because it makes a difference of just over a megabyte in binary size with no functional difference I could detect. I am not an expert by any means at compilation and linking... if somewhere in the above I said something that sounds ridiculous or misguided, it's probably because it is. Any corrections or suggestions would be appreciated :) > I'm also not sure why you need to copy all the files together like > that, on Linux gaim's ./configure script has options to staticly > link prpls and doesn't need that. Is that just a framework thing? Just a framework thing -- I could meticulously set up the build process the create a folder within Libgaim.framework/Headers for each prpl, but I haven't because it hasn't been necessary yet because thus far the prpl headers I've needed to use were big ones like aim.h and jabber.h. -Evan |