D15795: Fix warnings about deprecated install dirs

ltoscano added inline comments. INLINE COMMENTS > KDEInstallDirs.cmake:564 > "documentation bundles generated using kdoctools" > -HTML_INSTALL_DIR) > +KDE_INSTALL_DOCBUNDLEDIR) > _define_relative(KCFGDIR DATAROOTDIR "config.kcfg" I'm going to comment only on this, but the others (m

D9446: WIP: Allow to autogenerate and install categories file

ltoscano added a comment. In D9446#284288 , @cgiboudeaux wrote: > > There are several issues that need fixes: > > - Installation dir for categories, /etc/xdg on linux has always been wrong. categories are not config files

D9446: WIP: Allow to autogenerate and install categories file

ltoscano added a comment. There can be more headers file for the same repository, and it has not been a problem in practice because the categories usually maps to different groups of files in different directories. See for example kopete, wacomtablet o kgraphviewer. REPOSITORY R240 Extra

Re: build errors in kdelibs4support: openssl 1.0 vs. 1.1

Milian Wolff ha scritto: > Hey all, > > ArchLinux recently updated openssl to 1.1, I now have: > > /usr/include/openssl <- 1.1 > /usr/include/openssl-1.0/openssl <- 1.0 > > kdelibs4support finds the former and then fails to compile with e.g.: > > [...] > > Just adding a 1.0 version to the find

Re: FindDocbookXML4.cmake

Allen Winter ha scritto: > On Monday, April 17, 2017 1:14:01 PM EDT Luigi Toscano wrote: >> Allen Winter ha scritto: >>> I guess the only real question is which minimum version is required to make >>> both happy? >>> >>> < set(DocB

Re: FindDocbookXML4.cmake

Allen Winter ha scritto: > Howdy, > > I discovered that kdelibs4support and kdoctools have a FindDocBookXML4.cmake. > The diff looks like the following. Can we unify and move into ECM? I think I asked the question long time ago and the answer was that the use was not so general to justify a move

D5143: Introduce fetch-translations build command

ltoscano added inline comments. INLINE COMMENTS > KDECMakeSettings.cmake:289 > +option(KDE_L10N_AUTO_TRANSLATIONS "Automatically 'make > fetch-translations`" OFF) > +set(KDE_L10N_BRANCH "trunk" CACHE STRING "Branch from l10n.kde.org to > fetch from: trunk | stable | lts | trunk_kde4 | s

D5136: Introduce fetch-translations build command

ltoscano added a comment. I agree that it should go to ECM, and there are modules (for various reasons) with translations not handled by KI18n. REPOSITORY R249 KI18n REVISION DETAIL https://phabricator.kde.org/D5136 To: apol, #frameworks, #build_system, sitter, kfunk, aacid Cc: ltoscano

[Differential] [Commented On] D4810: ecm_install_po_files_as_qm: filter the .po files

ltoscano added a comment. In https://phabricator.kde.org/D4810#90158, @aacid wrote: > What's the use case? Point this macro and ki18n_install() (which may require a similar change) in the same directory. I understand that it's not stricly needed (they can be two separate director

[Differential] [Request, 148 lines] D4810: ecm_install_po_files_as_qm: filter the .po files

ltoscano created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. REVISION SUMMARY Add a new parameter to ecm_install_po_files_as_qm which allows users to filter the .po files handled by the func

[Differential] [Updated] D3830: Add a new FindGperf module

ltoscano added a dependent revision: D3883: Generate gperf output at build time. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3830 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pino, #frameworks, #buildsystem, #windo

[Differential] [Updated] D3850: Pass -fno-operator-names when supported

ltoscano added a reviewer: Buildsystem. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3850 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kfunk, #frameworks, ivan, #buildsystem Cc: elvisangelaccio

[Differential] [Updated] D2854: New: ECMAddQch, for generating qch & doxygen tag files

ltoscano added a reviewer: KDE Buildsystem. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D2854 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kossebau, staniek, #frameworks, #kde_buildsystem Cc: shumski, kfunk, staniek

[Differential] [Updated] D3826: Detect inotify.

ltoscano added a reviewer: KDE Buildsystem. ltoscano removed a subscriber: KDE Buildsystem. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3826 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: adridg, apol, tcberner, arro

[Differential] [Updated] D3830: Add a new FindGperf module

ltoscano added a reviewer: KDE Buildsystem. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3830 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pino, #frameworks, #kde_buildsystem

[Differential] [Changed Subscribers] D3826: Detect inotify.

ltoscano added a subscriber: KDE Buildsystem. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3826 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: adridg, apol, tcberner, arrowdodger Cc: #kde_buildsystem

[Differential] [Updated] D3733: Force colored warnings in ninja's output

ltoscano added a reviewer: KDE Buildsystem. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3733 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: elvisangelaccio, #frameworks, #kde_buildsystem

Re: Review Request 129367: Use the generic redirect and add the doc link

marked as submitted. Review request for Build System and Extra Cmake Modules. Changes --- Submitted with commit 25241dece1cd717f24544ecc5c98213d1f263fd9 by Luigi Toscano to branch master. Repository: extra-cmake-modules Description --- https://commits.kde.org/?path=...&br

Re: Review Request 129367: Use the generic redirect and add the doc link

oper repository browser. Add a link to the generated ECM documentation. Diffs - README.rst f3e98aa kde-modules/KDECMakeSettings.cmake 6e53cb1 Diff: https://git.reviewboard.kde.org/r/129367/diff/ Testing --- Thanks, Luigi Toscano

Review Request 129367: Use the generic redirect and add the doc link

rg/r/129367/diff/ Testing --- Thanks, Luigi Toscano

Re: Review Request 129140: Add peruse to the build list.

> On Ott. 15, 2016, 10:38 p.m., Michael Pyne wrote: > > It doesn't look like the peruse git repo is marked active anymore. Did that > > recently change? kdesrc-build will refuse to build inactive git > > repositories so that it doesn't accidentally download needless repositories > > when inclu

Re: Review Request 128531: Do not include manpages when installing docbooks

marked as submitted. Review request for Build System, Documentation and Pino Toscano. Changes --- Submitted with commit 6a175a7059ad092e33fa45c1c6d47498c53a by Luigi Toscano to branch handbook_without_manpage. Repository: kdoctools Description --- Remove man-*.docbook files

Re: Review Request 128531: Do not include manpages when installing docbooks

for manpages and regular manuals (kate, kde-baseapps/frameworks). Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128531: Do not include manpages when building docbooks

docbook files for them were useless. Diffs - KF5DocToolsMacros.cmake e0a85b3 Diff: https://git.reviewboard.kde.org/r/128531/diff/ Testing --- Tested with repositories which provides docbook for manpages and regular manuals (kate, kde-baseapps/frameworks). Thanks, Luigi Toscano

Re: Review Request 126648: Allow to disable KArchive for internal usage

marked as submitted. Review request for Build System, KDE Frameworks, Alex Merry, and David Faure. Changes --- Submitted with commit cbd56540d0fd3a9a4b46b621c10a0b619e57ed46 by Luigi Toscano to branch master. Repository: kdoctools Description --- Most of the code was already

Re: Review Request 126648: Allow to disable KArchive for internal usage

required. Diffs (updated) - CMakeLists.txt 2ec3027 src/CMakeLists.txt 136fbfb src/xslt_kde.cpp 7069a28 Diff: https://git.reviewboard.kde.org/r/126648/diff/ Testing --- Normal compilation, compilation with MEINPROC_NO_KARCHIVE=ON Thanks, Luigi Toscano

Re: Review Request 126648: Allow to disable KArchive for internal usage

it.reviewboard.kde.org/r/126648/#review90682 ------- On Gen. 6, 2016, 1:58 a.m., Luigi Toscano wrote: > > --- > This is an automatically generated e-mail. To rep

Review Request 126648: Allow to disable KArchive for internal usage

: https://git.reviewboard.kde.org/r/126648/diff/ Testing --- Normal compilation, compilation with MEINPROC_NO_KARCHIVE=ON Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde

Re: Review Request 125560: Give unique names to the targets created by KDE4Macros.cmake

KDocTools, so generating longer, unique target names. The change is basically the same and it has been throughly tested. I would wait few days and if no one else object, I would give a ship it. - Luigi Toscano On Ott. 8, 2015, 7:38 p.m., Hrvoje Senjan wrote

Re: Review Request 120648: Encode the URIs which end up in DTD files

, I'd like to understand the implication of the patch. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120648/#review78445 ---

Re: Review Request 120648: Encode the URIs which end up in DTD files

nows during the installation. Or something like that. - Oh, that's the feedback I was looking for. Can you please copy the exact content of the path to docbookx.dtd as referenced into kdedbx45.dtd? - Luigi --- This is an automatica

Re: Review Request 120649: Encode the URIs which end up in DTD files

/120648/ for the twin review on kdoctools. Diffs - cmake/uriencode.cmake PRE-CREATION src/CMakeLists.txt 4a1d80d Diff: https://git.reviewboard.kde.org/r/120649/diff/ Testing --- It compiles, but I can't properly test Mac and Windows scenarios Thanks, Luigi To

Re: Review Request 120648: Encode the URIs which end up in DTD files

--- It compiles, but I can't properly test Mac and Windows scenarios Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 120649: Encode the URIs which end up in DTD files

twin review on kdoctools. Diffs (updated) - cmake/uriencode.cmake PRE-CREATION src/CMakeLists.txt 4a1d80d Diff: https://git.reviewboard.kde.org/r/120649/diff/ Testing --- It compiles, but I can't properly test Mac and Windows scenarios Thanks, Luigi To

Re: Review Request 120648: Encode the URIs which end up in DTD files

://git.reviewboard.kde.org/r/120648/diff/ Testing --- It compiles, but I can't properly test Mac and Windows scenarios Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 120648: Encode the URIs which end up in DTD files

escaped_uri "${${_original_uri}}") > > > > and then use `${escaped_uri}` in the perl script. Added to the function, thanks. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.

Re: Review Request 120648: Encode the URIs which end up in DTD files

> On Ott. 18, 2014, 8:50 p.m., René J.V. Bertin wrote: > > These are both RRs for KF5? > > Luigi Toscano wrote: > Yes, otherwise the repository would have been kdelibs. Do you think it > would make sense to backport it? > > René J.V. Bertin wrote: > You

Re: Review Request 120648: Encode the URIs which end up in DTD files

o reply, visit: https://git.reviewboard.kde.org/r/120648/#review68674 ------- On Ott. 18, 2014, 5:50 p.m., Luigi Toscano wrote: > > --- > This is an automatically

Re: Review Request 120648: Encode the URIs which end up in DTD files

matically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120648/#review68675 --- On Ott. 18, 2014, 5:50 p.m., Luigi Toscano wrote: > > --- > This is an automat

Review Request 120649: Encode the URIs which end up in DTD files

src/CMakeLists.txt 4a1d80d Diff: https://git.reviewboard.kde.org/r/120649/diff/ Testing --- It compiles, but I can't properly test Mac and Windows scenarios Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org

Review Request 120648: Encode the URIs which end up in DTD files

://git.reviewboard.kde.org/r/120649/ for the twin review on kdelibs4support. Diffs - src/CMakeLists.txt 341ecf4 cmake/uriencode.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120648/diff/ Testing --- It compiles, but I can't properly test Mac and Windows scenarios Thanks, Luigi To

Re: Review Request 120324: Simplify CMake code for DTD generation (WIN32/non-WIN32)

developers. Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 120324: Simplify CMake code for DTD generation (WIN32/non-WIN32)

> On Set. 23, 2014, 12:53 a.m., Luigi Toscano wrote: > > Re-reading the code and the comments, the core of the problem is described > > later, in another part which should be touched by the patch. The comment > > says: > > > > # WARNING: this has severe li

Re: Review Request 120324: Simplify CMake code for DTD generation (WIN32/non-WIN32)

hese files are not installed while # building kdoctools. Instead, we will reconfigure those files at install time # with relative paths. So is the limitation due to the fact that file(RELATIVE_PATH can't compute in advance the relative path with non-existing files as argument? - Luigi Toscano O

Review Request 120324: Simplify CMake code for DTD generation (WIN32/non-WIN32)

applied to kdelibs4support. Diffs - src/CMakeLists.txt 341ecf4 Diff: https://git.reviewboard.kde.org/r/120324/diff/ Testing --- Tested on a Linux-based based system only, needs input from Windows developers. Thanks, Luigi Toscano ___ Kde

Re: Review Request 116650: Give unique names to the targets created by KDocToolsMacros.cmake

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116650/#review52690 --- Ship it! Perfect, thanks! - Luigi Toscano On March 11

Re: Review Request 116650: Give unique names to the targets created by KDocToolsMacros.cmake

g/r/116650/#comment37141> Does it work on Windows? - Luigi Toscano On March 10, 2014, 5:17 p.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboar

Re: Review Request 116650: Remove unused targets from KDocToolsMacros.cmake

oo. KF5DocToolsMacros.cmake <https://git.reviewboard.kde.org/r/116650/#comment37094> It is needed indeed... - Luigi Toscano On March 7, 2014, 3:05 p.m., Aleix Pol Gonzalez wrote: > > --- > This is an autom

Re: Review Request 115897: Remove FindDocBook*.cmake

kdoctools, it's time to remove them from ecm. - Luigi Toscano On Feb. 19, 2014, 11:45 p.m., Alex Merry wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard

Re: Review Request 115897: Remove FindDocBook*.cmake

> On Feb. 22, 2014, 6:29 p.m., Luigi Toscano wrote: > > As this was already committed, can this RR be closed? > > Alex Merry wrote: > Actually, I never committed this one, since I never got a ship it. I > added the files to kdoctools, but never removed them from e-c-m

Re: Review Request 115897: Remove FindDocBook*.cmake

? - Luigi Toscano On Feb. 19, 2014, 11:45 p.m., Alex Merry wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Re: Review Request 115876: More generic DocBookXML -> DocBookXML4

d them to another review). Thanks, Luigi Toscano ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 115876: More generic DocBookXML -> DocBookXML4

> On Feb. 21, 2014, 7:47 p.m., Luigi Toscano wrote: > > The files have been moved to kdoctools, should I open a new review against > > the kdoctools component or can I get a shipit here? :) > > Alex Merry wrote: > I thought I'd already made this reply, bu

