Le 19/08/2012 08:46, David C. Rankin a écrit : > On 08/18/2012 04:22 PM, David C. Rankin wrote: >> On 08/18/2012 08:59 AM, Darrell Anderson wrote: >>> Read my comments in bug report 1178. >>> >>> Darrell >>> >> Thank you! >> >> I'll pick through the mess as soon as I recover from a 7 and two 9 year-old >> sleepover last night..... Very painful.... >> > Here is the current doc install situation in 3513: > > /opt/trinity/share/doc > HTML/en -- BAD > <majority missing apps are here> > kde/HTML/en --OK > ksquirrel-libs -- BAD > tde/HTML/en -- BAD > abakus > krename > > Basically the working docpath in 3513 is: > > /opt/trinity/share/doc/kde/HTML/en > > all other locations are not included in khelpcenter. The incorrectly installed > documents account for more than 50% of the application manuals. > > Slavek, should we consider /opt/trinity/share/doc/kde/HTML the standard docpath > in 3513-sru? If so I'll look at creating patches. > I agree that all packages should have the same default HTML directory location, that would work by default. But I think we should not hardcode a "kde" directory now in GIT, since we are trying to get rid of kde references. Currently in 3.5.13, it looks like all cmake-built (including tdelibs ...) packages default to "doc/kde/HTML", whereas autotools-built default to "doc/HTML". Most applications still use autotools, that's why their HTML directory is not consistent with tdelibs. To avoid this, I hardcode the directory directly in the build process in autotools-built packages. Something like: sed -i admin/acinclude.m4.in -e "s|kde_htmldir='.*'|kde_htmldir='/opt/trinity/share/doc/kde/HTML'|g" This is a just a workaround until we take a final decision. Francois