Bug 660

This affects more than just kdegames. 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? 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.

Serious paper cut candidate.

The problem seems to be with the cmake conversion.

Those packages converted to cmake have the Help file path set to /opt/trinity/share/doc/kde/HTML.

The packages still using autotools have the Help file path set to /opt/trinity/share/doc/HTML.

Unless there is a reason for this new path, such as avoiding conflicts with KDE4, then the cmake files should be reset to the previous location used in 3.5.12.

Right now, in 3.5.13 we have a broken Help file system. :(

Created attachment 158 [details]
Fix hard-coded path to help files

TDE 3.5.13 contains a broken Help file system because of the mixture of cmake and autotools build processes that place Help files into two different locations.

Rather than try to fix every single build script, in my master build script I run the following inline patch to the cmake files after uncompressing the sources to my build directory:

find $APP_SOURCES_DIR -name TDESetupPaths.cmake -exec sed -i s'|\${SHARE_INSTALL_PREFIX}/doc/kde/HTML|\${SHARE_INSTALL_PREFIX}/doc/HTML|g' {} \;

Applying this one-time search to the entire SVN/GIT tree would repair all affected TDESetupPaths.cmake files and avoid the problem of dependent packages failing to build correctly. No additional patching would be required by packagers.

Included is a patch for kdelibs/kstandarddirs.cpp, which has the help directory hard-coded.

These two changes keep all packages consistent to use a help directory path of ${SHARE_INSTALL_PREFIX}/doc/HTML.

There are unlikely to be any conflicts with KDE4 as most packagers should be building TDE to install to /opt/trinity.

Hello, for your information, I'm doing the exact opposite on the RHEL/Fedora packages: I move every HTML documentation to /opt/trinity/share/doc/kde/HTML.

So I'm doing a "sed" ont he "acinclude.m4.in" file.

sed -i admin/acinclude.m4.in \
  -e "s,kde_htmldir='.*',kde_htmldir='/opt/trinity/share/doc/kde/HTML',g"

Tim,

Conceptually, this is an easy bug to fix. The challenge is every TDESetupPaths.cmake must be patched and pushed --- 117 times.

To globally change all of the TDESetupPaths.cmake files requires only this:

find $GIT_SOURCES_DIR -name TDESetupPaths.cmake -exec sed -i s'|\${SHARE_INSTALL_PREFIX}/doc/kde/HTML|\${SHARE_INSTALL_PREFIX}/doc/HTML|g' {} \;

To individually path each TDESetupPaths.cmake file requires this:

diff -urN tdebase/cmake/modules/TDESetupPaths.cmake tdebase.new/cmake/modules/TDESetupPaths.cmake
--- tdebase/cmake/modules/TDESetupPaths.cmake 2012-03-07 21:51:07.000000000 -0600
+++ tdebase.new/cmake/modules/TDESetupPaths.cmake 2012-03-09 23:20:00.000000000 -0600
@@ -42,7 +42,7 @@
   _tde_internal_setup_path( PLUGIN_INSTALL_DIR        "${LIB_INSTALL_DIR}/trinity"                     "The subdirectory relative to the install prefix where plugins will be installed (default is ${LIB_INSTALL_DIR}/trinity)" )
   _tde_internal_setup_path( CONFIG_INSTALL_DIR        "${SHARE_INSTALL_PREFIX}/config"              "The config file install dir" )
   _tde_internal_setup_path( DATA_INSTALL_DIR          "${SHARE_INSTALL_PREFIX}/apps"                "The parent directory where applications can install their data" )
-  _tde_internal_setup_path( HTML_INSTALL_DIR          "${SHARE_INSTALL_PREFIX}/doc/kde/HTML"        "The HTML install dir for documentation" )
+  _tde_internal_setup_path( HTML_INSTALL_DIR          "${SHARE_INSTALL_PREFIX}/doc/HTML"            "The HTML install dir for documentation" )
   _tde_internal_setup_path( ICON_INSTALL_DIR          "${SHARE_INSTALL_PREFIX}/icons"               "The icon install dir (default ${SHARE_INSTALL_PREFIX}/share/icons/)" )
   _tde_internal_setup_path( KCFG_INSTALL_DIR          "${SHARE_INSTALL_PREFIX}/config.kcfg"         "The install dir for kconfig files" )
   _tde_internal_setup_path( LOCALE_INSTALL_DIR        "${SHARE_INSTALL_PREFIX}/locale"              "The install dir for translations" )

Do you have a handy trick to perform a system-wide change like this? Let me know whether I can help.

Comment on attachment 158 [details]
Fix hard-coded path to help files

I am pulling the patch because a different method needs to be used to sensure no conflicts with KDE4. I am testing that method now.

When satisfied I'll push everything to GIT all at the same time.

I ran into the issue and I tried to determine if there was any rhyme or reason between cmake and autoconf builds that could explain the documentation being installed in different locations -- there wasn't. For instance:

  tdelibs docs are installed in:

    tde-tdelibs /opt/trinity/share/doc/kde/HTML/en/

  tdebase docs are installed in:

    tde-tdebase /opt/trinity/share/doc/HTML/en/

both cmake apps. I don't know if this can be fixed in the /admin or /cmake files, but it would be nice to have all doc files from the project install in a consistent location. That should happen by default unless a packager adjusts the --datarootdir=DIR ( or any of the sub dir locations). It looks to me like setting:

  --datarootdir=${PREFIX}/share

globally would do it. Then everything would default to:

${DATAROOTDIR}/doc/${PACKAGE}/<html,pdf,etc..>

  You may want the mandir explicitly set as:

${DATAROOTDIR}/man

I updated my build environment to automate the creation of patches for each module.

I need to run a complete build cycle to create all of the individual patches.

After creating the patches I need another full build run as a test. Then I need to verify each help handbook displays correctly, verify no stray directories, etc.

Therafter I should be able to push the patches for each module. This will require a few days. Then we'll have this critter resolved.

Changes have been pushed in numerous patches. Check the Commit Patches web page, dates 2012-04-10 and 2012-04-11.

I'll leave this bug report open for a few days to ensure nobody screams from the changes. If not then I'll close as resolved.

There have been no comments or reports for several days. I'm closing this bug report as resolved.