Re: Review Request 115876: More generic DocBookXML -> DocBookXML4

> On Feb. 21, 2014, 7:47 p.m., Luigi Toscano wrote: > > The files have been moved to kdoctools, should I open a new review against > > the kdoctools component or can I get a shipit here? :) > > Alex Merry wrote: > I thought I'd already made this reply, bu

Re: Review Request 115876: More generic DocBookXML -> DocBookXML4

review against the kdoctools component or can I get a shipit here? :) - Luigi Toscano On Feb. 18, 2014, 10:52 p.m., Luigi Toscano wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewb

Re: Review Request 115897: Remove FindDocBook*.cmake

> On Feb. 19, 2014, 12:52 p.m., Luigi Toscano wrote: > > Uhm, well, not sure about the non-usage in kde4support: I would like to > > make sure that the needed files (4.2) are really there, so I would like to > > call FindDocBookXML4 for that. > > Alex Merry wrote:

Re: Review Request 115897: Remove FindDocBook*.cmake

> On Feb. 19, 2014, 12:52 p.m., Luigi Toscano wrote: > > Uhm, well, not sure about the non-usage in kde4support: I would like to > > make sure that the needed files (4.2) are really there, so I would like to > > call FindDocBookXML4 for that. > > Alex Merry wrote:

