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