Olivier's attention required [was: compile problems...]

[edscott]

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

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

Yea, you have a good point here. Do we want to make libxfcegui4 larger?


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

I might have worded some crazy ideas (viewed in retrospect) about
libxfcegui4 and libxfceutil4, but I *never* did any arbitrary acts with
them. For Pete's sake, if you look my recent commits you will see that I
rather did a cut and paste to customize both buttons of the confirm
dialog rather than doing any arbitrary acts, like modify the code in a
way which might not suit Jasper.


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

Yea that was an incorrect (nearsighted) idea. It just slipped from my
fingers while I typed. Just forget I ever typed libxfcegui4/libxfceutil4
and focus on the real issue: xfce4-modules.

Notwithstanding, in order to retain the behaviour of xfce4-modules (as
before all this .config/.cache stuff), it was necessary to separate the
header files. See other options below.


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

I beg to differ in opinion. Xfce is small, fast and powerful. Planning
for that is not waste of time, it is a priority.

Did you know that the sum of 1/n goes to infinity, eventhough the terms
go to zero as n increases? Get a sufficient number of small libraries
and you can bring any system to its knees. 

Anyways, this ain't a democracy. Comrade Olivier is chairman and
responsible for the decisions. These are the options I see (feel free to
add any others):

1- Separate xfce4-module headers (as shown in CVS)
2- Put the module headers back to where they were and add a dependency
for xfce-utils (that's real easy).
3- Put the headers into libxfcegui4 or libxfceutil and keep
xfce4-modules separate.
4- Put both modules and headers into libxfcegui4 or libxfceutil.
5- Incorporate the xfce4-modules code directly into one of the two above
libraries.
6- send xfce4-modules and all code that depends on it to Gulag-19.
7- none of the above.
8- all of the above.

Olivier? Are you reading?

The option I prefer is the one already committed to CVS. Easier to show
than tell. People always seem to get angry when I write words at them.
I'm sure I got on your nerves, Brian.


Best regards,

Edscott