compile problems with xfrun

[edscott]

El jue, 22-07-2004 a las 10:53, Brian J. Tarricone escribió:

> > > 
> > > Hmm, I don't think I like the sound of that ;)
> 
> nor do i.

The sound is not clear. I'm afraid you do not understand. 


> 
> 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.
> 

I think you are talking about something else. If you keep symbols
around, then you are not unloading code that has already been used and
is not required at the moment. For example, say I want a dialog popup
from libxfcegui4, but only after certain conditions are met. And I don't
want the dialog construction code hanging around after I'm done with it
(along with all the other code from the library). When you leave the
dynamic loading up to the operating system instead of proceeding in a
cold, calculating way, you are stuck with stuff you no longer need. 

> 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.

After today's commit, the setup is better. The modules are not loaded if
both libdbh *and* xfheaders are not found at compile-time. 

> 
> 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.

You like hacks, I try to avoid them (though not always successfully).
Since libxfcegui4 and libxfce4util  are *required* by other xfce stuff,
it makes no difference whether or not they are in xfheaders or in their
own directory: just a matter of system integration. 

The idea is, if library headers are grouped together, then there would
only be one dependency to satisfy. Compilation of the rest of xfce
components could proceed in any order. Yes, I know this is not the way
gnome or kde do it. Forgive me for suggesting a novel approach. I was
unaware you were against new ideas (which are maybe not even that new
anyways).

> 
> 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.

No, it seems you don't understand. Maybe I don't want to install
xfce4-modules today. Good. Xfrun will not use the combo module. Tomorrow
I can install xfce4-modules and xfrun will use the combo module without
need to recompile. If xfce4-modules installs its own headers, then there
would be a dependency in xfrun4 (which Jasper correctly pointed out).
That dependency is now removed.