Re: Review Request 115897: Remove FindDocBook*.cmake

> On Feb. 19, 2014, 12:52 p.m., Luigi Toscano wrote: > > Uhm, well, not sure about the non-usage in kde4support: I would like to > > make sure that the needed files (4.2) are really there, so I would like to > > call FindDocBookXML4 for that. > > Alex Merry wrote:

Re: Review Request 115897: Remove FindDocBook*.cmake

would like to make sure that the needed files (4.2) are really there, so I would like to call FindDocBookXML4 for that. - Luigi Toscano On Feb. 19, 2014, 12:47 p.m., Alex Merry wrote: > > --- > This is an automatically generated e

Re: Review Request 115876: More generic DocBookXML -> DocBookXML4

pplications/libraries using it. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115876/#review50181 ------- On Feb.

Review Request 115876: More generic DocBookXML -> DocBookXML4

ules/FindDocBookXML.cmake b6d623e find-modules/FindDocBookXML4.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115876/diff/ Testing --- Compiles (some changes are needed in KDocTools, I will add them to another review). Thanks, Luigi Toscano __

Re: Review Request 115234: Only set QT_STRICT_ITERATORS when not compiling with MSVC

> On Jan. 23, 2014, 9:28 a.m., David Faure wrote: > > Oh, OK, didn't know this was broken on MSVC. Worth a Qt fix or at least > > bugreport? Thiago reported it: see http://lists.kde.org/?l=kde-buildsystem&m=139042097719628&w=2 and https://codereview.qt-project.org/#change,76311 - Luigi --

