compile problems with xfrun

[Brian J. Tarricone]

On Thu, 22 Jul 2004, edscott wrote:

> El jue, 22-07-2004 a las 08:44, Jasper Huijsmans escribió:
> > On Thu, Jul 22, 2004 at 08:05:39AM -0500, edscott wrote:
> > ...
> > > > Edscott, doesn't this create a build-time dependency that was only a run-time
> > > > dependency before? 
> > > 
> > > Uh-huh. In order to retain only run-time dependency only we would need a
> > > package for headers. Like the linux-headers package. 
> > > 
> > 
> > Hmm, I don't think I like the sound of that ;)

nor do i.

> Too late ;) 
> 
> > 
> > It does seem to me that it also makes libdbh a new dependency for Xfce 
> > (instead of for xffm only). I'm not saying that is bad, but it is a change.
> > 
> 
> No, that has not changed. I repeat: the modules code is not available at
> run time if libdbh is not found (modules depends on dbh). Xfutils checks
> for libdbh, but compilation will proceed if it is found or not. Libdbh
> cannot be loaded as a module for performance reasons.

i'm not sure i agree here.  using g_module_open/g_module_symbol should 
not impose a significant performance penalty beyond the setup time of 
resolving your symbols.  assuming you keep these symbols around 
(stored in global function pointers, for example), there shouldn't be a 
noticeable slowdown.  using G_MODULE_BIND_LAZY will further increase 
load time, although that may cause problems later if the user has a 
broken installation.  libdbh doesn't appear to have any deps beyond 
libc, so i can't imagine it would be a problem.

either way, i don't see a problem with the current setup, where the 
modules aren't loaded if libdbh isn't found at compile-time.

> > Anyway, I just wanted to raise the issue here to see if anyone has objections
> > or otherwise strong opinion about it.

so by that you mean you'll email the list and go ahead and do it anyway 
before anyone has a chance to respond?

> Do you have any strong objection? Do you object to changing the location
> of header files for libxfcgui4 and libxfceutil as well? If so, why? I
> want to change the way xffm uses these libraries and do it in a
> load/unload fashion to keep memory footprint down. 

are you saying you're planning on _moving_ the public headers for 
libxfce4util and libxfcegui4 into xfce4/xfheaders?  if so, then yes, i 
have a problem with that.  that's a real pain to maintain, and makes the 
library build procedure problematic.  i don't see why you can't just 
load the libraries you need dynamically if you want to make them 
optional.  if you want the core xfce libs to be optional, you need to 
make xffm work around that, not make the core libs work around you.  
what you need to do is make a stub library that uses 
g_module_open/g_module_symbol to load the symbols you need, and 
statically link that into xffm.  you can either keep a local copy of the 
headers you need with xffm or xfce4-modules, or simply copy out the 
declarations into your stub header and turn them into function pointers.  
i'm sorry if that's a pain for you, as it would require you to keep up 
with library changes, but you can't bend the world to your needs.

furthermore, i don't see why xfheaders is necessary.  why can't 
xfce4-modules simply install its own header files?  i may be 
misunderstanding exactly what you're trying to do here, but i'm sure 
there's a less confusing way of doing this that avoids adding another 
module.

	-brian