20 Aug
2012
20 Aug
'12
10:26 a.m.
Why not fix this once and for all, fix tdelibs, and
just set:
kde_htmldir='\${datadir}/doc/HTML'
for all??
That way, instead of patching hundreds of autotools
packages, the original location in tdelibs is standardized where it should be in
'kstandarddirs.cpp', the CMake files are corrected to match the original
kde_htmldir locations in their sources, and all future CMake migration can go forward
without every set of files having to set kde_htmldir and reset it for 3513 in
another set of patches... (this stuff should be standard anyway -- there is
absolutely no need to have 'kde' or 'tde' in the middle of kde_htmldir)
Because adding the /tde/ (nee /kde/) subdirectory ensures there are no conflicts, real or
imagined, with KDE3/KDE4.
By default KDE4 is hard-coded to install help files to share/doc/HTML. I checked the 4.8.5
source code.
You could modify only kstandarddirs.cpp and the cmake converted packages, but then risk
conflict with KDE. That was my original proposal long ago too. Then I realized the
potential conflict existed and only resolved one problem while creating another. Hence the
eventual comprehensive change of all packages.
Generally, most packagers build TDE to install to /opt/trinity. Most packagers build
KDE3/KDE4 to install to /usr. In that case there are no potential conflicts. Yet nothing
stops packagers from building Trinity to install to /usr.
Short history:
In 3.5.10 kdelibs/kdecore/kstandarddirs.cpp, the path was set to share/doc/HTML/.
In SVN commit 1061230 (3.5.11) the path was changed to share/doc/kde/HTML/. This was the
first attempt to avoid potential conflicts.
In GIT commit 979b0c9a the path was changed to share/doc/tde/HTML/, as part of the overall
renaming project.
As noted, everything now installs correctly in R14. The problem is fixing 3.5.13 SRU. SRU
needs to avoid the same potential conflict. Therefore leave
kdelibs/kdecore/kstandarddirs.cpp as is, leave the cmake packages as is, and update the
autotool packages. Backport the R14 patches.
SRU is not patched with the many renaming efforts and therefore should remain at
share/doc/kde/HTML/, just like currently set in kdelibs/kdecore/kstandarddirs.cpp
The help handbook problem existed right from the beginning in 3.5.13 and never noticed by
anybody. I don't know whether the problems existed in 3.5.12 or 3.5.11. I suspect they
did because the autotool files never were updated to match the change made in SVN 1061230
(3.5.11).
I appreciate the desire to avoid work. Yet once the patches are in place the computers do
all the work.
Your frustration right now is the same I experienced last year when I tripped over this
problem. Small consolation, I know. :-)
Darrell