Re: Review Request 112451: Adapt the DocBook finders to newer naming conventions

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112451/#review39357 --- Ship it! Ship It! - Luigi Toscano On Sept. 4, 2013, 1:55

Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master

Albert Astals Cid wrote: > El Diumenge, 16 de desembre de 2012, a les 23:53:23, Antonis Tsiapaliokas va > escriure: >> Hello, >> >>> Attached, can somebody give it a try ? >>> >>> Alex >> >> I have test the attached patch with 2.8.8 cmake and it doesn't work. >> With the 2.8.9 cmake, the issues is

Re: [Digikam-devel] docbook cannot be compiled because FindDocBookXML.cmake is missing

On Wed, 28 Mar 2012 11:42:02 +0100, Ananta Palani wrote: > Is there a reason that FindDocBookXML.cmake and FindDocBookXSL.cmake are > not installed by kdelibs? I am told that anything not installed is used > internally by kdelibs during build, but I am curious why these need to be > internal only.

Re: [Digikam-devel] docbook cannot be compiled because FindDocBookXML.cmake is missing

On Fri, 30 Mar 2012 09:06:45 +0200, Andreas Pakulat wrote: > On 28.03.12 11:42:02, Ananta Palani wrote: >> Is there a reason that FindDocBookXML.cmake and FindDocBookXSL.cmake >> are not installed by kdelibs? I am told that anything not installed is >> used internally by kdelibs during build, but

