> >>> It looks like (correct me if I'm wrong) these
> are
> >> CMAKE-ported packages.
> >>> Did we miss a CMAKE variable that indicates
> the
> >> location of 'doc'
> >>> directory ?
> >> Check */cmake/modules/TDESetupPaths.cmake for all
> paths.
> > I have been doing that. I'm not find a pattern. For
> example, the TDESetupPaths.cmake files for kdebase and
> kdegames are identical. The kdebase Help files all install
> to /opt/trinity/share/doc/kde/HTML. All of the kdegames Help
> files install to /opt/trinity/share/doc/HTML.
> > 
> > None of the apps in kdegames can find the Help files.
> > 
> > kdemultimedia is the same as kdegames, although built
> with autotools. The apps can't find the Help files.
> > 

> Concerning the autotools-built packages, I found out that
> the file 'admin/acinclude.m4' defines the kde_htmldir
> variable as below :
> 
>   if test -z "$kde_htmldir"; then
>     kde_htmldir='\${datadir}/doc/HTML'
>   fi
> 
> I can workaround it by modifying this file before the "make
> -f admin/Makefile.common".
> e.g modify the line with:
>     kde_htmldir='\${datadir}/doc/HTML/kde'
> 
> Then the HTML documentation are installed in the expected
> directory.
> I guess I will have to rebuild a lot of packages :)

I haven't looked at every package yet, but I'm guessing all or most of those built with autotools are the ones that can't find the Help files.

In 3.5.12 all of the package apps found the Help files. Those packages built with autotools have not changed from 3.5.12. Only the ones ported to cmake have changed.

I'm guessing because the foundation packages have been ported to cmake, and those have been changed to ${SHARE_INSTALL_PREFIX}/doc/kde/HTML, that the new path sets the tone for all other TDE packages. Because the packages built with autotools have not been changed to sync with this new location, none of the apps can find the Help files, which are installed in the same location as 3.5.12.

This is similar to bug reports 599 and 600. In those reports, the header files are installed in ${INCLUDE_INSTALL_DIR}/kde/ rather than ${INCLUDE_INSTALL_DIR}/. Those new unexpected locations cause other packages that depend upon those header files to fail to build.

The same thing is happening with the Help files. Because the base packages are pointing the Help file directory to a new location of /opt/trinity/share/doc/kde/HTML, all other packages that build the Help files to install to the previous location of /opt/trinity/share/doc/HTML cause the apps to not find the Help files.

I'm guessing something in kdelibs or kdebase creates the indexes and they now point to the new location.

I don't know why we are installing files to this new /kde subdirectory. I think the TDESetupPaths.cmake need to be updated to install the Help files to the previous /opt/trinity/share/doc/HTML and not /opt/trinity/share/doc/kde/HTML.

I understand this new path might have been selected to avoid conflicts with KDE4.

If not then I think we need the following:

All TDESetupPaths.cmake files:

As is:
${SHARE_INSTALL_PREFIX}/doc/kde/HTML

Change to:
${SHARE_INSTALL_PREFIX}/doc/HTML

All CMakeLists.txt files:

As is:
DESTINATION \${INCLUDE_INSTALL_DIR}/kde )

Change to:
DESTINATION \${INCLUDE_INSTALL_DIR} )

Please understand I'm NOT blaming anybody. :) I'm just sharing what I observe and offering a simple remedy.

Right now we have a broken Help system. :(

Darrell