Quite a few 3.5.13 apps will not show associated Help files. A little investigating reveals the apps that show Help files have the Help files installed at:
/opt/trinity/share/doc/kde/HTML
Those apps that won't show Help files have the help files installed at:
/opt/trinity/share/doc/HTML
Is this a build issue at my end? Do I need to specify an explicit install location for help files or is this a configuration bug with the make files?
There are quite a few apps like this.
Darrell
Le 25/11/2011 20:50, Darrell Anderson a écrit :
Quite a few 3.5.13 apps will not show associated Help files. A little investigating reveals the apps that show Help files have the Help files installed at:
/opt/trinity/share/doc/kde/HTML
Those apps that won't show Help files have the help files installed at:
/opt/trinity/share/doc/HTML
Is this a build issue at my end? Do I need to specify an explicit install location for help files or is this a configuration bug with the make files?
There are quite a few apps like this.
Hello, I obtain the same result in Fedora/RHEL builds, so it is not distro-specific. I already noticed this but I did not dare moving 'share/doc/*' to 'share/doc/kde'. It can be easyly "fixed" in packaging process, but there should be a better solution
At least the following core packages are affected: kdebase kdegraphics kdelibs kdenetwork kdepim kdesdk
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 ?
On Friday 25 November 2011 22:35:52 François ANDRIOT wrote: [...]
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.
Le 25/11/2011 21:39, Serghei Amelian a écrit :
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.
Oops sorry I messed up with directories: it is exactly the contrary of my previous mail. The CMAKE packages doc are correctly installed under 'share/doc/kde'.
There are some non-CMAKE packages (kdemultimedia, kdeutils ...) that do NOT create the 'kde' subdir.
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.
Darrell
On Friday 25 November 2011 22:56:56 Darrell Anderson wrote: [...]
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.
kdegames are not ported to cmake yet. Check your autotools config parameters.
Le 25/11/2011 21:56, Darrell Anderson a écrit :
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.
Darrell
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 :)
Francois Andriot
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
-
Darrell Anderson -
François ANDRIOT -
Serghei Amelian