Re: Review Request: Add missing dependency to xmllint

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101707/ --- (Updated June 21, 2011, 7:21 p.m.) Review request for Build System, kdelib

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: > On Wednesday 26 May 2010, Luigi Toscano wrote: >> Alexander Neundorf wrote: >>> On Wednesday 26 May 2010, Luigi Toscano wrote: >>>> Alexander Neundorf wrote: >>>>> Ok, stupid question. >>>>> Now I actu

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: > On Wednesday 26 May 2010, Luigi Toscano wrote: >> Alexander Neundorf wrote: >>> Ok, stupid question. >>> Now I actually tried to build kdelibs again, and it failed because the >>> docbook stuff wasn't found. >>> The giv

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: > > Ok, stupid question. > Now I actually tried to build kdelibs again, and it failed because the docbook > stuff wasn't found. > The given link in the error message is http://docbook.org/schemas/4x.html > So, what should I download from there ? It's not so easy from that

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: > > I had a quick look at both files (XML and XSLT). > Only a few comments: > you should add > include(FindPackageHandleStandardArgs) > , otherwise, as it is now, both files rely on that some other file which has > been processed before has already done that. Done. > > I

Re: DocBook XML & XSL: new dependencies

Maciej Mrozowski wrote: > Hi > > Gentoo needs something like below as we do not provide catalog.xml (I think > it's regenerated elsewhere under different name) : > > -find_path (DOCBOOKXML_CURRENTDTD_DIR catalog.xml > +find_path (DOCBOOKXML_CURRENTDTD_DIR catalog.xml docbook.cat > docbook.cat shoul

Re: KDE/kdelibs/cmake/modules

Matthew Woehlke wrote: > Thanks. I guess I don't need to tell you it's ugly (thanks Fedora :P ). > I had my own idea, here: http://reviewboard.kde.org/r/3954/ > > It's also ugly, but at least doesn't hard-code the rpm version. Does it > look okay? From my point of view, it looks good. I was thinki

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: On Friday 07 May 2010, Luigi Toscano wrote: Alexander Neundorf wrote: On Thursday 06 May 2010, Luigi Toscano wrote: Alexander Neundorf wrote: > > Are the two find-modules supposed to be installed ? > IOW, are docbookxml and docbook xsl only requ

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: On Thursday 06 May 2010, Luigi Toscano wrote: Alexander Neundorf wrote: > On Tuesday 04 May 2010, Luigi Toscano wrote: >> as I announced on kde-core-devel[1], I'm working to remove the embedded >> copies of XML and XSLT files from kde

Re: DocBook XML & XSL: new dependencies

Alexander Neundorf wrote: > On Tuesday 04 May 2010, Luigi Toscano wrote: >> as I announced on kde-core-devel[1], I'm working to remove the embedded >> copies of XML and XSLT files from kdelibs/kdoctools. This process will >> introduce two external dependencies

DocBook XML & XSL: new dependencies

ML version # # Copyright (c) 2010, Luigi Toscano, # # Redistribution and use is allowed according to the terms of the BSD license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. if (DOCBOOKXML_CURRENTDTD_DIR AND DOCBOOK_XML_CURRENTDTD_VERSION) set (DOCBOOKXML_FOUND TR