compile problems with xfrun

[Brian J. Tarricone]

On Thu, 22 Jul 2004, edscott wrote:

> El jue, 22-07-2004 a las 10:53, Brian J. Tarricone escribió:
> 
> > 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. 

unless you're assuming that xffm is going to be used heavily without 
xfce, this is really irrelevant.  libxfcegui4 will already be in memory, 
and, as a shared library, will not need to be reopened when you dlopen() 
it.

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

uhh... there is a very strong precedent for using stub libraries to 
dynamically load optional dependencies at runtime.  my way is most 
definitely not a hack, and you certainly don't know me well enough to 
assume that i "like hacks".  nothing could be further from the truth.  i 
conceed that hacks do have their place, but they're no replacement for a 
thorough design process.  your arbitrary acts here, without any sort of 
discussion, does not fit the definition of "thorough" in the slightest.

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

again, you're attributing beliefs and attitudes to me that you simply 
know nothing about.  i'm fine with new ideas, if they are based on sound 
design principles.  moving all public header files out of their owning 
package gives xfce as a whole nothing.  maybe it makes a couple things 
easier for xffm and a few of the smaller utilities, but now the panel, 
xfdesktop, the mcs manager, and xfwm4 would need to depend on an extra, 
unneeded package for required functionality.

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

what you're describing is a highly unlikely use case that is, IMO, a 
waste of time to plan for.  for one thing, i can't see anyone wanting to 
do that - either you want the modules or you don't.  if you forget about 
them and need to recompile, it's not a big deal.  on the other side, 
most people don't compile their own software, and those do usually do so 
through some kind of source-based package manager, where all 
dependencies are handled ahead of time  (certainly, the binary distros 
will make this choice for the user well in advance).  if libdbh and 
xfce4-modules were huge, lumbering, bloated dependencies, i might - 
_might_ - ignore all that and try to make it more modular, but in this 
case it just isn't worth it.

	-brian