I'm trying to use the cmake-magic to include translations (po's & doc's) in a project. For translations I'm using a self-made script which downloads l10n-data from SVN-server: * po-files are stored in a directory named: l10n-messages/<LANG>/*.po * doc-files are stored in a directory named: l10n-docs/<LANG>/docs/*.docbook The application-code was downloaded from GIT-server before. To combine it with translations, I've copied the translation-dirs (l10n-messages & l10n-docs) into the application-code. Then I tried to append original CMakeLists.txt with the following lines: find_package(KF5I18n CONFIG REQUIRED) ki18n_install(l10n-messages) find_package(KF5DocTools REQUIRED) kdoctools_install(l10n-docs) 1. issue: Found out that doc's strictly have to be placed into the same directory as the po-files, otherwise cmake breaks while processing kdoctools_install() . But shouldn't the functions kdoctools_install(DIR) and ki18n_install(DIR) work independently from each other? It seems that it is not possible to have po's in <DIR1> and doc's in <DIR2> 2. issue: Because of 1st issue I changed my script to download l10n-data from SVN-server like this: * po-files are stored in a directory named: translations/<LANG>/*.po * doc-files are stored in a directory named: translations/<LANG>/docs/*.docbook But cmake still breaks while processing kdoctools_install(), now with the following error: CMake Error at /usr/lib64/cmake/KF5DocTools/KF5DocToolsMacros.cmake:106 (message): SUBDIR needs to be defined when calling kdoctools_create_handbook Call Stack (most recent call first): /usr/lib64/cmake/KF5DocTools/KF5DocToolsMacros.cmake:231 (kdoctools_create_handbook) CMakeLists.txt:116 (kdoctools_install) How to define the missing "SUBDIR"? Shouldn't this be done by kdoctools_install() automatically? Used kf5-kdoctools version: 5.17.0 Reproducible: Always
Any reason you decided to create your own script instead of using existing ones?
Well, this is off-topic but I've made this script a while ago already (KDE4) to be able to create tarballs named in a way I found it useful. Seems that you're aiming at the files found in "releaseme.git". But as far as I could see kdoctools_install() won't be used here (yet?). Instead it seems workarounds are used to add CMakeLists.txt containing the functions kdoctools_create_handbook() and kdoctools_create_manpage() - which IMHO should not be necessary anymore when using kdoctools_install(). In the moment I try do adapt my script to the needs of KF5. With some particular cmake-magic implemented in KF5 my script should even be simpler than to KDE4-times. ki18n_install() is working as expected. kdoctools_install() is not - this is why I filled this report.
Apologize for the long delay. I think that what you hit is a problem with the structure of the directories. You used translations/<LANG>/docs/*.docbook but it should be translations/<LANG>/docs/<manualname>/*.docbook See the example tests/kdoctools_install-test/ inside the kdoctools source directory, and/or the comments in the KF5DocToolsMacros.cmake file. With that structure, it works both when doc translations are "mixed" with interface translations, and when they are in separate directories (tested back to 5.16). Does it work for you?
With a subdir added as suggested, during compilation CMake now complains: > add_custom_target cannot create target "BLA_BLA" because another target with the same > name already exists. The existing target is a custom target created in source directory > ... > ... > See documentation for policy CMP0002 for more details." Adding "cmake_policy(SET CMP0002 OLD)" doesn't help. I still don't get the logic behind all this. Looking at other code-examples: 1) http://download.kde.org/stable/kronometer/2.1.0/src/kronometer-2.1.0.tar.xz 2) http://download.kde.org/stable/ktorrent/5.0/ktorrent-5.0.1.tar.xz These projects include translated PO's => simplified directory-structure (w/o CMakeLists.txt in subdirs) => "ki18n_install()" is used in CMakeLists.txt (root-dir) These projects include translated DOC's => old directory-structure (incl. CMakeLists.txt in any subdir) => "kdoctools_install()" is NOT used in CMakeLists.txt (root-dir) Is it possible for these projects to use "kdoctools_install()" instead - how would I do that? If there would be no solution for this, what is the propose of "kdoctools_install()", then? Thought with "kdoctools_install()" one is able to get rid of these CMakeLists.txt in subdirs by some magic of these CMake-helpers...
(In reply to MaxiPunkt from comment #4) > With a subdir added as suggested, during compilation CMake now complains: > > > add_custom_target cannot create target "BLA_BLA" because another target with the same > > name already exists. The existing target is a custom target created in source directory > > ... > > ... > > See documentation for policy CMP0002 for more details." > Adding "cmake_policy(SET CMP0002 OLD)" doesn't help. Which version of cmake? I tested it with 3.5, but it should work with older versions. The issue with conflicting targets was solved long time ago. Could you please share the example you are testing? > I still don't get the logic behind all this. Looking at other code-examples: > 1) > http://download.kde.org/stable/kronometer/2.1.0/src/kronometer-2.1.0.tar.xz > 2) http://download.kde.org/stable/ktorrent/5.0/ktorrent-5.0.1.tar.xz > > These projects include translated PO's > => simplified directory-structure (w/o CMakeLists.txt in subdirs) > => "ki18n_install()" is used in CMakeLists.txt (root-dir) > > These projects include translated DOC's > => old directory-structure (incl. CMakeLists.txt in any subdir) > => "kdoctools_install()" is NOT used in CMakeLists.txt (root-dir) > > Is it possible for these projects to use "kdoctools_install()" instead - how > would I do that? > > If there would be no solution for this, what is the propose of > "kdoctools_install()", then? Yes, they can use it. It's just that no one implemented its usage in the scripts which create tarballs, probably because the feature was not advertised. I asked around and there is some work in progress, even if it needs some design decision. See https://phabricator.kde.org/T2433
> Which version of cmake? * cmake-3.4.1 * kf5-kdoctools-5.21.0 > Could you please share the example you are testing? Currently I'm trying to compile krusader-kf5 with all bells & whistles (including all translations). Hopefully I'm able to upload current tar.xz I've made of the translations with my self-made script...
Created attachment 98995 [details] krusader-translations from today's SVN tar.xz includes "CMakeLists.txt.l10n" It is intended to be appended to "CMakeLists.txt" of project-code.
I think I know where the issue is, does the change here works for you? https://git.reviewboard.kde.org/r/127935/ You can comment on the review directly if you have an account on identity.kde.org.
Thanks for your recent efforts. To test this I would have to replace system's "kdoctools" with a patched version first, as my system does not allow me to modify system-files (SELinux) manually. Hopefully this is not a time-consuming task, otherwise I will have to give up for now...
Patching "kdoctools" was o.k., but unfortunatelly your patch doesn't work for me. Actually I'm not sure if the errors are related to "kdoctools", or to krusader's DOC's (possibly not not up-to-date?). [ 3%] Generating l10n-docs/pt_BR/docs/krusader/index.cache.bz2 cd /home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186 && /usr/bin/meinproc5 --check --cache /home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu/l10n-docs/pt_BR/docs/krusader/index.cache.bz2 l10n-docs/pt_BR/docs/krusader/index.docbook I/O warning : failed to load external entity "/usr/share/kf5/kdoctools/customization/xsl/pt-BR.xml" No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". ... ... ... [ 3%] Generating l10n-docs/pt/docs/krusader/index.cache.bz2 cd /home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186 && /usr/bin/meinproc5 --check --cache /home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu/l10n-docs/pt/docs/krusader/index.cache.bz2 l10n-docs/pt/docs/krusader/index.docbook No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". installation.docbook:1023: parser error : Entity 'kicon' not defined a partir do &kmenu;. P.ex. no &Mandrake;-&Linux; 10.0 carregue no botão &kicon; ^ installation.docbook:1257: parser error : chunk is not well balanced index.docbook:414: parser error : Failure to process entity installation &installation; ^ index.docbook:414: parser error : Entity 'installation' not defined &installation; ^ No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". Error: `xmllint --noout` outputted text CMakeFiles/l10n-docs-pt-docs-krusader-index-cache-bz2.dir/build.make:100: recipe for target 'l10n-docs/pt/docs/krusader/index.cache.bz2' failed make[2]: *** [l10n-docs/pt/docs/krusader/index.cache.bz2] Error 1 make[2]: Leaving directory '/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu' CMakeFiles/Makefile2:366: recipe for target 'CMakeFiles/l10n-docs-pt-docs-krusader-index-cache-bz2.dir/all' failed make[1]: *** [CMakeFiles/l10n-docs-pt-docs-krusader-index-cache-bz2.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". Note: Writing krusader.1 make[2]: Leaving directory '/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu' [ 3%] Built target l10n-docs-nl-docs-krusader-index-cache-bz2 make[2]: Leaving directory '/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu' [ 3%] Built target l10n-docs-pt-BR-docs-krusader-krusader-1 No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". No "pt_br" localization of "footer-doc-comment" exists; using "en". No "pt_br" localization of "footer-doc-feedback" exists; using "en". No "pt_br" localization of "footer-doc-teamname" exists; using "en". make[2]: Leaving directory '/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu' [ 3%] Built target l10n-docs-pt-BR-docs-krusader-index-cache-bz2 make[1]: Leaving directory '/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu' Makefile:130: recipe for target 'all' failed make: *** [all] Error 2 make: Leaving directory '/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu' Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.ZxLV96 (%build) Fehler beim Bauen des RPM: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.ZxLV96 (%build)
Got it, before compiling I did the following: $ rm -rf ./l10n-docs/pt_BR/ $ rm -rf ./l10n-docs/pt/ The code compiles fine then - with the help of your patch of kdoctools (comment #8). So in addition to the (fixed) problem in kdoctools some of krusader-DOC's seem to be bogus. Didn't test if installed DOC's are usable yet, as I still have to do finish my RPM-SPEC to be able to install this software. Anyhow - thanks for your help!
(In reply to MaxiPunkt from comment #11) > So in addition to the (fixed) problem in kdoctools some of krusader-DOC's > seem to be bogus. > No, the krusader docbooks are ok. These are just warnings and you can savely ignore them: [quote] No "pt_br" localization of "footer-doc-comment" exists; using "en". [/quote] Maybe https://bugs.kde.org/show_bug.cgi?id=290836 is related ?
(In reply to Burkhard Lueck from comment #12) > Maybe https://bugs.kde.org/show_bug.cgi?id=290836 is related ? It's that bug, sorry; I will put it higher in my queue. Regarding the present problem, let's discuss on the review.
Git commit 0a90d5fc7d367d5937f3cb171f56f948f93f36ef by Luigi Toscano. Committed on 16/05/2016 at 17:59. Pushed by ltoscano into branch 'master'. Call kdoctools_create_handbook only for index.docbook When more documentation files are available in a certain directory, the assumption is that there should always be an index.docbook which imports all the other docbook files in the same directory. The call to kdoctools_create_handbook must be created only for index.docbook; the macro takes care of the installation of the others docbooks. This should make kdoctools_install work when there are multiple docbooks in the same directory. REVIEW: 127935 M +6 -7 KF5DocToolsMacros.cmake http://commits.kde.org/kdoctools/0a90d5fc7d367d5937f3cb171f56f948f93f36ef
Recently I've checked this issue again - unfortunately installing translated DOC's via "kdoctools_install()" still doesn't work as expected, yet: The directory-structure for translated DOC's was done following comment#3, which is: ./10n-docs/<LANG>/docs/<APPNAME>/*.docbook The "CMakeLists.txt" contains the following lines: find_package(KF5DocTools REQUIRED) kdoctools_install(l10n-docs) On my system the DOC's currently get installed into: /usr/share/doc/HTML/<LANG>/<LANG>/docs/<APPNAME>/*.docbook So for some reason <LANG> is used _twice_ in the installation-path by accident. Like this the translated DOC's are not usable. Could you please fix?
As the issue was solved, please file a new bug. The macro is used in many tarballs successfully, for example: http://download.kde.org/stable/kronometer/2.1.2/src/kronometer-2.1.2.tar.xz Do they work for you? What version of KDocTools are you using?
Now tested again: translation DIR-structure N°1: ------------------------------ l10n-messages_docs/<LANG>/*.po l10n-messages_docs/<LANG>/docs/<APPNAME>/*.docbook => DOC's & translations are "mixed" in a single directory "CMakeLists.txt" N°1: --------------------- find_package(KF5I18n CONFIG REQUIRED) ki18n_install(l10n-messages_docs) find_package(KF5DocTools REQUIRED) kdoctools_install(l10n-messages_docs) => Results in OK-installation (btw. this DIR-strukture is currently used in kronometer tarball) translation DIR-structure N°2: ------------------------------ l10n-messages/<LANG>/*.po 10n-docs/<LANG>/docs/<APPNAME>/*.docbook => DOC's & translations are in separate directories "CMakeLists.txt" N°2: --------------------- find_package(KF5I18n CONFIG REQUIRED) ki18n_install(l10n-messages) find_package(KF5DocTools REQUIRED) kdoctools_install(l10n-docs) => Results in bogus installation-path of DOC's, as <LANG> is used _twice_ in the installation-path. On my system: /usr/share/doc/HTML/<LANG>/<LANG>/docs/<APPNAME>/*.docbook Acc.to what you've written in comment#3 KDocTools should be able to handle both DIR-structure scenarios correctly: > it works both when doc translations are "mixed" with interface translations > and when they are in separate directories (tested back to 5.16). > What version of KDocTools are you using? My distro currently provides version 5.27.0
(In reply to MaxiPunkt from comment #17) > translation DIR-structure N°2: > ------------------------------ > l10n-messages/<LANG>/*.po > 10n-docs/<LANG>/docs/<APPNAME>/*.docbook > > => DOC's & translations are in separate directories > > "CMakeLists.txt" N°2: > --------------------- > find_package(KF5I18n CONFIG REQUIRED) > ki18n_install(l10n-messages) > find_package(KF5DocTools REQUIRED) > kdoctools_install(l10n-docs) > > => Results in bogus installation-path of DOC's, > as <LANG> is used _twice_ in the installation-path. > On my system: /usr/share/doc/HTML/<LANG>/<LANG>/docs/<APPNAME>/*.docbook I tried to simulate this scenario by adapting the structure of the exploded tarball of kronometer 2.1.2, and I can't reproduce the issue. Can you please share an example tarball, or at least the output of the tree command on your sources?
Created attachment 103043 [details] kronometer DOC's & translations in separated DIRs (SVN) As requested. Please note that this tarball includes translations, only. It can be combined with kronometer's GIT-source (c097a179). I do this by extracting tarball into GIT-source & appending content of included "CMakeLists.txt.l10n" to original CMakeLists.txt.
You hit the bug because the folder ends in "docs" and the way this match line is built: string(REGEX MATCH "docs/(.*)/index.docbook" match ${docbook}) If you have .../foodocs/<lang>/docs/<program>/index.docbook the content of cmake_match_1 will be <lang>/docs/<program> instead of the expected <program> In fact man pages are not affected (the previous match works). If you use any name for the directory which does not end in docs, the macro works. Please file a new bug (as it is a corner case), or I can do it, I will prepare a patch.