All,
The K Help Center has no documentation in it. It shows all the apps installed, but there is no documentation for any of it. Is that a build time issue (i.e. DOCPATH), or is there a problem with the generation of help files? Here is a screenshot of khelpcenter:
http://www.3111skyline.com/dl/dt/trinity/ss/tde-no-documentation.jpg
Is there an internal setting that will fix this? I just let the build put the documentation in its default location after setting prefix=/opt/trinity (TDEDIR).
On 04/03/2012 08:34 AM, David C. Rankin wrote:
All,
The K Help Center has no documentation in it. It shows all the apps installed, but there is no documentation for any of it. Is that a build time issue (i.e. DOCPATH), or is there a problem with the generation of help files? Here is a screenshot of khelpcenter:
http://www.3111skyline.com/dl/dt/trinity/ss/tde-no-documentation.jpg
Is there an internal setting that will fix this? I just let the build put the documentation in its default location after setting prefix=/opt/trinity (TDEDIR).
The build files seem to be installing help files in TWO different locations by default. Specifically, documentation is either installed in:
${TDEDIR}/share/doc/HTML/en
or
${TDEDIR}/share/doc/kde/HTML/en
with a ksquirrel-libs installed as a loner at:
/opt/trinity/share/doc/ksquirrel-libs/
There is NO rhyme or reason to where to files go. No CMake build verses autoconf build explanation. What gives? The full listing of where the different files for different packages go by default are here:
/opt/trinity/share/doc
HTML kde ksquirrel-libs
/opt/trinity/share/doc/HTML/en
KRegExpEditor amor ark atlantik basket blinken bookreader cervisia doc filelight gwenview irkick k3b k9copy kaffeine kalzium kanagram kasteroids kate kate-plugins katomic kbabel kbackgammon kbattleship kblackbox kbounce kbruch kbugbuster kcalc kcharselect kcmlirc kcontrol kcron kdat kdcop kdebugdialog kdf kdiff3 kdirstat kedit keduca kenolaba kfind kfloppy kfouleggs kgeography kgoldrunner kgpg khangman khelpcenter khexedit kicker kicker-applets kig kima kinfocenter kioslave kipi-plugins kiten kjots kjumpingcube klatin klettres klickety klines klipper kmag kmahjongg kmenuedit kmines kmoon kmousetool kmouth kmplot knetattach knetstats knetworkconf knutclient kodo kolf kompare kompmgr konq-plugins konqueror konquest konsole konversation kpackage kpager kpat kpercentage kpoker krename kreversi krusader ksame kshisen ksig ksim ksirtet ksmiletris ksnake ksokoban kspaceduel ksplashml kstars ksysguard ksysv kteatime ktimer ktouch ktron kttsd ktuberling kturtle kuser kverbos kvoctrain kwallet kweather kwordquiz kworldclock kwrite kxkb lilo-config lskat soundkonverter superkaramba tdecachegrind tdeprint tdesu tdesvn-build tdm twin4 umbrello
/opt/trinity/share/doc/kde/HTML/en
abakus akregator amarok common kaddressbook kalarm kamera kandy karm kcoloredit kcontrol kdict kdvi kgamma kget kghostview kiconedit kio-locate kleopatra kmail knewsticker knode knotes kolourpaint konsolekalendar kontact kooka kopete korganizer korn kpdf kpf kpilot kpovmodeler kppp krdc krfb kruler ksirc ksnapshot kspell ktalkd ktnef kuickshow kview kwatchgnupg kwifimanager lisa rosegarden tdesvn
/opt/trinity/share/doc/ksquirrel-libs/0.8.0
belka_bkgr.gif bits.html development-highlev.html how_to_build_arrow.png how_to_build_c++.png how_to_build_c.png how_to_build_codec.png index.html ksquirrel-libs-about.html ksquirrel-libs-fio.html ksquirrel-libs-metainfo.html ksquirrel-libs-olibs.html ksquirrel-libs-olibs1.html ksquirrel-libs-olibs2.html ksquirrel-libs-olibs3.html ksquirrel-libs-struct.html styles.css
On 04/03/2012 11:32 AM, David C. Rankin wrote: <snip>
There is NO rhyme or reason to where to files go. No CMake build verses autoconf build explanation. What gives? The full listing of where the different files for different packages go by default are here:
<snip>
A quick example will bring this home:
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/
Where can this be fixed in the CMake files? I thought keeping all this consistent was the purpose of all the submodule includes in the GIT tree? I'll check the bug tracker, if there isn't anything, I'll add one. This should be a blocker of R14... The help files should be available through tde help center.
The K Help Center has no documentation in it. It shows all the apps installed, but there is no documentation for any of it. Is that a build time issue (i.e. DOCPATH), or is there a problem with the generation of help files? Here is a screenshot of khelpcenter:
http://www.3111skyline.com/dl/dt/trinity/ss/tde-no-documentation.jpg
Is there an internal setting that will fix this? I just let the build put the documentation in its default location after setting prefix=/opt/trinity (TDEDIR).
Refer to bug report 660. This has been a long-standing issue.
Do not use the patch attached to that bug report (I need to remove the patch).
I resolve the problem here locally by using a different method. In my master build script I run a function to modify all the files on-the-fly. On my to do list is creating individual patches through this method so I can update each module through GIT. Also tdelibs has to be patched. The location in tdelibs controls whether you see any help files.
In tdelibs I run the following patch:
==================================================== diff -urN tdelibs/tdecore/kstandarddirs.cpp tdelibs.new/tdecore/kstandarddirs.cpp --- tdelibs/tdecore/kstandarddirs.cpp 2011-08-20 23:15:32.000000000 -0500 +++ tdelibs.new/tdecore/kstandarddirs.cpp 2011-11-26 17:33:31.148545755 -0600 @@ -1030,7 +1030,7 @@ if (!strcmp(type, "html-bundle")) return "share/doc-bundle/HTML/"; if (!strcmp(type, "html")) - return "share/doc/kde/HTML/"; + return "share/doc/tde/HTML/"; if (!strcmp(type, "icon")) return "share/icons/"; if (!strcmp(type, "config")) ====================================================
In my master build script I run the following against every package I build:
==================================================== # Note: tdelibs/tdecore/kstandarddirs.cpp is fixed with a patch in tdelibs. find $APP_SOURCES_DIR -name TDESetupPaths.cmake -exec sed -i 's|${SHARE_INSTALL_PREFIX}/doc/kde/HTML|${SHARE_INSTALL_PREFIX}/doc/tde/HTML|g' {} ; find $APP_SOURCES_DIR -name debianrules -exec sed -i 's|$kde_prefix/share/doc/kde/HTML|$kde_prefix/share/doc/tde/HTML|g' {} ; find $APP_SOURCES_DIR -name am_edit -exec sed -i 's|$kde_prefix/share/doc/kde/HTML|$kde_prefix/share/doc/tde/HTML|g' {} ; find $APP_SOURCES_DIR -type f -exec sed -i 's|{datadir}/doc/HTML|{datadir}/doc/tde/HTML|g' {} ; find $APP_SOURCES_DIR -type f -exec sed -i 's|share/doc/HTML|share/doc/tde/HTML|g' {} ; ====================================================
I do not build anything inside my local source tree. I copy each module to $TMP and patch and build there, just like with a tarball. Therefore $APP_SOURCES_DIR refers to my copied location, not to my local repository.
The final directory location of $PREFIX/share/doc/tde/HTML avoids potential conflicts with KDE4.
I have not yet started to patch each module individually because I have been testing this method. Thus far everything is building as I expect, all help files are now install in the same location, and there are no help center problems.
Although I build most of the additional apps, I don't build them all and I need to update those packages too.
I should start patching each module because this bug is a thorn. The big challenge is any final changes need to be pushed in one effort. When I do that I'll post a warning.
Darrell
On 04/03/2012 02:40 PM, Darrell Anderson wrote:
I have not yet started to patch each module individually because I have been testing this method. Thus far everything is building as I expect, all help files are now install in the same location, and there are no help center problems.
Although I build most of the additional apps, I don't build them all and I need to update those packages too.
I should start patching each module because this bug is a thorn. The big challenge is any final changes need to be pushed in one effort. When I do that I'll post a warning.
Darrell
UUGH!!
Great work Darrell!! I concur with $PREFIX/share/doc/tde/HTML. That is the proper location.
I don't see why this can't all be fixed with a single patch to tdelibs setting the html docpath to $PREFIX/share/doc/tde/HTML and then the /admin and /cmake files fixed so that all apps are built with the correct docpath? I don't know, but isn't there a way in the /admin and /cmake stuff to set the following project wide:
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR]
Like I said, I don't know, but it seems that if that is possible, it sure beats patching the code in every single app :)
Great work Darrell!! I concur with $PREFIX/share/doc/tde/HTML. That is the proper location.
I don't see why this can't all be fixed with a single patch to tdelibs setting the html docpath to $PREFIX/share/doc/tde/HTML and then the /admin and /cmake files fixed so that all apps are built with the correct docpath? I don't know, but isn't there a way in the /admin and /cmake stuff to set the following project wide:
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR]
Like I said, I don't know, but it seems that if that is possible, it sure beats patching the code in every single app :)
That is what my on-the-fly patching does in my master build script: fixes the admin and cmake directory in each module. I don't know whether there is a shortcut to fixing the mess.
There is a common admin and cmake directory in the source tree, but I don't know how that is related to the individual admin and cmake directories in each module. Are those common admin and cmake directories replicated nightly to the individual modules ?
Darrell
On 04/03/2012 04:38 PM, Darrell Anderson wrote:
That is what my on-the-fly patching does in my master build script: fixes the admin and cmake directory in each module. I don't know whether there is a shortcut to fixing the mess.
There is a common admin and cmake directory in the source tree, but I don't know how that is related to the individual admin and cmake directories in each module. Are those common admin and cmake directories replicated nightly to the individual modules ?
Darrell
Short answer - I don't know, but my understanding is 'yes' -- those are replicated/updated when you update the git tree. That's the whole purpose behind the submodule init stuff. Having standardization behind the build mechanics of every module/app in the TDE project. The /admin and /cmake files would be the proper place to do all this if the path info can be set there. I know that is the proper place for the cmake 'tde_setup_paths( )' magic to take place and I suspect the same can be done for all the autoconf files through acinclude.m4.in files (or something similar).
Those are the dimly lit misty places where the likes of the 'White Wizard' and the creature called 'sameleian' lurk and control the keys to the rest of the kingdom. I think with a small amount of magic, those two could probably unlock the secret to getting the doc files in the right place without having to mount a frontal attack on the individual modules themselves :)
Looking at the cmake files for tdelibs/tdebase/etc.. the doc paths are not set in the top-level CMakeLists.txt file along with the other paths that are specified. I suspect that is the answer...
-
Darrell Anderson -
David C. Rankin