Re: Syncing ECM release number with KF5

2015-04-04 Thread David Faure 
On Saturday 28 March 2015 05:49:01 Michael Palimaka wrote:
> On 28/03/15 03:48, Alex Merry wrote:
> > On Wednesday 25 March 2015 22:35:24 Stephen Kelly wrote:
> >> Hello,
> >> 
> >> ECM release numbers are in sync with KF5 release numbers, except for the
> >> major component.
> >> 
> >> This means that if you want to build the 5.x.y release you have to
> >> download
> >> the 1.x.y release of ECM. That doubles the complexity of your script
> >> which
> >> downloads the tarball to build it.
> >> 
> >> That is bad and it is not necessary.
> >> 
> >> Let's sync the major number for the next release.
> >> 
> >> At some point the reason to make them out of sync was to be able to make
> >> ECM releases more frequently. That is very rare because KF5 releases are
> >> happening every month. If ECM needs to make an out of band release, it
> >> can use the 4th version number component.
> > 
> > I have no particular objection, although I think "doubling the complexity"
> > of scripts is overstating things a little.
> > 
> > Alex
> 
> Is ECM actually part of KF5, or just happens to be released alongside
> it? (I thought the latter, hence the different version).

The initial idea was "it' happens to be released alongside, when necessary".

I.e. as a "marketing" message: you can use ECM without using KF5.
But, well, this modularity exists for the rest of KF5 too (you can use 
KArchive without using KIO), so this would still be clear if the version 
number was aligned.

I also saw it as a way to not include it if it didn't change, but in practice 
there's always at least one change every month, usually more ;)

> FWIW the different version doesn't bother me at all as a downstream.

And it doesn't bother me as the release dude - I have one if() in the version 
file ;)   (so, I also disagree with "doubles the complexity").

But since both Stephen Kelly and Alex Merry (maintainers of ECM) are in favour 
of switching, I'll make the switch.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 123969: Fix test on OSX, no bundle expected here.

2015-05-31 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123969/
---

Review request for Extra Cmake Modules and Marko Käning.


Repository: extra-cmake-modules


Description
---

CI said:
 Linking C executable dummy.app/Contents/MacOS/dummy
 Built target dummy
 Could not find path to executable, perhaps it was not built: dummy


Diffs
-

  tests/ExecuteKDEModules/CMakeLists.txt 
d70ea90882781b1dfc77e16e733d3fa84f847cf2 

Diff: https://git.reviewboard.kde.org/r/123969/diff/


Testing
---

still passes on linux, to be tested on OSX


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123969: Fix test on OSX, no bundle expected here.

2015-06-06 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123969/
---

(Updated June 6, 2015, 8:11 a.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules and Marko Käning.


Changes
---

Submitted with commit ef88a6683a2578679b3c98396a9ee3001db69541 by David Faure 
to branch master.


Repository: extra-cmake-modules


Description
---

CI said:
 Linking C executable dummy.app/Contents/MacOS/dummy
 Built target dummy
 Could not find path to executable, perhaps it was not built: dummy


Diffs
-

  tests/ExecuteKDEModules/CMakeLists.txt 
d70ea90882781b1dfc77e16e733d3fa84f847cf2 

Diff: https://git.reviewboard.kde.org/r/123969/diff/


Testing
---

still passes on linux, to be tested on OSX


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

2015-06-08 Thread David Faure 
That wasn't very constructive/positive...

On Monday 08 June 2015 15:22:20 Ben Cooksley wrote:
> The Qt developers
> didn't want to provide any infrastructure at all to make developer
> environments (including our CI system) easier. 

The *any* here is too broad. One approach was rejected, there are tons of 
others. E.g. just naming the variables QT_ instead of XDG_ might have been 
less controversial.
But since everyone was saying, at the same time, that end users don't want env 
vars, I can understand that the Qt developers thought this issue needs more 
thinking, to solve all uses cases, not just "KDE CI" (which was a too 
restrictive line of argumentation compared to what it really was, "developer 
setup", as you say).

> The maintainer(s) of
> the QStandardPaths class never reviewed our patch

That would be me, and since I don't know how things should work on OSX, I am 
not in a good position to decide. On top of that I come from the KDE world, so 
I can't really force a KDE patch into Qt if it's a bit controversial.

> , and the module
> maintainer for QtCore wanted the opinion of a Digia employee who was
> extremely unresponsive.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Updating CMakeLists in KDE4 repos

2015-07-25 Thread David Faure 
[moving this discussion to the mailing-list]

On Saturday 25 July 2015 17:45:53 Stephen Kelly wrote:
> On 07/25/2015 04:06 PM, David Faure wrote:
> > On Tuesday 21 July 2015 09:03:18 Stephen Kelly wrote:
> >> All KDE4 code needs to use the 'cmake_minimum_required(VERSION 2.8.9)'
> >> command before the project command in the CMakeLists at the top of each
> >> repo.
> > OK I'm looking at this.
> 
> Cool, thanks!
> 
> > What should I do in case there is a cmake_minimum_required(VERSION 2.6) 
> > already? I upgrade it to 2.8.9, right?
> 
> Yes. The content in FindKDE4Internal until recently should override that
> in older KDE4 versions, so changing it to 2.8.9 is desired.

OK.

> > What should I do if it says cmake_minimum_required(VERSION 2.8.12)? Leave 
> > it untouched?
> 
> Perhaps someone specified that version because they used a command
> introduced in that version, though that's not the correct thing to do.

Well, I would have done the same mistake :)
It's quite complex that an app using a 2.8.12 cmake feature is not supposed
to set the cmake min version to 2.8.12 but to set it to 2.8.9 due to kdelibs4
and abort if it's 2.8.12 (as you explain further below).
Nobody would ever guess that in a million years.

Is this solved by ECM, or does it have the same issue?
 
> That 2.8.12 would have been overridden by the FindKDE4Internal content
> though, in terms of policies. If CMake 2.8.12 issued policy warnings
> which were ignored and you leave that line untouched, those policy
> warnings will not be issued anymore and NEW behavior will be used
> instead. That may or may not result in an error.
> 
> If you intend to build these projects, you could change it to 2.8.9 and
> run cmake on projects like that, and they don't issue warnings, then
> they can be left with the 2.8.12.

Well I do intend to build them, but I was hoping that just checking that it 
builds
would be enough. If I need to watch out for cmake warnings, how will I know
whether my version change introduced them, or if they were there before?
Doing a diff of the cmake warnings after/before sounds like a lot of work
for 462 modules...

> If you don't build those projects, and you think people were ignoring
> the policy warnings, then the safe thing to do is to change it to 2.8.9.
> You could also add:
> 
>  if (CMAKE_VERSION VERSION_LESS 2.8.12)
>message(FATAL_ERROR "This project requires CMake 2.8.12 functionality")
>  endif()
> 
> That way, there is an early diagnosis if an older CMake version is used,
> but no matter which CMake version is used it will use 2.8.9 behavior.
> 
> Of course, any ignored policies are future problems. Policy warnings are
> saying 'a future version of CMake will behave differently and may or may
> not build this code in the future'. Both new and old versions of CMake
> can still be used if if() conditions are added as I did here:
> 
>  http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=3fd71668
> 
> But maybe by the time a new CMake version adopts the new behavior KDE4
> will no longer be distributed by anyone together with that new CMake
> version.
> 
> Sorry that's not an easier answer!

Me too!
But ... the good news is that I looked again, and only gcompris requires 2.8.12.
Everything else which doesn't already say 2.8.9, points to older versions:

/d/kde/src/t/extragear/office/kile/CMakeLists.txt requires 2.6.2
/d/kde/src/t/extragear/office/tellico/CMakeLists.txt requires 2.6.2
/d/kde/src/t/extragear/office/skrooge/CMakeLists.txt requires 2.8
/d/kde/src/t/extragear/pim/trojita/CMakeLists.txt requires 2.8.7
/d/kde/src/t/extragear/accessibility/simon/CMakeLists.txt requires 2.8.0
/d/kde/src/t/extragear/edu/gcompris/CMakeLists.txt requires 2.8.12
/d/kde/src/t/extragear/utils/kdesrc-build/CMakeLists.txt requires 2.6
/d/kde/src/t/extragear/graphics/kolor-manager/CMakeLists.txt requires 2.4
/d/kde/src/t/extragear/graphics/kxstitch/CMakeLists.txt requires 2.6
/d/kde/src/t/extragear/graphics/kphotoalbum/CMakeLists.txt requires 2.8.3
/d/kde/src/t/extragear/graphics/symboleditor/CMakeLists.txt requires 2.6
/d/kde/src/t/extragear/graphics/skanlite/CMakeLists.txt requires 2.6
/d/kde/src/t/extragear/graphics/kst-plot/CMakeLists.txt requires 2.8


> > What if the existing line isn't at the top of the file?
> You mean a cmake_minimum_required() which is below other commands like
> project() etc? That would be a bug, but a separate one which is not yet
> diagnosed by a policy. The cmake_minimum_required() should be before the
> project().

OK, thanks for the confirmation. My script now takes care of this and moves 
things
around if necessary.
 
> > I can omit FATAL_ERROR, i.e. ignore cmake 2.4 completely, right?
> 
> Yep, I

[cantor/Applications/14.12] /: Add cmake_minimum_required(VERSION 2.8.9) at the top and fix build.

2015-07-25 Thread David Faure 
Git commit 19252f57cb5576a39e1a43cd19670d97e0cd9a8d by David Faure.
Committed on 25/07/2015 at 22:12.
Pushed by dfaure into branch 'Applications/14.12'.

Add cmake_minimum_required(VERSION 2.8.9) at the top and fix build.

Somehow "kpty" doesn't work anymore, ${KDE4_KPTY_LIBS} must be used instead.

CCMAIL: kde-buildsystem@kde.org

M  +1-0CMakeLists.txt
M  +1-1src/CMakeLists.txt
M  +1-1src/backends/maxima/CMakeLists.txt
M  +1-1src/backends/sage/CMakeLists.txt
M  +1-0src/lib/CMakeLists.txt
M  +1-1src/lib/test/CMakeLists.txt

http://commits.kde.org/cantor/19252f57cb5576a39e1a43cd19670d97e0cd9a8d

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f712483..8fc49d3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 project(cantor)
 
 find_package(KDE4 REQUIRED)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index c41bd26..a415713 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -20,7 +20,7 @@ add_subdirectory(panelplugins)
 #build the config object in a separate library, shared between shell and part
 kde4_add_kcfg_files(config_SRCS settings.kcfgc)
 kde4_add_library( cantor_config  SHARED ${config_SRCS} )
-target_link_libraries( cantor_config ${KDE4_KDEUI_LIBS} ${KDE4_KPARTS_LIBS} 
${KDE4_KNEWSTUFF3_LIBS} )
+target_link_libraries( cantor_config PUBLIC ${KDE4_KDEUI_LIBS} 
${KDE4_KPARTS_LIBS} ${KDE4_KNEWSTUFF3_LIBS} )
 install( TARGETS cantor_config  ${INSTALL_TARGETS_DEFAULT_ARGS} )
 
 set(cantor_SRCS
diff --git a/src/backends/maxima/CMakeLists.txt 
b/src/backends/maxima/CMakeLists.txt
index 1868beb..d5452e6 100644
--- a/src/backends/maxima/CMakeLists.txt
+++ b/src/backends/maxima/CMakeLists.txt
@@ -20,7 +20,7 @@ kde4_add_ui_files(MaximaBackend_SRCS settings.ui)
 kde4_add_plugin( cantor_maximabackend ${MaximaBackend_SRCS} )
 target_link_libraries( cantor_maximabackend ${KDE4_KDEUI_LIBS} cantorlibs 
${KDE4_KIO_LIBS})
 if(NOT WIN32)
-  target_link_libraries(cantor_maximabackend kpty)
+   target_link_libraries(cantor_maximabackend ${KDE4_KPTY_LIBS})
 endif(NOT WIN32)
 
 kde4_add_unit_test( testmaxima testmaxima.cpp)
diff --git a/src/backends/sage/CMakeLists.txt b/src/backends/sage/CMakeLists.txt
index c1492d9..f96c564 100644
--- a/src/backends/sage/CMakeLists.txt
+++ b/src/backends/sage/CMakeLists.txt
@@ -16,7 +16,7 @@ install(FILES sagebackend.kcfg DESTINATION 
${KCFG_INSTALL_DIR})
 kde4_add_ui_files(SageBackend_SRCS settings.ui)
 
 kde4_add_plugin( cantor_sagebackend ${SageBackend_SRCS} )
-target_link_libraries( cantor_sagebackend ${KDE4_KDEUI_LIBS} cantorlibs kpty 
${KDE4_KIO_LIBS})
+target_link_libraries( cantor_sagebackend ${KDE4_KDEUI_LIBS} cantorlibs 
${KDE4_KPTY_LIBS} ${KDE4_KIO_LIBS})
 
 kde4_add_unit_test( testsage testsage.cpp)
 target_link_libraries( testsage
diff --git a/src/lib/CMakeLists.txt b/src/lib/CMakeLists.txt
index 3c6b84e..b13d8b8 100644
--- a/src/lib/CMakeLists.txt
+++ b/src/lib/CMakeLists.txt
@@ -58,6 +58,7 @@ configure_file (config-cantorlib.h.cmake 
${CMAKE_CURRENT_BINARY_DIR}/config-cant
 kde4_add_library( cantorlibs  SHARED ${cantor_LIB_SRCS} )
 
 target_link_libraries( cantorlibs
+ PUBLIC
   ${KDE4_KDECORE_LIBS}
   ${KDE4_KIO_LIBS}
   ${QT_LIBRARIES}
diff --git a/src/lib/test/CMakeLists.txt b/src/lib/test/CMakeLists.txt
index 4bf1742..af56f18 100644
--- a/src/lib/test/CMakeLists.txt
+++ b/src/lib/test/CMakeLists.txt
@@ -5,7 +5,7 @@ set(cantortest_SRCS
 )
 
 kde4_add_library( cantortest SHARED ${cantortest_SRCS} )
-target_link_libraries( cantortest
+target_link_libraries( cantortest PUBLIC
   cantorlibs
   ${KDE4_KDECORE_LIBS}
   ${QT_QTTEST_LIBRARY}
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [cantor/Applications/14.12] /: Add cmake_minimum_required(VERSION 2.8.9) at the top and fix build.

2015-07-26 Thread David Faure 
On Sunday 26 July 2015 09:57:23 Stephen Kelly wrote:
> David Faure wrote:
> 
> > Git commit 19252f57cb5576a39e1a43cd19670d97e0cd9a8d by David Faure.
> > Committed on 25/07/2015 at 22:12.
> > Pushed by dfaure into branch 'Applications/14.12'.
> > 
> > Add cmake_minimum_required(VERSION 2.8.9) at the top and fix build.
> > 
> 
> >  target_link_libraries( cantorlibs
> > + PUBLIC
> >${KDE4_KDECORE_LIBS}
> >${KDE4_KIO_LIBS}
> >${QT_LIBRARIES}
> 
> 
> I guess you encountered some CMP0022 warnings and added PUBLIC. 

Yup.

> You probably want LINK_PRIVATE instead, as you want the link implementation 
> to not be propagated to callers (which was the case before you added 
> PUBLIC), and because PRIVATE/PUBLIC were added with 2.8.12, but 
> LINK_PRIVATE/LINK_PUBLIC are available with 2.8.9. 
> 
>  http://quickgit.kde.org/?p=kdepimlibs.git&a=commitdiff&h=501d6986

I see. Thanks for the explanation. See why I shouldn't be the one fixing this 
:-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kdepimlibs/KDE/4.14] /: Add min required cmake version; fix clashes on target names

2015-07-26 Thread David Faure 
Git commit c31af9a2c15fa28df017c050373f3dd747999521 by David Faure.
Committed on 26/07/2015 at 09:08.
Pushed by dfaure into branch 'KDE/4.14'.

Add min required cmake version; fix clashes on target names

CCMAIL: kde-buildsystem@kde.org

M  +1-0CMakeLists.txt
M  +6-6includes/tests/CMakeLists.txt
M  +3-3kimap/tests/CMakeLists.txt

http://commits.kde.org/kdepimlibs/c31af9a2c15fa28df017c050373f3dd747999521

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 46f1434..0840dfd 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 project(kdepimlibs)
 
 # where to look first for cmake modules. This line must be the first one or 
cmake will use the system's FindFoo.cmake
diff --git a/includes/tests/CMakeLists.txt b/includes/tests/CMakeLists.txt
index e4ee625..f314c61 100644
--- a/includes/tests/CMakeLists.txt
+++ b/includes/tests/CMakeLists.txt
@@ -86,12 +86,12 @@ add_includes( Mailtransport )
 add_includes( Syndication )
 
 add_definitions( -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII 
-DQT_NO_KEYWORDS -DQT_NO_CAST_FROM_BYTEARRAY -DQT_STRICT_ITERATORS )
-kde4_add_executable( headertest header_compile.cpp )
-target_link_libraries( headertest ${QT_QTCORE_LIBRARY} )
-add_dependencies( headertest akonadi-calendar ) # ensure calendarsettings.h is 
generated in parallel builds
-add_dependencies( headertest kabc ) # ensure addressee.h is generated in 
parallel builds
-add_dependencies( headertest kcal )
-add_dependencies( headertest mailtransport ) # ensure transportbase.h is 
generated in parallel builds
+kde4_add_executable( headercompiletest header_compile.cpp )
+target_link_libraries( headercompiletest ${QT_QTCORE_LIBRARY} )
+add_dependencies( headercompiletest akonadi-calendar ) # ensure 
calendarsettings.h is generated in parallel builds
+add_dependencies( headercompiletest kabc ) # ensure addressee.h is generated 
in parallel builds
+add_dependencies( headercompiletest kcal )
+add_dependencies( headercompiletest mailtransport ) # ensure transportbase.h 
is generated in parallel builds
 
 endif()
 
diff --git a/kimap/tests/CMakeLists.txt b/kimap/tests/CMakeLists.txt
index 9d2e7c1..91f7339 100644
--- a/kimap/tests/CMakeLists.txt
+++ b/kimap/tests/CMakeLists.txt
@@ -11,11 +11,11 @@ set( EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR} )
 remove_definitions(-DQT_USE_QSTRINGBUILDER)
 MACRO(KIMAP_UNIT_TESTS)
   FOREACH(_testname ${ARGN})
-kde4_add_unit_test(${_testname} TESTNAME kimap-${_testname} NOGUI 
${_testname}.cpp)
+kde4_add_unit_test(kimap-${_testname} TESTNAME kimap-${_testname} NOGUI 
${_testname}.cpp)
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
-target_link_libraries(${_testname} ${KDE4_KDECORE_LIBS} 
${QT_QTTEST_LIBRARY}
+target_link_libraries(kimap-${_testname} ${KDE4_KDECORE_LIBS} 
${QT_QTTEST_LIBRARY}
   kimap kimaptest kmime)
-set_target_properties(${_testname} PROPERTIES COMPILE_FLAGS 
-DTEST_DATA="\\"${CMAKE_CURRENT_SOURCE_DIR}\\"")
+set_target_properties(kimap-${_testname} PROPERTIES COMPILE_FLAGS 
-DTEST_DATA="\\"${CMAKE_CURRENT_SOURCE_DIR}\\"")
   ENDFOREACH(_testname)
 ENDMACRO(KIMAP_UNIT_TESTS)
 
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Updating CMakeLists in KDE4 repos

2015-07-26 Thread David Faure 
On Saturday 25 July 2015 20:30:06 Stephen Kelly wrote:
> > There are many many (see attached), but I don't know how to fix them
> > all... You could take a look at kdepimlibs, it seems to be the worst of
> > all ;)
> 
> I'll take a look, thanks.

I pushed a fix, I needed kdepimlibs to build in order to build many other 
modules that depend on it.

There's still a CMP0033 warning in gpgme++/CMakeLists.txt though.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kate/KDE/4.14] /: Set cmake min req to 2.8.9 to match kdelibs4; fix linking to ktexteditor as a result.

2015-07-26 Thread David Faure 
Git commit f60d08e0d27db18d5868f18af894af367032f058 by David Faure.
Committed on 26/07/2015 at 10:42.
Pushed by dfaure into branch 'KDE/4.14'.

Set cmake min req to 2.8.9 to match kdelibs4; fix linking to ktexteditor as a 
result.

CCMAIL: kde-buildsystem@kde.org

M  +1-0CMakeLists.txt
M  +1-1addons/kate/project/CMakeLists.txt
M  +1-1addons/ktexteditor/hlselection/CMakeLists.txt
M  +1-1addons/ktexteditor/insertfile/CMakeLists.txt
M  +3-3kate/app/CMakeLists.txt
M  +3-3part/CMakeLists.txt
M  +1-1tests/CMakeLists.txt

http://commits.kde.org/kate/f60d08e0d27db18d5868f18af894af367032f058

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3072aee..d383b81 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 # Kate project
 project (kate)
 
diff --git a/addons/kate/project/CMakeLists.txt 
b/addons/kate/project/CMakeLists.txt
index 93c5ffa..d614683 100644
--- a/addons/kate/project/CMakeLists.txt
+++ b/addons/kate/project/CMakeLists.txt
@@ -33,7 +33,7 @@ set(kateprojectplugin_PART_SRCS
 kde4_add_plugin(kateprojectplugin ${kateprojectplugin_PART_SRCS})
 
 # Ubuntu 12.10 needs the lower-case qjson
-target_link_libraries(kateprojectplugin  ${KDE4_KDEUI_LIBS} ${QJSON_LIBRARIES} 
${qjson_LIBRARIES} kateinterfaces ktexteditor)
+target_link_libraries(kateprojectplugin  ${KDE4_KDEUI_LIBS} ${QJSON_LIBRARIES} 
${qjson_LIBRARIES} kateinterfaces ${KDE4_KTEXTEDITOR_LIBS})
 
 ### install files ###
 install(TARGETS kateprojectplugin DESTINATION ${PLUGIN_INSTALL_DIR} )
diff --git a/addons/ktexteditor/hlselection/CMakeLists.txt 
b/addons/ktexteditor/hlselection/CMakeLists.txt
index 58e85ae..b7bc4ef 100644
--- a/addons/ktexteditor/hlselection/CMakeLists.txt
+++ b/addons/ktexteditor/hlselection/CMakeLists.txt
@@ -5,7 +5,7 @@ set(ktexteditor_hlselection_PART_SRCS hlselectionplugin.cpp )
 
 kde4_add_plugin(ktexteditor_hlselection ${ktexteditor_hlselection_PART_SRCS})
 
-target_link_libraries(ktexteditor_hlselection  ${KDE4_KIO_LIBS} ktexteditor 
${KDE4_KDEUI_LIBS} ${KDE4_KFILE_LIBS})
+target_link_libraries(ktexteditor_hlselection  ${KDE4_KIO_LIBS} 
${KDE4_KTEXTEDITOR_LIBS} ${KDE4_KDEUI_LIBS} ${KDE4_KFILE_LIBS})
 
 install(TARGETS  ktexteditor_hlselection  DESTINATION ${PLUGIN_INSTALL_DIR} )
 
diff --git a/addons/ktexteditor/insertfile/CMakeLists.txt 
b/addons/ktexteditor/insertfile/CMakeLists.txt
index ca00ff0..30b4174 100644
--- a/addons/ktexteditor/insertfile/CMakeLists.txt
+++ b/addons/ktexteditor/insertfile/CMakeLists.txt
@@ -6,7 +6,7 @@ set(ktexteditor_insertfile_PART_SRCS insertfileplugin.cpp )
 
 kde4_add_plugin(ktexteditor_insertfile ${ktexteditor_insertfile_PART_SRCS})
 
-target_link_libraries(ktexteditor_insertfile  ${KDE4_KIO_LIBS} ktexteditor 
kdeui kfile)
+target_link_libraries(ktexteditor_insertfile ${KDE4_KIO_LIBS} 
${KDE4_KTEXTEDITOR_LIBS})
 
 install(TARGETS  ktexteditor_insertfile  DESTINATION ${PLUGIN_INSTALL_DIR} )
 
diff --git a/kate/app/CMakeLists.txt b/kate/app/CMakeLists.txt
index f39bf68..a908300 100644
--- a/kate/app/CMakeLists.txt
+++ b/kate/app/CMakeLists.txt
@@ -34,9 +34,9 @@ if (NOT KDE_NO_DEPRECATED)
set (KDE_4_4_LIBS_NEEDED ${KDE4_KUTILS_LIBS})
 endif()
 
-target_link_libraries(kateinterfaces  ${KDE_4_4_LIBS_NEEDED} 
${QT_QTXML_LIBRARY} ${KDE4_KTEXTEDITOR_LIBS} ${KDE4_KPARTS_LIBS} 
${KACTIVITIES_LIBRARY} )
-target_link_libraries(kateinterfaces  LINK_INTERFACE_LIBRARIES 
"${KDE4_KPARTS_LIBS}" )
-
+target_link_libraries(kateinterfaces
+   LINK_PUBLIC ${KDE4_KPARTS_LIBS}
+   LINK_PRIVATE ${KDE_4_4_LIBS_NEEDED} ${QT_QTXML_LIBRARY} 
${KDE4_KTEXTEDITOR_LIBS} ${KDE4_KPARTS_LIBS} ${KACTIVITIES_LIBRARY} )
 
 set_target_properties(kateinterfaces PROPERTIES VERSION ${GENERIC_LIB_VERSION} 
SOVERSION ${GENERIC_LIB_SOVERSION})
 
diff --git a/part/CMakeLists.txt b/part/CMakeLists.txt
index dcfcd5a..18082f5 100644
--- a/part/CMakeLists.txt
+++ b/part/CMakeLists.txt
@@ -231,10 +231,10 @@ kde4_add_ui_files(katepart_PART_SRCS ${katepart_PART_UI} )
 kde4_add_library (katepartinterfaces ${LIBRARY_TYPE} ${katepart_PART_SRCS} )
 
 target_link_libraries (
-  katepartinterfaces ${KDE4_KDECORE_LIBS} ${KDE4_KPARTS_LIBS}
-  ${KDE4_KCMUTILS_LIBS} ${KDE4_KTEXTEDITOR_LIBS} ${QT_QTSCRIPT_LIBRARY} 
${KDE_4_4_LIBS_NEEDED} ${KDE4_KNEWSTUFF3_LIBS}
+   katepartinterfaces
+   LINK_PUBLIC ${KDE4_KPARTS_LIBS}
+   LINK_PRIVATE ${KDE4_KDECORE_LIBS} ${KDE4_KPARTS_LIBS} ${KDE4_KCMUTILS_LIBS} 
${KDE4_KTEXTEDITOR_LIBS} ${QT_QTSCRIPT_LIBRARY} ${KDE_4_4_LIBS_NEEDED} 
${KDE4_KNEWSTUFF3_LIBS}
 )
-target_link_libraries(katepartinterfaces LINK_INTERFACE_LIBRARIES 
"${KDE4_KPARTS_LIBS}" )
 
 set_target_properties(
   katepartinterfaces PROPERTIES
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 43e7339..ed52fad 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -20,7 +20,7 @@ include_directories(
   ${KDE4_KIO_INCLUDES}
 )
 
-set (KATE_TEST_LINK_LIBS ${KDE4_KDECO

marble and cmake_min_req

2015-07-26 Thread David Faure 
This one is hairy...


project(marble)
option(QTONLY "Create Marble version without KDE dependencies" OFF)
[...]


# minimum required cmake version
if( QTONLY )
# all previous releases lack QT_QTSCRIPT_LIBRARY needed for panoramio
# this might be replaced by a workaround
cmake_minimum_required( VERSION 2.4.8 )

#suppress the policy warnings while keeping the same behaviour
if( COMMAND cmake_policy )
cmake_policy( SET CMP0005 OLD )
cmake_policy( SET CMP0003 OLD )
endif( COMMAND cmake_policy )

endif( QTONLY )
[...]

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[analitza/KDE/4.14] /: Add cmake_min_req matching kdelibs req & policies, fix build accordingly.

2015-07-26 Thread David Faure 
Git commit 9c677d2ce90e1c0868f889728a1b765883bbb474 by David Faure.
Committed on 26/07/2015 at 14:05.
Pushed by dfaure into branch 'KDE/4.14'.

Add cmake_min_req matching kdelibs req & policies, fix build accordingly.

CCMAIL: kde-buildsystem@kde.org

M  +1-0CMakeLists.txt
M  +1-1analitza/CMakeLists.txt
M  +1-1analitzagui/CMakeLists.txt
M  +3-1analitzaplot/CMakeLists.txt
M  +1-1analitzaplot/tests/CMakeLists.txt

http://commits.kde.org/analitza/9c677d2ce90e1c0868f889728a1b765883bbb474

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6b6296d..b7fb236 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 project(analitza)
 
 find_package(KDE4 REQUIRED)
diff --git a/analitza/CMakeLists.txt b/analitza/CMakeLists.txt
index 6315d32..b3ae939 100644
--- a/analitza/CMakeLists.txt
+++ b/analitza/CMakeLists.txt
@@ -45,7 +45,7 @@ set(analitza_SRCS
 )
 
 kde4_add_library(analitza SHARED ${analitza_SRCS})
-target_link_libraries(analitza ${QT_QTCORE_LIBRARY} ${QT_QTXML_LIBRARY} 
${KDE4_KDECORE_LIBS})
+target_link_libraries(analitza LINK_PRIVATE ${QT_QTCORE_LIBRARY} 
${QT_QTXML_LIBRARY} ${KDE4_KDECORE_LIBS})
 
 set_target_properties(analitza PROPERTIES VERSION ${ANALITZA_LIB_VERSION} 
SOVERSION ${ANALITZA_LIB_SOVERSION} )
 
diff --git a/analitzagui/CMakeLists.txt b/analitzagui/CMakeLists.txt
index 2ac4834..224fd67 100644
--- a/analitzagui/CMakeLists.txt
+++ b/analitzagui/CMakeLists.txt
@@ -22,7 +22,7 @@ if(HAVE_OPENGL)
 endif(HAVE_OPENGL)
 
 kde4_add_library(analitzagui SHARED ${analitzagui_SRCS})
-target_link_libraries(analitzagui ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} 
${KDE4_KDEUI_LIBS} ${QT_QTSVG_LIBRARY} ${QT_QTOPENGL_LIBRARY} analitza 
analitzaplot)
+target_link_libraries(analitzagui LINK_PRIVATE ${QT_QTCORE_LIBRARY} 
${QT_QTGUI_LIBRARY} ${KDE4_KDEUI_LIBS} ${QT_QTSVG_LIBRARY} 
${QT_QTOPENGL_LIBRARY} analitza analitzaplot)
 
 set_target_properties(analitzagui PROPERTIES VERSION ${ANALITZA_LIB_VERSION} 
SOVERSION ${ANALITZA_LIB_SOVERSION} )
 
diff --git a/analitzaplot/CMakeLists.txt b/analitzaplot/CMakeLists.txt
index 040ce01..692242d 100644
--- a/analitzaplot/CMakeLists.txt
+++ b/analitzaplot/CMakeLists.txt
@@ -66,6 +66,7 @@ endif(HAVE_OPENGL)
 
 kde4_add_library( analitzaplot SHARED ${analitzaplot_SRCS} )
 target_link_libraries ( analitzaplot
+   LINK_PRIVATE
   ${QT_QTCORE_LIBRARY}
   ${QT_QTGUI_LIBRARY}
   ${KDE4_KDECORE_LIBS}
@@ -75,13 +76,14 @@ target_link_libraries ( analitzaplot
 
 if(HAVE_OPENGL)
 target_link_libraries ( analitzaplot
+ LINK_PRIVATE
 ${OPENGL_gl_LIBRARY}
 ${OPENGL_glu_LIBRARY}
 )
 endif(HAVE_OPENGL)
 
 if(WIN32)
-target_link_libraries(analitzaplot ${GLEW_LIBRARIES})
+   target_link_libraries(analitzaplot LINK_PRIVATE ${GLEW_LIBRARIES})
 endif(WIN32)
 
 set_target_properties(analitzaplot PROPERTIES VERSION ${ANALITZA_LIB_VERSION} 
SOVERSION ${ANALITZA_LIB_SOVERSION} )
diff --git a/analitzaplot/tests/CMakeLists.txt 
b/analitzaplot/tests/CMakeLists.txt
index ce8e30f..fd4ab43 100644
--- a/analitzaplot/tests/CMakeLists.txt
+++ b/analitzaplot/tests/CMakeLists.txt
@@ -12,6 +12,6 @@ target_link_libraries(surfacetest ${testLibs})
 kde4_add_unit_test(plotsmodeltest plotsmodeltest.cpp)
 target_link_libraries(plotsmodeltest ${testLibs})
 
-add_definitions("-DSOURCE_DIR=\\\"${CMAKE_CURRENT_SOURCE_DIR}\\\"")
+add_definitions(-DSOURCE_DIR="\\\"${CMAKE_CURRENT_SOURCE_DIR}\\\"")
 kde4_add_unit_test(plotsdictionarymodeltest plotsdictionarymodeltest.cpp)
 target_link_libraries(plotsdictionarymodeltest ${testLibs})
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[parley/KDE/4.14] /: set cmake min req to match kdelibs4; fix build accordingly

2015-07-26 Thread David Faure 
Git commit 7521b4babad3197bcc0171f06d4adcbe923b2b64 by David Faure.
Committed on 26/07/2015 at 14:37.
Pushed by dfaure into branch 'KDE/4.14'.

set cmake min req to match kdelibs4; fix build accordingly

CCMAIL: kde-buildsystem@kde.org

M  +1-0CMakeLists.txt
M  +1-1plasmoid/CMakeLists.txt
M  +1-1plasmoid/engine/CMakeLists.txt

http://commits.kde.org/parley/7521b4babad3197bcc0171f06d4adcbe923b2b64

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9fa08a6..a06ac72 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 project(parley)
 
 find_package(KDE4 REQUIRED)
diff --git a/plasmoid/CMakeLists.txt b/plasmoid/CMakeLists.txt
index bdebb75..2cf6fc7 100644
--- a/plasmoid/CMakeLists.txt
+++ b/plasmoid/CMakeLists.txt
@@ -10,7 +10,7 @@ kde4_add_ui_files(parley_plasma_SRCS config.ui)
 
 kde4_add_plugin(plasma_applet_parley ${parley_plasma_SRCS})
 target_link_libraries(plasma_applet_parley
-plasma ${KDE4_KIO_LIBS}
+   ${KDE4_PLASMA_LIBS} ${KDE4_KIO_LIBS}
 ${LIBKDEEDU_KEDUVOCDOCUMENT_LIBRARIES}
 )
 
diff --git a/plasmoid/engine/CMakeLists.txt b/plasmoid/engine/CMakeLists.txt
index f3af4c4..e0a878c 100644
--- a/plasmoid/engine/CMakeLists.txt
+++ b/plasmoid/engine/CMakeLists.txt
@@ -6,7 +6,7 @@ include_directories( ${LIBKDEEDU_INCLUDE_DIR} )
 
 kde4_add_plugin(plasma_engine_parley ${parley_engine_SRCS})
 target_link_libraries(plasma_engine_parley ${KDE4_KDECORE_LIBS}
-  plasma
+  ${KDE4_PLASMA_LIBS}
   ${LIBKDEEDU_KEDUVOCDOCUMENT_LIBRARIES}
 )
 
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kuser] /: set cmake min req and fix linking, working around the lack of a ${KDE4_KNTLM_LIBS}

2015-07-26 Thread David Faure 
Git commit 9fbacac53225885be9f2fcdbe6b90acfc84d1026 by David Faure.
Committed on 26/07/2015 at 14:54.
Pushed by dfaure into branch 'master'.

set cmake min req and fix linking, working around the lack of a 
${KDE4_KNTLM_LIBS}

CCMAIL: kde-buildsystem@kde.org

M  +2-1CMakeLists.txt

http://commits.kde.org/kuser/9fbacac53225885be9f2fcdbe6b90acfc84d1026

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3282eb0..44540e9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 project(kuser)
 
 # search packages used by KDE
@@ -86,7 +87,7 @@ kde4_add_ui_files(kuser_SRCS ku_filessettings.ui 
ku_generalsettings.ui ku_ldapse
 
 kde4_add_executable(kuser ${kuser_SRCS})
 
-target_link_libraries(kuser ${KDE4_KIO_LIBS} ${KDE4_KLDAP_LIBS} kntlm)
+target_link_libraries(kuser ${KDE4_KIO_LIBS} ${KDE4_KLDAP_LIBS} 
${KDE4_TARGET_PREFIX}kntlm)
 if(HAVE_CRYPT_LIBRARY)
target_link_libraries(kuser crypt)
 endif(HAVE_CRYPT_LIBRARY)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: marble and cmake_min_req

2015-07-26 Thread David Faure 
Please check kmix too:


if(POLICY CMP0046)
  cmake_policy (SET CMP0046 NEW)
endif()

# Your project should require at least CMake 2.8.12 to use FindKF5.cmake
if (KMIX_KF5_BUILD)
   cmake_minimum_required(VERSION 2.8.12)
   add_definitions( -DX_KMIX_KF5_BUILD )
   add_definitions( -DTRANSLATION_DOMAIN=\"kmix\" )
else ()
   cmake_minimum_required(VERSION 2.8.11)
endif()

if(POLICY CMP0046)
  cmake_policy (SET CMP0046 NEW)
endif()



-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kmplayer] /: set cmake_min_req to 2.8.9 to match kdelibs4 policy; fix build accordingly

2015-07-26 Thread David Faure 
Git commit 4be412db53ce6342103836163c7b809f36d88a03 by David Faure.
Committed on 26/07/2015 at 15:50.
Pushed by dfaure into branch 'master'.

set cmake_min_req to 2.8.9 to match kdelibs4 policy; fix build accordingly

(working around the lack of ${KDE4_KMEDIAPLAYER_LIBS})

CCMAIL: kde-buildsystem@kde.org

M  +1-0CMakeLists.txt
M  +5-3src/CMakeLists.txt

http://commits.kde.org/kmplayer/4be412db53ce6342103836163c7b809f36d88a03

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 43d78ab..ff94308 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,4 @@
+cmake_minimum_required(VERSION 2.8.9)
 project(kmplayer)
 
 cmake_policy(VERSION 2.6)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 01180df..ac230ef 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -13,7 +13,7 @@ IF (KMPLAYER_WITH_CAIRO)
 MESSAGE("have cairo cflags:${optionalCFlags} ldflags:${optionalLinkFlags}")
 endif (KMPLAYER_WITH_CAIRO)
 
-add_definitions(-DQT3_SUPPORT 
-DKMPLAYER_VERSION_STRING=\\"${KMPLAYER_VERSION_STRING}\\")
+add_definitions(-DQT3_SUPPORT 
-DKMPLAYER_VERSION_STRING="\\\"${KMPLAYER_VERSION_STRING}\\\"")
 
 ADD_DEFINITIONS(${CAIROCFlags})
 
@@ -73,6 +73,7 @@ SET_TARGET_PROPERTIES(kmplayercommon PROPERTIES COMPILE_FLAGS
 "${CAIROCflags} ${GLibDBusCflags}")
 
 target_link_libraries(kmplayercommon
+   LINK_PRIVATE
   ${CAIROLinkFlags}
   ${GLibDBusLinkFlags}
   ${KDE4_KPARTS_LIBS}
@@ -81,7 +82,7 @@ target_link_libraries(kmplayercommon
   ${X11_X11_LIB}
   ${EXPAT_LIBRARIES}
   ${KDE4_SOLID_LIBS}
-  kmediaplayer
+  ${KDE4_TARGET_PREFIX}kmediaplayer
 )
 
 install(TARGETS kmplayercommon ${INSTALL_TARGETS_DEFAULT_ARGS} )
@@ -93,7 +94,8 @@ set(kmplayerpart_SRCS kmplayer_part.cpp)
 kde4_add_plugin(kmplayerpart WITH_PREFIX ${kmplayerpart_SRCS})
 
 target_link_libraries(kmplayerpart
-  kmplayercommon kmediaplayer
+  kmplayercommon
+  ${KDE4_TARGET_PREFIX}kmediaplayer
   ${KDE4_KPARTS_LIBS}
   ${KDE4_KDEUI_LIBS}
   ${QT_QT3SUPPORT_LIBRARY}
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kphotoalbum] /: set cmake_min_req to 2.8.9 to match kdelibs4 policy; fix build accordingly

2015-07-26 Thread David Faure 
Git commit f785317ba88528760886b592aa9604b0c4ba62dd by David Faure.
Committed on 26/07/2015 at 16:12.
Pushed by dfaure into branch 'master'.

set cmake_min_req to 2.8.9 to match kdelibs4 policy; fix build accordingly

(working around the lack of ${KDE4_KMEDIAPLAYER_LIBS})

CCMAIL: kde-buildsystem@kde.org

M  +2-2CMakeLists.txt

http://commits.kde.org/kphotoalbum/f785317ba88528760886b592aa9604b0c4ba62dd

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6335f9b..f7741fa 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)
+cmake_minimum_required(VERSION 2.8.9)
 project(kphotoalbum)
 
 if(POLICY CMP0017)
@@ -456,7 +456,7 @@ kde4_add_library(Utilities STATIC ${libUtilities_SRCS})
 target_link_libraries(kphotoalbum Utilities)
 
 # External components
-target_link_libraries(kphotoalbum ${KDE4_KIO_LIBS} ${JPEG_LIBRARY} 
kmediaplayer ${KDE4_PHONON_LIBS})
+target_link_libraries(kphotoalbum ${KDE4_KIO_LIBS} ${JPEG_LIBRARY} 
${KDE4_TARGET_PREFIX}kmediaplayer ${KDE4_PHONON_LIBS})
 
 if(KIPI_FOUND)
 target_link_libraries(kphotoalbum ${KIPI_LIBRARIES})
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Fwd: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument

2015-08-04 Thread David Faure 
Hello Brad,

IMHO your logic is inconsistent with the fact that
set(CMAKE_CXX_VISIBILITY_PRESET hidden)
and
set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)

are ** GLOBAL OPTIONS **, they are not limited to the project.
If one "dependency" sets this, it affects the whole project.
There is clearly a need to fine-tune what these things do.
But maybe this particular behavior change shouldn't be done with a policy then,
but with another global variable.
Random idea:
set(CMAKE_CXX_VISIBILITY_ALL_TARGETS_PRESET hidden)
i.e. keep CMAKE_CXX_VISIBILITY_PRESET applying to only shared libs,
and have another variable for a preset that applis to shared libs, static libs 
and executables.
(this is from what I remember of this issue, maybe there's a better solution for
fine-tuning what these global variables do).

Basically it sounds to me like cmake is starting to overuse this policy thing, 
as a bad excuse
for changing behavior all the time, when more source-compatible changes could 
be made instead.

David.

On Friday 31 July 2015 19:36:07 Alex Merry wrote:
> David,
> 
> CMake won't accept the patch we discussed, and Brad says that projects should 
> either set NO_POLICY_SCOPE when they include the file, or else set the policy 
> manually themselves.
> 
> Alex
> 
> --  Forwarded Message  --
> 
> Subject: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New 
> PARENT_SCOPE 
> argument
> Date: Friday 31 July 2015, 13:30:03
> From: Brad King 
> To: Alex Merry 
> CC: cmake-develop...@cmake.org
> 
> On 07/31/2015 12:54 PM, Alex Merry wrote:
> >> Setting policies centrally breaks their compatibility model.
> > 
> > I should perhaps explain our use case:
> 
> My assertion stands regardless of the use case.
> 
> > Now, sure, we could change every single project that includes this module 
> > to 
> > use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we 
> > tell people to use this module, it seems a very clunky approach.
> 
> That is the correct approach.
> 
> If a project wants to opt-in to letting KDECompilerSettings set
> policies for it (and therefore accept the risk of the broken
> compatibility model) then it should state so explicitly by
> including the module with NO_POLICY_SCOPE.
> 
> > It means the module is at risk of leaking policy settings it didn't mean to
> 
> Use cmake_policy(PUSH/POP) around most of the module. Then set
> policies explicitly outside of that scope if they are intended
> to be set for includers that use NO_POLICY_SCOPE.
> 
> > you are asking users to opt-in to this particular behavoural change
> 
> Yes, because the behavior change comes from a CMake version update.
> 
> The purpose of policies is to not change behavior for a project until
> it is modified to be aware of the CMake version that makes the change.
> For this compatibility model to work the modification must be made
> in the project itself, not in one of its dependencies.
> 
> -Brad
> 
> -

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 124613: kdesrc-build: improve message about why a full refresh is needed

2015-08-04 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124613/
---

Review request for Build System and Michael Pyne.


Repository: kdesrc-build


Description
---

i.e. be more precise than "meets other building criteria"


Diffs
-

  modules/ksb/BuildSystem.pm 24963040d77dc93f8f86a2f19755c617713bbd8a 
  modules/ksb/IPC.pm 0e55c5fe5c2a8771f6b9b159a684bdcc6dda52a7 
  modules/ksb/Module.pm a7a7fbcc5e30cbb4c52979d87407a3250b80f2b2 

Diff: https://git.reviewboard.kde.org/r/124613/diff/


Testing
---

Example:

$ kdesrc-build --refresh plasma-nm

Building plasma-nm from kf5-network-management (1/1)
Updating plasma-nm (to branch master)
No source update, but the option refresh-build was set
Source update complete for plasma-nm: no files affected
Preparing build system for plasma-nm.
...


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124613: kdesrc-build: improve message about why a full refresh is needed

2015-08-09 Thread David Faure 


On Aug. 7, 2015, 1:37 a.m., David Faure wrote:
> > One other thing, the "l10nSystem" class is a source updater and a build 
> > system combined, and has a 'needsRefreshed' sub that would also need 
> > updated. Something like this diff should work:
> > 
> > diff --git a/modules/ksb/l10nSystem.pm b/modules/ksb/l10nSystem.pm
> > index e5756f8..0101824 100644
> > --- a/modules/ksb/l10nSystem.pm
> > +++ b/modules/ksb/l10nSystem.pm
> > @@ -24,7 +24,9 @@ sub new
> >  # TODO: Support different localization branches?
> >  
> >  $module->setOption('module-base-path', 'trunk/l10n-kde4');
> > -return bless { module => $module, needsRefreshed => 1 }, $class;
> > +
> > +my $refreshMessage = "couldn't verify the source is unchanged";
> > +return bless { module => $module, needsRefreshed => 
> > $refreshMessage }, $class;
> >  }
> >  
> >  sub module
> > @@ -75,7 +77,7 @@ sub updateInternal
> >  $self->check_module_validity();
> >  my $count = $self->update_module_path(@dirs);
> >  
> > -$self->{needsRefreshed} = 0 if $count == 0;
> > +$self->{needsRefreshed} = '' if $count == 0;
> >  return $count;
> >  }
> >  else {
> > @@ -103,7 +105,7 @@ sub needsRefreshed
> >  {
> >  my $self = shift;
> >  
> > -# Should be 1 except if no update happened.
> > +# Should be a 'reason' string except if no update happened.
> >  return $self->{needsRefreshed};
> >  }
> > 
> > With those taken care of you have a +1 from me.

Since the value is set to empty (in the 2nd hunk) when no files were updated by 
"svn update", doesn't this mean that the message in the first hunk should be 
"an update happened"?


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124613/#review83527
---


On Aug. 4, 2015, 9:57 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124613/
> ---
> 
> (Updated Aug. 4, 2015, 9:57 a.m.)
> 
> 
> Review request for Build System and Michael Pyne.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> i.e. be more precise than "meets other building criteria"
> 
> 
> Diffs
> -
> 
>   modules/ksb/BuildSystem.pm 24963040d77dc93f8f86a2f19755c617713bbd8a 
>   modules/ksb/IPC.pm 0e55c5fe5c2a8771f6b9b159a684bdcc6dda52a7 
>   modules/ksb/Module.pm a7a7fbcc5e30cbb4c52979d87407a3250b80f2b2 
> 
> Diff: https://git.reviewboard.kde.org/r/124613/diff/
> 
> 
> Testing
> ---
> 
> Example:
> 
> $ kdesrc-build --refresh plasma-nm
> 
> Building plasma-nm from kf5-network-management (1/1)
> Updating plasma-nm (to branch master)
> No source update, but the option refresh-build was set
> Source update complete for plasma-nm: no files affected
> Preparing build system for plasma-nm.
> ...
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124613: kdesrc-build: improve message about why a full refresh is needed

2015-08-09 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124613/#review83595
---



modules/ksb/BuildSystem.pm (line 73)
<https://git.reviewboard.kde.org/r/124613/#comment57852>

Are you sure? I found code in Module.pm line 509 that creates a .refresh-me 
file right after printing out "Unable to configure".



modules/ksb/BuildSystem.pm (line 79)
<https://git.reviewboard.kde.org/r/124613/#comment57854>

what does // 0 mean btw?



modules/ksb/BuildSystem.pm (line 82)
<https://git.reviewboard.kde.org/r/124613/#comment57853>

Well, either that or the user manually wiped out the contents of the 
builddir (but not the builddir itself).
(or kdesrc-build looks for the wrong file, in case of a bug).

I'd like to keep the output as precise as possible, so one can figure out 
why exactly this is happening...


- David Faure


On Aug. 4, 2015, 9:57 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124613/
> ---
> 
> (Updated Aug. 4, 2015, 9:57 a.m.)
> 
> 
> Review request for Build System and Michael Pyne.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> i.e. be more precise than "meets other building criteria"
> 
> 
> Diffs
> -
> 
>   modules/ksb/BuildSystem.pm 24963040d77dc93f8f86a2f19755c617713bbd8a 
>   modules/ksb/IPC.pm 0e55c5fe5c2a8771f6b9b159a684bdcc6dda52a7 
>   modules/ksb/Module.pm a7a7fbcc5e30cbb4c52979d87407a3250b80f2b2 
> 
> Diff: https://git.reviewboard.kde.org/r/124613/diff/
> 
> 
> Testing
> ---
> 
> Example:
> 
> $ kdesrc-build --refresh plasma-nm
> 
> Building plasma-nm from kf5-network-management (1/1)
> Updating plasma-nm (to branch master)
> No source update, but the option refresh-build was set
> Source update complete for plasma-nm: no files affected
> Preparing build system for plasma-nm.
> ...
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124613: kdesrc-build: improve message about why a full refresh is needed

2015-08-09 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124613/
---

(Updated Aug. 9, 2015, 9:36 a.m.)


Review request for Build System and Michael Pyne.


Changes
---

made the requested changes that I understood ;)


Repository: kdesrc-build


Description (updated)
---

i.e. be more precise than "meets other building criteria"

REVIEW: 124613


Diffs (updated)
-

  modules/ksb/IPC.pm 0e55c5fe5c2a8771f6b9b159a684bdcc6dda52a7 
  modules/ksb/Module.pm a7a7fbcc5e30cbb4c52979d87407a3250b80f2b2 
  modules/ksb/l10nSystem.pm e5756f85026ad9b95533d2989746ab91f87920a6 
  modules/ksb/BuildSystem.pm 24963040d77dc93f8f86a2f19755c617713bbd8a 

Diff: https://git.reviewboard.kde.org/r/124613/diff/


Testing
---

Example:

$ kdesrc-build --refresh plasma-nm

Building plasma-nm from kf5-network-management (1/1)
Updating plasma-nm (to branch master)
No source update, but the option refresh-build was set
Source update complete for plasma-nm: no files affected
Preparing build system for plasma-nm.
...


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124613: kdesrc-build: improve message about why a full refresh is needed

2015-08-12 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124613/
---

(Updated Aug. 12, 2015, 8:50 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and Michael Pyne.


Changes
---

Submitted with commit d480b86c65943c7c1eb1644b59689132e4512b05 by David Faure 
to branch master.


Repository: kdesrc-build


Description
---

i.e. be more precise than "meets other building criteria"

REVIEW: 124613


Diffs
-

  modules/ksb/IPC.pm 0e55c5fe5c2a8771f6b9b159a684bdcc6dda52a7 
  modules/ksb/Module.pm a7a7fbcc5e30cbb4c52979d87407a3250b80f2b2 
  modules/ksb/l10nSystem.pm e5756f85026ad9b95533d2989746ab91f87920a6 
  modules/ksb/BuildSystem.pm 24963040d77dc93f8f86a2f19755c617713bbd8a 

Diff: https://git.reviewboard.kde.org/r/124613/diff/


Testing
---

Example:

$ kdesrc-build --refresh plasma-nm

Building plasma-nm from kf5-network-management (1/1)
Updating plasma-nm (to branch master)
No source update, but the option refresh-build was set
Source update complete for plasma-nm: no files affected
Preparing build system for plasma-nm.
...


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Fwd: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument

2015-08-15 Thread David Faure 
On Wednesday 05 August 2015 09:11:59 Brad King wrote:
> On 08/04/2015 08:42 AM, Brad King wrote:
> > The compatibility model for policies is that the authors of a
> > project should be aware of changes to CMake's preferred behavior
> > before their project is affected by it.  They indicate so by
> > updating their own source to set the policy to NEW.  If your
> > dependents want to defer this decision to you and accept the
> > risk of the broken compatibility model then they can include
> > you with NO_POLICY_SCOPE.  That is our model.
> 
> That said, you may still be able to hack this without updating
> your dependents by setting CMAKE_POLICY_DEFAULT_CMP0063 to NEW:
> 
>  
> http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_POLICY_DEFAULT_CMP.html
> 
> The variable is meant for end users to set in their local cache
> to quiet policy warnings without modifying the project.  The
> variable documents that it should not be set by project code,
> but you could abuse it for your use case.  Setting it won't
> override policy settings made by your dependents but can set
> the default when they don't set the policy at all.  This still
> breaks our compatibility model, but it is an option you have.

Thanks for the suggestion, however I can't make it work. Am I doing it wrong?

 
--- a/kde-modules/KDECompilerSettings.cmake
+++ b/kde-modules/KDECompilerSettings.cmake
@@ -198,6 +198,7 @@ endif()
 # Default to hidden visibility for symbols
 set(CMAKE_CXX_VISIBILITY_PRESET hidden)
 set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
+set(CMAKE_POLICY_DEFAULT_CMP0063 NEW PARENT_SCOPE) # don't let cmake >= 3.3 
warn about the above
 
 if (UNIX AND NOT APPLE)
 # Enable adding DT_RUNPATH, which means that LD_LIBRARY_PATH takes 
precedence


I still get warnings like this for each and every target:

CMake Warning (dev) at autotests/CMakeLists.txt:4 (add_executable):
  Policy CMP0063 is not set: Honor visibility properties for all target
  types.  Run "cmake --help-policy CMP0063" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target "krossqtstest" of type "EXECUTABLE" has the following visibility
  properties set for CXX:

CXX_VISIBILITY_PRESET
VISIBILITY_INLINES_HIDDEN

  For compatibility CMake is not honoring them for this target.
This warning is for project developers.  Use -Wno-dev to suppress it.



-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124740: Also set the default visibility for C code to hidden.

2015-08-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124740/#review83856
---

Ship it!


Ship It!

- David Faure


On Aug. 14, 2015, 6:11 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124740/
> ---
> 
> (Updated Aug. 14, 2015, 6:11 p.m.)
> 
> 
> Review request for Extra Cmake Modules.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> This prevents accidental "leaking" of symbols from internal code, such as 
> flex/bison generated parsers.
> 
> Affects Solid, Service and CalendarCore at least.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake 
> 5a5850214f615662a6937f0390c28869c3bbc352 
> 
> Diff: https://git.reviewboard.kde.org/r/124740/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 124762: KDEFrameworkCompilerSettings: only enable strict iterators in debug mode

2015-08-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124762/
---

Review request for Extra Cmake Modules.


Repository: extra-cmake-modules


Description
---

(they are slower)


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 
1bc23ccf8e8a54d3c6153ad6c999d41e31e64417 

Diff: https://git.reviewboard.kde.org/r/124762/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 124763: Add -pedantic for KF5 code (when using gcc or clang)

2015-08-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124763/
---

Review request for Extra Cmake Modules.


Repository: extra-cmake-modules


Description
---

Add -pedantic for KF5 code (when using gcc or clang)


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 
1bc23ccf8e8a54d3c6153ad6c999d41e31e64417 

Diff: https://git.reviewboard.kde.org/r/124763/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124763: Add -pedantic for KF5 code (when using gcc or clang)

2015-08-18 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124763/
---

(Updated Aug. 18, 2015, 9:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules.


Changes
---

Submitted with commit 7af8bdcc7610df1de24c36ceeedd8c9f82529634 by David Faure 
to branch master.


Repository: extra-cmake-modules


Description
---

Add -pedantic for KF5 code (when using gcc or clang)


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 
1bc23ccf8e8a54d3c6153ad6c999d41e31e64417 

Diff: https://git.reviewboard.kde.org/r/124763/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124762: KDEFrameworkCompilerSettings: only enable strict iterators in debug mode

2015-08-18 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124762/
---

(Updated Aug. 18, 2015, 9:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules.


Changes
---

Submitted with commit 00b1f67ef595c6fd2b326738ea7ac03c0e23303b by David Faure 
to branch master.


Repository: extra-cmake-modules


Description
---

(they are slower)


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 
1bc23ccf8e8a54d3c6153ad6c999d41e31e64417 

Diff: https://git.reviewboard.kde.org/r/124762/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124595: Add macro to generate logging category declarations for Qt5.

2015-08-18 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124595/#review84022
---

Ship it!


Very extensive, many many thanks!


modules/ECMQtDeclareLoggingCategory.cmake (line 33)
<https://git.reviewboard.kde.org/r/124595/#comment58203>

5.14 now


- David Faure


On Aug. 16, 2015, 9:34 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124595/
> ---
> 
> (Updated Aug. 16, 2015, 9:34 p.m.)
> 
> 
> Review request for Extra Cmake Modules and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> This makes life a bit easier for developers who use the categorised
> logging in Qt5 in the common case - rather than creating two new files,
> and remembering to put in the #ifdef for the default verbosity settings
> in Qt 5.4, they can just add a couple of lines to their CMakeLists.txt.
> 
> (NB: see https://codereview.qt-project.org/#/c/122641 for patch for the Qt 
> bug mentioned in the docs).
> 
> 
> Diffs
> -
> 
>   tests/ECMQtDeclareLoggingCategoryTest/testmain.cpp PRE-CREATION 
>   tests/ECMQtDeclareLoggingCategoryTest/CMakeLists.txt PRE-CREATION 
>   tests/CMakeLists.txt 7960154a42ec083be61aec2bd066b072560beb61 
>   modules/ECMQtDeclareLoggingCategory.h.in PRE-CREATION 
>   modules/ECMQtDeclareLoggingCategory.cpp.in PRE-CREATION 
>   docs/module/ECMQtDeclareLoggingCategory.rst PRE-CREATION 
>   modules/ECMQtDeclareLoggingCategory.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124595/diff/
> 
> 
> Testing
> ---
> 
> Added unit test runs and passes. Documentation builds and looks sane.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: broken kdelibs - was- Fwd: Re: KDE Applications 15.08.0 available for packagers

2015-08-19 Thread David Faure 
On Wednesday 19 August 2015 00:08:55 Albert Astals Cid wrote:
> Please somebody fix this.

Didn't I just fix that yesterday evening?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library

2015-08-26 Thread David Faure 


> On Aug. 25, 2015, 1:41 p.m., David Edmundson wrote:
> > I've got both Gentoo and Arch saying this causes a major problem [1]:
> > 
> > libdraganddropplugin.so changes to draganddropplugin.so
> > in /usr/lib/qt/qml/org/kde/draganddrop
> > 
> > and then they don't get loaded.
> > 
> > any ideas? Otherwise I'll have to revert this before release.
> > 
> > [1] https://aur.archlinux.org/packages/plasma-desktop-git/
> 
> Harald Sitter wrote:
> I tried it this morning and it seemed to work. Now I try it again and it 
> fails
> 
> I suppose this is the point where we call for a revert hammer? :P
> 
> Harald Sitter wrote:
> from qmldir documentation
> 
> Declares a plugin to be made available by the module.
>  is the plugin library name. This is usually not the same as the 
> file name of the plugin binary, which is platform dependent; e.g. the library 
> MyAppTypes would produce libMyAppTypes.so on Linux and MyAppTypes.dll on 
> Windows.
> 
> Harald Sitter wrote:
> 
> http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SHARED_MODULE_PREFIX.html
> 
> David Edmundson wrote:
> are we meant to set that to "lib" in every project? That doesn't sound 
> right.
> 
> Harald Sitter wrote:
> More like per-target even, since a kded plugin for example wouldn't want 
> the prefix I suppose. It might well be that switching the qml plugins to 
> MODULE is quite simply not the best solution to the initial problem on OSX, 
> even though TBH they are really MODULE and not SHARED anyway so by any 
> measure declaring them SHARED was weird all along.
> alexmerry might know of a better way but from my quick research it 
> appears that either we need to set the prefix variable (supposedly via a 
> macro wrapping add_library) or we revert back to SHARED and need to find 
> another way to coerce cmake into producing working results on OSX.
> 
> In a way I would argue that the problem is more with the qml loader not 
> looking for a version without lib prefix if the lib prefix one is not 
> available. So, regardless of how we proceed with kdeclarative I think it 
> would be wortwhile to possible expand the qml loader to not require the lib 
> prefix on unix systems. If not to resolve the issue at hand, at least to have 
> it behave reasonably in the distant future.
> 
> René J.V. Bertin wrote:
> > find another way to coerce cmake into producing working results on OSX
> 
> Are you sure that results actually "do no not work" on OS X (and that 
> this has nothing to do with QStandardPaths returning unexpected locations)?!
> It is always possible to ensure that the plugins get the correct 
> install_name and even a compatibility_version if there's any point in that 
> (do these get versioning under Linux?). This can be done during the link step 
> but also afterwards (probably more complicated to get right in CMake 
> scripts). Whatever the approach, it should be possible to do it in the CMake 
> macro (cmake already generates an option to set the install_name because 
> otherwise the linker would either assume a relative install_name [just the 
> filename] or use the full path to the output file).
> 
> I presume that at least some of the plugins targeted here exists for KDE4 
> and if so, are still built the way they were there?

Harald: you are right, Qt requiring the lib prefix is incorrect (unnecessary 
and confusing) on Linux, since as you say, a module is not a shared lib.
QLibrary actually tries with and without the lib prefix (which is why C++ 
plugins like kded and others don't have it). I assume QML doesn't use QLibrary 
then?


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124892/#review84333
---


On Aug. 23, 2015, 9:16 p.m., Hanspeter Niederstrasser wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124892/
> ---
> 
> (Updated Aug. 23, 2015, 9:16 p.m.)
> 
> 
> Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, 
> Plasma, and Harald Sitter.
> 
> 
> Bugs: 342962
> https://bugs.kde.org/show_bug.cgi?id=342962
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> The kdeclarative plugins (draganddropplugin, kcoreaddonsplugin, kio, 
> kquickcontrolsprivateplugin, and kquickcontrolsaddonsplugin) are being built 
> as shared libraries. They should be built as bundles (MODULE) in the 
> CMakeLists.txt file.
> 
> When built as SHARED as in the current code, libdraganddropplugin.dylib gets 
> installed to $PREFIX/share/qt5/qml/org/kde/draganddrop, but is given an OS X 
> install_name of $PREFIX/lib/libdraganddropplugin.dylib. This mismatch can 
> cause problems. It is also gi

Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

2015-09-02 Thread David Faure 
On Monday 31 August 2015 14:41:00 Friedrich W. H. Kossebau wrote:
> 
> The only place lxr.kde.org pointed out to use the *TEST_EXPORT approach was 
> grantlee, which simply creates a separate file with the define that then is 
> appended to the file generated with generate_export_header:
> http://lxr.kde.org/source/grantlee/templates/lib/CMakeLists.txt

Konqueror has a simpler approach, a file that includes the generated file
and adds the tests_export macro on top.

 #include "konquerorprivate_export.h"

/* Classes from the Konqueror application, which are exported only for unit 
tests */
#ifdef COMPILING_TESTS
# ifndef KONQ_TESTS_EXPORT
#  define KONQ_TESTS_EXPORT KONQUERORPRIVATE_EXPORT
# endif
#else /* not compiling tests */
# define KONQ_TESTS_EXPORT
#endif

See kde/applications/kde-baseapps/konqueror/src/konqprivate_export.h
branch frameworks.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125192: Update GTK icon cache when installing icons.

2015-09-13 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125192/#review85334
---



modules/ECMInstallIcons.cmake (line 187)
<https://git.reviewboard.kde.org/r/125192/#comment58958>

Olivier, I was wrong! You can remove the recursive mtime check from Qt, if 
the rule is always that any icon installation must touch the toplevel dir. 
Which clearly we were doing already. Sorry for the wrong advice on my part.


- David Faure


On Sept. 12, 2015, 12:23 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125192/
> ---
> 
> (Updated Sept. 12, 2015, 12:23 p.m.)
> 
> 
> Review request for Extra Cmake Modules and Olivier Goffart.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Despite the name, Qt is also using this, and it considerably speeds up
> icon lookup.
> 
> 
> Diffs
> -
> 
>   modules/ECMInstallIcons.cmake 79dc5150e8a966db2a9fdd39cbd5ce8c2f842e18 
> 
> Diff: https://git.reviewboard.kde.org/r/125192/diff/
> 
> 
> Testing
> ---
> 
> Built and installed kdepim, cache files are generated in the expected places.
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125192: Update GTK icon cache when installing icons.

2015-09-15 Thread David Faure 


> On Sept. 13, 2015, 9:27 p.m., David Faure wrote:
> > modules/ECMInstallIcons.cmake, line 187
> > <https://git.reviewboard.kde.org/r/125192/diff/1/?file=402974#file402974line187>
> >
> > Olivier, I was wrong! You can remove the recursive mtime check from Qt, 
> > if the rule is always that any icon installation must touch the toplevel 
> > dir. Which clearly we were doing already. Sorry for the wrong advice on my 
> > part.
> 
> Olivier Goffart wrote:
> David: but does the package manager that contains icons will touch the 
> theme directory?

Ah, good question. No idea though. That's a question for release-t...@kde.org, 
where the packagers will be able to answer you.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125192/#review85334
---


On Sept. 12, 2015, 12:23 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125192/
> ---
> 
> (Updated Sept. 12, 2015, 12:23 p.m.)
> 
> 
> Review request for Extra Cmake Modules and Olivier Goffart.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Despite the name, Qt is also using this, and it considerably speeds up
> icon lookup.
> 
> 
> Diffs
> -
> 
>   modules/ECMInstallIcons.cmake 79dc5150e8a966db2a9fdd39cbd5ce8c2f842e18 
> 
> Diff: https://git.reviewboard.kde.org/r/125192/diff/
> 
> 
> Testing
> ---
> 
> Built and installed kdepim, cache files are generated in the expected places.
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125192: Update GTK icon cache when installing icons.

2015-09-19 Thread David Faure 


> On Sept. 13, 2015, 9:27 p.m., David Faure wrote:
> > modules/ECMInstallIcons.cmake, line 187
> > <https://git.reviewboard.kde.org/r/125192/diff/1/?file=402974#file402974line187>
> >
> > Olivier, I was wrong! You can remove the recursive mtime check from Qt, 
> > if the rule is always that any icon installation must touch the toplevel 
> > dir. Which clearly we were doing already. Sorry for the wrong advice on my 
> > part.
> 
> Olivier Goffart wrote:
> David: but does the package manager that contains icons will touch the 
> theme directory?
> 
> David Faure wrote:
> Ah, good question. No idea though. That's a question for 
> release-t...@kde.org, where the packagers will be able to answer you.
> 
> Maciej Mrozowski wrote:
> Icon cache is cretaed at package install phase by package manager. cmake 
> install (where you invoke gtk-update-icon-cache) is source install phase. 
> Source install phase happens in sandboxed environment most of the time so 
> runnig gtk update icon cache will just work for kdebuild and local 
> installations. For distro packagers this will be a command to sed-out from 
> CMakeLists.
> 
> Maciej Mrozowski wrote:
> Small update. Icon cache is movable (does not contain absolute paths) so 
> icon cache will work when copied from package installation image to target 
> filesystem. Still generating it in buildsystem is stepping a bit too far into 
> packager area. With my Gentoo hat on. Worth asking jriddel what he thinks.
> 
> Volker Krause wrote:
> This is purely meant for developer builds, not distros. There this is 
> better done in post install hooks indeed. The DESTDIR check around this 
> should disable this for normal distro builds, same as we do already for e.g. 
> updating the mime database.

And this is all somewhat besides the point. The question wasn't "can/should 
packages run gtk-update-icon-cache in the future" (the answer is yes).

The question is... when you install some package that was made in the last 8 
years and that isn't about a GTK application, let's say firefox, libreoffice or 
whatever else,
if the package contains icons, does the package manager touch the toplevel icon 
theme directory or not.
If not, then we are going to miss the new icons. But then again, I suppose GTK 
would miss them too. So I guess packages do update the dir (or even run the 
gtk tool).


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125192/#review85334
---


On Sept. 12, 2015, 12:23 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125192/
> ---
> 
> (Updated Sept. 12, 2015, 12:23 p.m.)
> 
> 
> Review request for Extra Cmake Modules and Olivier Goffart.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Despite the name, Qt is also using this, and it considerably speeds up
> icon lookup.
> 
> 
> Diffs
> -
> 
>   modules/ECMInstallIcons.cmake 79dc5150e8a966db2a9fdd39cbd5ce8c2f842e18 
> 
> Diff: https://git.reviewboard.kde.org/r/125192/diff/
> 
> 
> Testing
> ---
> 
> Built and installed kdepim, cache files are generated in the expected places.
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125192: Update GTK icon cache when installing icons.

2015-10-03 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125192/#review86280
---

Ship it!


Right, sorry for delaying the "ship it" on this one. The discussion derailed 
into whether Qt should or shouldn't do a recursive mtime check, but this patch 
in itself is good to go, of course.

- David Faure


On Sept. 12, 2015, 12:23 p.m., Volker Krause wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125192/
> ---
> 
> (Updated Sept. 12, 2015, 12:23 p.m.)
> 
> 
> Review request for Extra Cmake Modules and Olivier Goffart.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Despite the name, Qt is also using this, and it considerably speeds up
> icon lookup.
> 
> 
> Diffs
> -
> 
>   modules/ECMInstallIcons.cmake 79dc5150e8a966db2a9fdd39cbd5ce8c2f842e18 
> 
> Diff: https://git.reviewboard.kde.org/r/125192/diff/
> 
> 
> Testing
> ---
> 
> Built and installed kdepim, cache files are generated in the expected places.
> 
> 
> Thanks,
> 
> Volker Krause
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Fwd: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument

2015-10-03 Thread David Faure 
On Tuesday 04 August 2015 08:42:34 Brad King wrote:
> On 08/04/2015 04:19 AM, David Faure wrote:
> > IMHO your logic is inconsistent with the fact that
> > set(CMAKE_CXX_VISIBILITY_PRESET hidden)
> > and
> > set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
> > 
> > are ** GLOBAL OPTIONS **, they are not limited to the project.
> 
> They are not global options.  They have directory scope.  The
> authors of your dependents know you're setting some things
> for them when they include you, and can optionally isolate
> these effects by including you in a subdirectory.  These
> dependents willingly ask you to set some things for them by
> including your central settings module.
> 
> The compatibility model for policies is that the authors of a
> project should be aware of changes to CMake's preferred behavior
> before their project is affected by it.  They indicate so by
> updating their own source to set the policy to NEW.  If your
> dependents want to defer this decision to you and accept the
> risk of the broken compatibility model then they can include
> you with NO_POLICY_SCOPE.  That is our model.
> 
> > But maybe this particular behavior change shouldn't be done with
> > a policy then, but with another global variable.
> 
> Policies are for when an old behavior is deemed incorrect (as
> was the lack of visibility settings for all target types).  Over
> time projects will have cmake_minimum_required(VERSION) high
> enough to set the policy to NEW automatically, and then no one
> ever notices that the old behavior ever existed.  This allows us
> to fix wrong behavior with no long term cost.
> 
> A solution that requires a project to write
> 
>  set(DO_IT_RIGHT_THIS_TIME 1)
> 
> to enable correct behavior forces all future projects to carry
> that extra setting around forever, and anyone writing a new project
> to know they need to set this every time.  Policies provide a
> compatible transition path to getting correct behavior without
> extra per-case code in the long run.

I see what you meant, but do notice how there is a contradiction in
the above :-)

The required addition of "NO_POLICY_SCOPE" in every application using
the shared code is exactly that: extra code that needs to be kept around for 
ever,
and which forces all future projects that include that shared code to "know
they need to set this every time".
In other words, this solution goes exactly against your own goals.

I can see how you wouldn't want in general some shared code to change
a project-wide policy when it could have an impact on the application's own
cmake code. However the case here is that CMP0063 is only about these
settings the shared code sets itself, there's no other impact on the app's
own cmake code. So I would still think there is a case for being able to
force a project-wide policy from shared code. People shouldn't abuse this
of course, they should only use it when the policy change cannot possibly
break the rest of the project

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: CMake questions (add_definition, CMP0063)

2015-10-03 Thread David Faure 
On Saturday 03 October 2015 00:30:04 Aleix Pol wrote:
> 
> As a proper fix, I'd suggest looking into
> extra-cmake-modules/kde-modules/KDECompilerSettings.cmake, there we
> are setting CMAKE_VISIBILITY_INLINES_HIDDEN globally for all KDE
> projects, we should figure out what's the most appropriate value for
> the variable or whether the policy should be set over there.

Unfortunately, it's not that simple (setting the policy there has no effect
because it doesn't affect the calling module). See the thread 
"Re: Fwd: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE 
argument"
on this very mailing-list, kde-buildsystem.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

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

2015-10-10 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125560/#review86607
---

Ship it!


Ship It!

- David Faure


On Oct. 8, 2015, 5:38 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125560/
> ---
> 
> (Updated Oct. 8, 2015, 5:38 p.m.)
> 
> 
> Review request for Build System, kdelibs and Luigi Toscano.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Backport of review 116650.
> Needed to fix build of some software after kdelibs' 4.14.11 cmake refactoring
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 8622959 
> 
> Diff: https://git.reviewboard.kde.org/r/125560/diff/
> 
> 
> Testing
> ---
> 
> k3b and skanlite tarballs now build.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123726: Make sure we load translations on the main thread.

2015-11-03 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123726/#review87899
---

Ship it!


The threading code looks OK. Slots in a QThread subclass are indeed very 
unintuitive, so I recommend never doing that, but for the benefit of keeping 
the test simple and since you documented it, I'll let this one pass ;-)


modules/ECMQmLoader.cpp.in (line 46)
<https://git.reviewboard.kde.org/r/123726/#comment60303>

maybe in an anonymous namespace, to avoid clashes if this generated code 
happens twice in the same binary/library? (or in case hidden-visibility is 
disabled)


- David Faure


On Oct. 14, 2015, 9:38 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123726/
> ---
> 
> (Updated Oct. 14, 2015, 9:38 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Aurélien Gâteau and Chusslove Illich.
> 
> 
> Bugs: 346188
> http://bugs.kde.org/show_bug.cgi?id=346188
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> BUG: 346188
> 
> 
> Diffs
> -
> 
>   modules/ECMPoQmTools.cmake 12bcf6b67c57dd456f078820f86c1e8365cb7c06 
>   modules/ECMQmLoader.cpp.in bc01bf98f0caa0aedf6b6175ef6c9f7757afdf1b 
>   tests/CMakeLists.txt 8a75ae61d9c2ce2eeb78e0a4c308d0d0c5fff5a5 
>   tests/ECMPoQmToolsTest/CMakeLists.txt 
> 15351d2f710f9bd07a38d3b1ad9b15e24bc64a61 
>   tests/ECMPoQmToolsTest/check_conf.cmake.in PRE-CREATION 
>   tests/ECMPoQmToolsTest/check_tree.cmake.in 
> 9f4f7c0d19f286647ad1c9c99362bd921ff01cba 
>   tests/ECMPoQmToolsTest/tr_test-po/en/catalog.po PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_test-po/en_GB/catalog.po PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_test.cpp PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_thread_test.cpp PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_thread_test_module.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123726/diff/
> 
> 
> Testing
> ---
> 
> Added tests for basic functionality and for loading a module on a thread. 
> Both pass.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125931: Warn instead of error if ecm_install_icons finds no icons.

2015-11-04 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125931/#review87988
---

Ship it!


Ship It!

- David Faure


On Nov. 3, 2015, 12:04 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125931/
> ---
> 
> (Updated Nov. 3, 2015, 12:04 p.m.)
> 
> 
> Review request for Extra Cmake Modules.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> The V1 syntax of ecm_install_icons searched for icons by globbing files
> with a particular naming pattern. If there were no such icons, this used
> to do nothing, but silently. Commit fb7b8eea7d accidentally made this an
> error. More sensible would be to make it a warning.
> 
> BUG: 354610
> 
> 
> Diffs
> -
> 
>   modules/ECMInstallIcons.cmake 8db486e7ab0db3d9f43d09a4b8b22a97a07b3bae 
>   tests/ECMInstallIconsTest/CMakeLists.txt 
> 738cba916a2798d5ef63300f0db418e2ee9fb3be 
>   tests/ECMInstallIconsTest/v1-syntax-no-icons/CMakeLists.txt PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125931/diff/
> 
> 
> Testing
> ---
> 
> Extended unit test, which passes, and ksirk now successfully configures.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125983: Give each htmlhandbook target a unique name

2015-11-08 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125983/#review88155
---

Ship it!


Ship It!

- David Faure


On Nov. 7, 2015, 1:59 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125983/
> ---
> 
> (Updated Nov. 7, 2015, 1:59 p.m.)
> 
> 
> Review request for Build System and kdelibs.
> 
> 
> Bugs: 351287
> http://bugs.kde.org/show_bug.cgi?id=351287
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Since the CMP0002 warnings have been turned into errors it was
> impossible to build kdelibs with -DKDE4_ENABLE_HTMLHANDBOOK:BOOL=TRUE:
> 
> "CMake Error at cmake/modules/KDE4Macros.cmake:315 (add_custom_target):
> add_custom_target cannot create target "htmlhandbook" because another
> target with the same name already exists"
> 
> The bug below is more about the similar error with -DKDE4_BUILD_TESTS
> but since it's still open (and I commented there about the htmlhandbook
> error ;-) I included it here.
> 
> BUG: 351287
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 5b3db07206d8075fdb580fda9f0b1f8d76a80511 
> 
> Diff: https://git.reviewboard.kde.org/r/125983/diff/
> 
> 
> Testing
> ---
> 
> Passed -DKDE4_ENABLE_HTMLHANDBOOK:BOOL=TRUE to the build, which succeeded 
> withouth error.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125999: Fix multiple calls to ecm_create_qm_loader.

2015-11-14 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125999/#review88356
---

Ship it!



tests/ECMPoQmToolsTest/CMakeLists.txt (line 93)
<https://git.reviewboard.kde.org/r/125999/#comment60580>

I'm curious, does "PRIVATE" really make any difference for an executable?



tests/ECMPoQmToolsTest/CMakeLists.txt (line 97)
<https://git.reviewboard.kde.org/r/125999/#comment60581>

I don't really understand this sentence. "to target" ?


- David Faure


On Nov. 9, 2015, 3:40 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125999/
> ---
> 
> (Updated Nov. 9, 2015, 3:40 p.m.)
> 
> 
> Review request for Extra Cmake Modules.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Multiple ecm_create_qm_loader() with different catalog names would
> overwrite each other's generated files, causing the wrong catalog to be
> loaded at runtime for some targets.
> 
> This puts the catalog name into the generated filename. Since the
> catalog name is the only difference between the generated files, this is
> sufficient to fix the runtime behaviour.
> 
> 
> Diffs
> -
> 
>   modules/ECMPoQmTools.cmake 12bcf6b67c57dd456f078820f86c1e8365cb7c06 
>   tests/ECMPoQmToolsTest/CMakeLists.txt 
> 76d801411b87987ac05de8dd99a0f37266ef6909 
>   tests/ECMPoQmToolsTest/check.cmake.in 
> ab434d2e425ff57f323a196acc60e0e52c0abb10 
>   tests/ECMPoQmToolsTest/check_conf.cmake.in 
> 9ab02e72c4f5aa740c04116e824a54c61fe8bda8 
>   tests/ECMPoQmToolsTest/tr_test-po/de/catalog2.po PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_test-po/en/catalog2.po PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125999/diff/
> 
> 
> Testing
> ---
> 
> Extended unit tests, which pass. Built frameworks and ~100 frameworks-based 
> KDE projects.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126075: Overhaul the ECM build system.

2015-11-22 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126075/#review88688
---

Ship it!


OK, I adapted release-tools/increase_frameworks_version.sh, thanks for the 
heads up.

Patch looks good, as far as I can tell.

- David Faure


On Nov. 15, 2015, 4:17 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126075/
> ---
> 
> (Updated Nov. 15, 2015, 4:17 p.m.)
> 
> 
> Review request for Extra Cmake Modules and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> It should now be easier to read, and more featureful. Among other
> tweaks, we now print a summary of dependencies and build options, and
> the documentation is generated with more sensible breadcrumbs and
> builds properly with Sphinx 1.3.
> 
> 
> Diffs
> -
> 
>   .gitignore PRE-CREATION 
>   CMakeLists.txt c1abd6c7be925dcebd5e9962fa05ae143abdf76b 
>   ECMConfig.cmake.in b163e3ae6e7b0f0f4d4620700a35ac501c6f94f8 
>   cmake/FindQCollectionGenerator.cmake PRE-CREATION 
>   cmake/FindSphinx.cmake PRE-CREATION 
>   docs/CMakeLists.txt f17400f8e96886c8beba45b9c9322960be20ba43 
>   docs/sphinx/conf.py.in 792c87ca1386ef3f7d8d58d6546c81c11d920e2f 
>   docs/sphinx/ecm.py  
>   docs/sphinx/static/ecm.css 2a326d47dda1d74f20aa6d7a65e27ffae26f08c3 
>   tests/CMakeLists.txt 9e6de12f2b82766aa0ab592fb4dff61f09b289e1 
>   tests/ECMGenerateHeadersTest/CMakeLists.txt 
> 9f407cb09064b9a278a74e183a7c2136337729fc 
>   tests/ECMGeneratePkgConfigFile/CMakeLists.txt 
> f3bc267d9ed14881807deebaf8fd11fe6ae6402d 
> 
> Diff: https://git.reviewboard.kde.org/r/126075/diff/
> 
> 
> Testing
> ---
> 
> Configured, built and installed with CMake 2.8.12.2 and with CMake 3.3.
> 
> Tested with various combinations of sphinx-build 1.3.1 (python2 and python3 
> versions) and qcollectiongenerator (Qt4 and Qt5 versions) installed or not.
> 
> All seem to work sensibly.
> 
> Generated HTML documentation checked by eye.
> 
> sphinx-build 1.2.2 (used by api.kde.org) *not* tested.
> 
> Example output:
> 
> -- Found Sphinx: /usr/bin/sphinx-build (found suitable version "1.3.1", 
> minimum required is "1.2") 
> -- Found QCollectionGenerator: /usr/bin/qcollectiongenerator (found 
> version "1.0") 
> -- The C compiler identification is GNU 5.2.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- 
> -- The following features have been enabled:
> 
>  * BUILD_HTML_DOCS , Generate HTML documentation for installed modules.
>  * BUILD_MAN_DOCS , Generate man page documentation for installed modules.
>  * BUILD_QTHELP_DOCS , Generate QtHelp documentation for installed 
> modules.
>  * BUILD_TESTING , Build automated tests.
> 
> -- The following OPTIONAL packages have been found:
> 
>  * Sphinx (required version >= 1.2) , Tool to generate documentation. , 
> <http://sphinx-doc.org/>
>Required to build documentation for Extra CMake Modules.
>  * QCollectionGenerator , Qt help collection generator. , 
> <http://www.qt.io/>
>Required to build Extra CMake Modules documentation in Qt Help format.
>  * Qt5LinguistTools , Qt5 linguist tools. , <http://www.qt.io/>
>Required to run tests for the ECMPoQmTools module.
>  * Qt5Core , Qt5 core library. , <http://www.qt.io/>
>Required to run tests for the ECMQtDeclareLoggingCategory module, and 
> for some tests of the KDEInstallDirs module.
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: 
> /home/kde-devel/src/extra-cmake-modules/build
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126000: Make sure we load translations on the main thread.

2015-11-23 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126000/#review88733
---



modules/ECMQmLoader.cpp.in (line 73)
<https://git.reviewboard.kde.org/r/126000/#comment60838>

"correct" is obvious but not precise. Should say "main" instead.



modules/ECMQmLoader.cpp.in (line 76)
<https://git.reviewboard.kde.org/r/126000/#comment60841>

You could just use invokeMethod + QueuedConnection, no?

Then the whole prose about QEvent types can be removed ;)



tests/ECMPoQmToolsTest/tr_thread_test.cpp (line 27)
<https://git.reviewboard.kde.org/r/126000/#comment60839>

you can easily assert that, like Q_ASSERT(QThread::currentThread() == 
qApp->thread());



tests/ECMPoQmToolsTest/tr_thread_test.cpp (line 32)
<https://git.reviewboard.kde.org/r/126000/#comment60840>

qPrintable(m_lib->errorString()) is slightly shorter.


- David Faure


On Nov. 22, 2015, 12:46 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126000/
> ---
> 
> (Updated Nov. 22, 2015, 12:46 p.m.)
> 
> 
> Review request for Extra Cmake Modules and David Faure.
> 
> 
> Bugs: 346188
> http://bugs.kde.org/show_bug.cgi?id=346188
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Because the old implementation (accidentally) worked when you put the
> ecm_create_qm_loader call in a different CMakeLists.txt file to the
> target the file was added to, some projects did this.
> 
> This won't work with build-time-generated files, though, like moc files.
> So we (ab)use QTimer events to make the loading happen on the main
> thread.
> 
> BUG: 346188
> 
> 
> Diffs
> -
> 
>   modules/ECMPoQmTools.cmake 0af5b12fdd662c07792e6084b7279b98dc99cf97 
>   modules/ECMQmLoader.cpp.in 423d1c932ddcf3d98c94d2f67e73355129357768 
>   tests/ECMPoQmToolsTest/CMakeLists.txt 
> 73d2b4271d646107ce02bb2da71fbe0d11f80fc8 
>   tests/ECMPoQmToolsTest/check.cmake.in 
> 5329b78d06bebb9aa14595201f45ac868afd8e81 
>   tests/ECMPoQmToolsTest/check_conf.cmake.in 
> 7bd11c36e2830e868c83f455e4b2809b72fcb3ce 
>   tests/ECMPoQmToolsTest/tr_thread_test.cpp PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_thread_test_module.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126000/diff/
> 
> 
> Testing
> ---
> 
> Extended unit tests, which pass. Built the world (all the default frameworks 
> stuff) with kdesrc-build.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126000: Make sure we load translations on the main thread.

2015-11-30 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126000/#review88951
---

Ship it!


Ship It!

- David Faure


On Nov. 23, 2015, 9:17 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126000/
> ---
> 
> (Updated Nov. 23, 2015, 9:17 p.m.)
> 
> 
> Review request for Extra Cmake Modules and David Faure.
> 
> 
> Bugs: 346188
> http://bugs.kde.org/show_bug.cgi?id=346188
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Because the old implementation (accidentally) worked when you put the
> ecm_create_qm_loader call in a different CMakeLists.txt file to the
> target the file was added to, some projects did this.
> 
> This won't work with build-time-generated files, though, like moc files.
> So we (ab)use QTimer events to make the loading happen on the main
> thread.
> 
> BUG: 346188
> 
> 
> Diffs
> -
> 
>   modules/ECMPoQmTools.cmake 0af5b12fdd662c07792e6084b7279b98dc99cf97 
>   modules/ECMQmLoader.cpp.in 423d1c932ddcf3d98c94d2f67e73355129357768 
>   tests/ECMPoQmToolsTest/CMakeLists.txt 
> 73d2b4271d646107ce02bb2da71fbe0d11f80fc8 
>   tests/ECMPoQmToolsTest/check.cmake.in 
> 5329b78d06bebb9aa14595201f45ac868afd8e81 
>   tests/ECMPoQmToolsTest/check_conf.cmake.in 
> 7bd11c36e2830e868c83f455e4b2809b72fcb3ce 
>   tests/ECMPoQmToolsTest/tr_thread_test.cpp PRE-CREATION 
>   tests/ECMPoQmToolsTest/tr_thread_test_module.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126000/diff/
> 
> 
> Testing
> ---
> 
> Extended unit tests, which pass. Built the world (all the default frameworks 
> stuff) with kdesrc-build.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

CMP0064 broken?

2015-12-21 Thread David Faure 
KDE4Macros.cmake says
   if (${second_PARAM} STREQUAL "TEST")
which leads to


CMake Warning (dev) at 
/d/kde/inst/kde4.14/share/apps/cmake/modules/KDE4Macros.cmake:775 (if):
  Policy CMP0064 is not set: Support new TEST if() operator.  Run "cmake
  --help-policy CMP0064" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  TEST will be interpreted as an operator when the policy is set to NEW.
  Since the policy is not set the OLD behavior will be used.

I tried changing that to
   if ("${second_PARAM}" STREQUAL "TEST")
but that doesn't help, the warning is still there.

How much more quoting can I do? :-)


Can't set the policy, this is from a file shared between many many projects.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: setting policies centrally (was: cmCMakePolicyCommand: New PARENT_SCOPE argument)

2015-12-22 Thread David Faure 
On Monday 17 August 2015 09:25:01 Brad King wrote:
> 
> So, I think we are back to asking projects to explicitly allow
> an included module to set policies by using NO_POLICY_SCOPE.

As much as I hate that solution, I was about to go ahead and do it, to finally 
fix the warning.

But I must be doing it wrong, it doesn't work?

ECM:

diff --git a/kde-modules/KDECompilerSettings.cmake 
b/kde-modules/KDECompilerSettings.cmake
index 707e5d7..68e007e 100644
--- a/kde-modules/KDECompilerSettings.cmake
+++ b/kde-modules/KDECompilerSettings.cmake
@@ -199,6 +199,7 @@ endif()
 set(CMAKE_C_VISIBILITY_PRESET hidden)
 set(CMAKE_CXX_VISIBILITY_PRESET hidden)
 set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
+set(CMAKE_POLICY_DEFAULT_CMP0063 NEW) # don't let cmake >= 3.3 warn about the 
above
 
 if (UNIX AND NOT APPLE)
 # Enable adding DT_RUNPATH, which means that LD_LIBRARY_PATH takes 
precedence
diff --git a/kde-modules/KDEFrameworkCompilerSettings.cmake 
b/kde-modules/KDEFrameworkCompilerSettings.cmake
index 55ab36c..8726c2a 100644
--- a/kde-modules/KDEFrameworkCompilerSettings.cmake
+++ b/kde-modules/KDEFrameworkCompilerSettings.cmake
@@ -30,7 +30,7 @@
 # (To distribute this file outside of extra-cmake-modules, substitute the full
 #  License text for the above reference.)
 
-include(KDECompilerSettings)
+include(KDECompilerSettings NO_POLICY_SCOPE)
 
 add_definitions(-DQT_NO_CAST_TO_ASCII
 -DQT_NO_CAST_FROM_ASCII

karchive:

index 0d1f96d..a47dc76 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,7 +11,7 @@ feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND 
FATAL_ON_MISSING_REQUIRED_PACKA
 set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR})
 
 include(KDEInstallDirs)
-include(KDEFrameworkCompilerSettings)
+include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE)
 include(KDECMakeSettings)
 

cmake output in karchive:

CMake Warning (dev) at 
/d/kde/inst/kde_frameworks/share/ECM/modules/ECMAddTests.cmake:97 
(add_executable):
  Policy CMP0063 is not set: Honor visibility properties for all target
  types.  Run "cmake --help-policy CMP0063" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target "deprecatedtest" of type "EXECUTABLE" has the following visibility
  properties set for CXX:

CXX_VISIBILITY_PRESET
VISIBILITY_INLINES_HIDDEN

  For compatibility CMake is not honoring them for this target.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: CMP0064 broken?

2015-12-22 Thread David Faure 
On Tuesday 22 December 2015 18:31:52 Matt McCormick wrote:
> Hi David,
> 
> Please try
> 
>   if ("x${second_PARAM}x" STREQUAL "xTESTx")

This looks like it should work, but isn't that an awful workaround?
Are we back to shell/autoconf programming from 1990?

Surely cmake can make the difference between a keyword (TEST)
and a string ("TEST") ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: CMP0064 broken?

2015-12-25 Thread David Faure 
On Wednesday 23 December 2015 12:40:33 Matt McCormick wrote:
> Hi David,
> 
> On Wed, Dec 23, 2015 at 2:17 AM, David Faure  wrote:
> >> Please try
> >>
> >>   if ("x${second_PARAM}x" STREQUAL "xTESTx")
> >
> > This looks like it should work, but isn't that an awful workaround?
> > Are we back to shell/autoconf programming from 1990?
> 
> It is preferable to actually set the policy.

Isn't setting the policy to OLD always considered a bad idea in the long run,
because that means "yes I know I'm using deprecated behaviour which
could go away one day"?
Usually there is a proper way to port to the new behaviour, otherwise
it means the new behaviour is wrong.

That's what I'm asking here, what will be the proper way to test that a
variable contains the string TEST, in 10 years time when CMP0064
no longer exists?

> > Surely cmake can make the difference between a keyword (TEST)
> > and a string ("TEST") ?
> 
> Patches that include tests would be welcome. Note that it will have to
> cover all cases of CMP0054:
> 
>   
> https://cmake.org/cmake/help/v3.4/policy/CMP0054.html?highlight=policy#policy:CMP0054

So you break it, I fix it? Sorry, no, that's your responsibility, not mine.

> PS. Please send these questions on the appropriate mailing list (cmake-users).

I can't exactly subscribe to 50 mailing-lists, days are too short to follow 
every
opensource project in the world.

I thought you might want to know about breakages introduced by your change.
Clearly my feedback isn't welcome, I'm being told to live with it and use awful
workarounds, or to fix it myself. That's not a very satisfactory outcome.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126535: Silence CMP0063 warnings with KDECompilerSettings.

2015-12-28 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126535/#review90214
---

Ship it!


Ship It!

- David Faure


On Dec. 27, 2015, 11:45 a.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126535/
> ---
> 
> (Updated Dec. 27, 2015, 11:45 a.m.)
> 
> 
> Review request for Extra Cmake Modules and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> We recommend including KDE "settings" modules with NO_POLICY_SCOPE, both
> so we can resolve this issue and to allow us to deal with similar things
> in the future.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECMakeSettings.cmake c2786c1a8af8b8f36ecd12b919b5ec8856d6724f 
>   kde-modules/KDECompilerSettings.cmake 
> 73d778255edca3d81ebc2e6b8e67b22896c81fef 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 
> e88c10d9cc6b5de59912e11de43555f056468cb5 
> 
> Diff: https://git.reviewboard.kde.org/r/126535/diff/
> 
> 
> Testing
> ---
> 
> Added NO_POLICY_SCOPE to KArchive's include(KDECompilerSettings), which 
> silenced the CMP0063 warnings.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 126546: Fix CMP0064 warning by setting policy CMP0054 to NEW.

2015-12-28 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126546/
---

Review request for Build System and Alex Merry.


Repository: kdelibs4support


Description
---

This isn't a typo: if CMP0054 is set, then "TEST" is not parsed
as TEST, and the CMP0064 warning doesn't trigger. Or something like that.
cmake isn't getting any simpler.


Diffs
-

  cmake/modules/KDE4Macros.cmake 1c41550eaf79cf908c0e34cef7a6aa36bec56aab 

Diff: https://git.reviewboard.kde.org/r/126546/diff/


Testing
---

Applied the same to kdelibs4 and it fixes the warning when compiling one of my 
kde4-based apps (fatcrm).


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126546: Fix CMP0064 warning by setting policy CMP0054 to NEW.

2015-12-28 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126546/
---

(Updated Dec. 28, 2015, 10:37 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and Alex Merry.


Changes
---

Submitted with commit 628aec760177891e040bb1d6c66958bbdb33e681 by David Faure 
to branch master.


Repository: kdelibs4support


Description
---

This isn't a typo: if CMP0054 is set, then "TEST" is not parsed
as TEST, and the CMP0064 warning doesn't trigger. Or something like that.
cmake isn't getting any simpler.


Diffs
-

  cmake/modules/KDE4Macros.cmake 1c41550eaf79cf908c0e34cef7a6aa36bec56aab 

Diff: https://git.reviewboard.kde.org/r/126546/diff/


Testing
---

Applied the same to kdelibs4 and it fixes the warning when compiling one of my 
kde4-based apps (fatcrm).


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: CMP0064 broken?

2015-12-28 Thread David Faure 
On Saturday 26 December 2015 12:27:26 Matt McCormick wrote:
> So, set CMP0054 to NEW.

Oh, I see. This fixes it indeed, and is a much better fix indeed.
I hadn't realized that setting CMP0054 would fix the CMP00064 warning,
that was not intuitive.

I thought the "set the policy" recommendation was about setting CMP00064,
(and that setting it to NEW wouldn't help since it would still interpret TEST
as a keyword).

I apologize for the tone in my previous email, I was so sure that the new
behaviour was incorrect for some use cases, based on the initial replies.

Thank you for the solution.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

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

2016-01-05 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126648/#review90682
---

Ship it!



src/xslt_kde.cpp (line 17)
<https://git.reviewboard.kde.org/r/126648/#comment61977>

I would suggest to add a qWarning() under this line, to warn at runtime in 
case this is ever called in a non-karchive build.


- David Faure


On Jan. 6, 2016, 12:58 a.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126648/
> ---
> 
> (Updated Jan. 6, 2016, 12:58 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Alex Merry, and David Faure.
> 
> 
> Repository: kdoctools
> 
> 
> Description
> ---
> 
> Most of the code was already prepared to compile without the KArchive 
> dependency (including the MEINPROC_NO_KARCHIVE flag).
> This mode should be only enabled on KDE infrastructure, as the compressed 
> cache (the only added feature coming from KArchive) is not used by the 
> generator of the documentation website.
> A warning is printed when the mode is enabled.
> The saveToCache function is preserved, even if without code, to minimize the 
> changes required.
> 
> 
> Diffs
> -
> 
>   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
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

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

2016-01-07 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126648/#review90735
---

Ship it!


Ship It!

- David Faure


On Jan. 6, 2016, 9:33 p.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126648/
> ---
> 
> (Updated Jan. 6, 2016, 9:33 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Alex Merry, and David Faure.
> 
> 
> Repository: kdoctools
> 
> 
> Description
> ---
> 
> Most of the code was already prepared to compile without the KArchive 
> dependency (including the MEINPROC_NO_KARCHIVE flag).
> This mode should be only enabled on KDE infrastructure, as the compressed 
> cache (the only added feature coming from KArchive) is not used by the 
> generator of the documentation website.
> A warning is printed when the mode is enabled.
> The saveToCache function is preserved, even if without code, to minimize the 
> changes required.
> 
> 
> Diffs
> -
> 
>   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
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126183: Add a FindPoppler module to ECM

2016-01-27 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126183/#review91658
---



This breaks compilation of okular (branch frameworks) for me, I had to patch it 
this way: http://www.davidfaure.fr/2016/fix_okular.diff

- David Faure


On Jan. 13, 2016, 1:55 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126183/
> ---
> 
> (Updated Jan. 13, 2016, 1:55 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Albert Astals Cid and Tobias Koenig.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> At least Okular and KBibTex include a FindPoppler.cmake module but this one
> uses the new ECMFindModuleHelpers and has imported targets.
> 
> ---
> 
> To make FindPoppler.cmake work without pkg-config it also includes this 
> commit:
> 
> 
> Use PATH_SUFFIXES in ecm_find_package_handle_library_components()
> 
> 
> This is required to find poppler without package config as all the headers
> are installed in a poppler subdirectory of the include directory
> 
> 
> Diffs
> -
> 
>   find-modules/FindPoppler.cmake PRE-CREATION 
>   find-modules/FindWayland.cmake c5a56c1635d03acdaf5ccd780b9a358d6f6655fd 
>   modules/ECMFindModuleHelpers.cmake 2044efe1ccf679b738f68aec9b3fb007c449717c 
> 
> Diff: https://git.reviewboard.kde.org/r/126183/diff/
> 
> 
> Testing
> ---
> 
> Okular can be built using this find module with minor changes. As it doesn't 
> set various HAVE_POPPLER_0_36 etc. variables that the find module in okular 
> did, I set those variables in the okular CMakeLists.txt
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-27 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127169/#review92830
---



Nicolás: if the prefixes are different, then this patch doesn't change anything 
(since it compares the prefixes). So it makes sense to me.
Adopt the Qt plugins dir when installing into the same prefix as Qt, keep 
default paths otherwise.
+1

- David Faure


On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 5:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

2016-02-27 Thread David Faure 


> On Feb. 27, 2016, 1:41 p.m., David Faure wrote:
> > Nicolás: if the prefixes are different, then this patch doesn't change 
> > anything (since it compares the prefixes). So it makes sense to me.
> > Adopt the Qt plugins dir when installing into the same prefix as Qt, keep 
> > default paths otherwise.
> > +1

(oops that was a reply to your previous comment, kmail threading didn't put all 
emails together).

Ship it!


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127169/#review92830
---


On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> ---
> 
> (Updated Feb. 24, 2016, 5:09 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca 
> Cintora.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where 
> plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that 
> might be controlled but usually won't.
> 
> In the end, otherwise, people need to keep adapting their systems with 
> environment variables anyway. All distros end up setting always this setting 
> as ON, as well as brave developers who don't have separate prefixes for Qt 
> and KDE.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake ebd48fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 127432: ecm_qt_declare_logging_category: improve error message when using without including

2016-03-20 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127432/
---

Review request for Extra Cmake Modules and Stephen Kelly.


Repository: extra-cmake-modules


Description
---

If one subdir in the project includes this file, all others can use the function
but they don't see the value of the variable, which leads to a strange error

CMake Error at ECM/modules/ECMQtDeclareLoggingCategory.cmake:114 
(configure_file):
  configure_file input location  is a directory but a file was expected.

Happened in KIO, with kio/gui doing include+function call, and then adding
function call in kio/widgets.


Diffs
-

  modules/ECMQtDeclareLoggingCategory.cmake 
3f7bb79a7f4d98c1480f87b1fffc252f4e159add 

Diff: https://git.reviewboard.kde.org/r/127432/diff/


Testing
---

As described in above. Got the better error message after the fix.


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127432: ecm_qt_declare_logging_category: improve error message when using without including

2016-04-03 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127432/
---

(Updated April 3, 2016, 8:42 p.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules and Stephen Kelly.


Changes
---

Submitted with commit f7c1e8d57f84d0883a2a7683fd59ecc990a03de1 by David Faure 
to branch master.


Repository: extra-cmake-modules


Description
---

If one subdir in the project includes this file, all others can use the function
but they don't see the value of the variable, which leads to a strange error

CMake Error at ECM/modules/ECMQtDeclareLoggingCategory.cmake:114 
(configure_file):
  configure_file input location  is a directory but a file was expected.

Happened in KIO, with kio/gui doing include+function call, and then adding
function call in kio/widgets.


Diffs
-

  modules/ECMQtDeclareLoggingCategory.cmake 
3f7bb79a7f4d98c1480f87b1fffc252f4e159add 

Diff: https://git.reviewboard.kde.org/r/127432/diff/


Testing
---

As described in above. Got the better error message after the fix.


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127432: ecm_qt_declare_logging_category: improve error message when using without including

2016-04-03 Thread David Faure 


> On March 20, 2016, 6:44 p.m., Stephen Kelly wrote:
> > I filed 
> > 
> >  http://public.kitware.com/Bug/view.php?id=16026
> >  
> > and I also reviewed the module as a whole. Then I submitted
> > 
> >  https://git.reviewboard.kde.org/r/127440/
> >  
> > The 
> > 
> >  string(FIND "${ARG_HEADER}" "." pos REVERSE)
> >  
> > stuff in this module is odd. It should use get_filename_component(NAME_WE) 
> > probably.

Thanks for the cmake bug report, I 100% agree with it :-)


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127432/#review93801
---


On April 3, 2016, 8:42 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127432/
> ---
> 
> (Updated April 3, 2016, 8:42 p.m.)
> 
> 
> Review request for Extra Cmake Modules and Stephen Kelly.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> If one subdir in the project includes this file, all others can use the 
> function
> but they don't see the value of the variable, which leads to a strange error
> 
> CMake Error at ECM/modules/ECMQtDeclareLoggingCategory.cmake:114 
> (configure_file):
>   configure_file input location  is a directory but a file was 
> expected.
> 
> Happened in KIO, with kio/gui doing include+function call, and then adding
> function call in kio/widgets.
> 
> 
> Diffs
> -
> 
>   modules/ECMQtDeclareLoggingCategory.cmake 
> 3f7bb79a7f4d98c1480f87b1fffc252f4e159add 
> 
> Diff: https://git.reviewboard.kde.org/r/127432/diff/
> 
> 
> Testing
> ---
> 
> As described in above. Got the better error message after the fix.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: How is KF5 packaged on major systems?

2016-04-23 Thread David Faure 
Shaheed !!!
Long time no see ;)

On Wednesday 20 April 2016 19:48:30 Shaheed Haque wrote:
> The whole point of what I am doing is to automate as much as possible
> of steps 1-4, and this question centres on step 4. How can I automate
> identifying the correct KF5 library .so file? For example, on my
> Ubuntu Wily system, I can start with the header files in
> "/usr/include/KF5/KItemModels/*.h" and then I need to link against
> "libKF5ItemModels.so".

Well, we tried to keep things rather consistent, so maybe just a few rules are 
necessary.

Just keep in mind that a single framework can install multiple libs (e.g. kio 
installs 5 of them).

(and that there are two kinds of forwarding headers (namespaced and 
non-namespaced),
but if you only parse the real lowercase headers and not the forwarding headers 
then
this doesn't matter)

But with that in mind, it should be straightforward.
E.g. include/KF5/KIOWidgets/* maps to libKF5KIOWidgets.so

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 127910: kdesrc-build: improve error messages by showing the right filename

2016-05-13 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127910/
---

Review request for Build System and Michael Pyne.


Repository: kdesrc-build


Description
---

Before:
"Don't use module libaccounts-qt on line 20 of /path/kdesrc-buildrc, use 
options libaccounts-qt"
 but line 20 is unrelated, some global option.

After:
"Don't use module libaccounts-qt on line 20 of 
/path/extragear/utils/kdesrc-build/kf5-workspace-build-include, use options 
libaccounts-qt"


Diffs
-

  modules/ksb/Application.pm b5bab5a6eb24cba488572dbdbdbabd024db8dc91 
  modules/ksb/RecursiveFH.pm 6892320bb5e8f8c1e4979ef137bb975775940908 

Diff: https://git.reviewboard.kde.org/r/127910/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127910: kdesrc-build: improve error messages by showing the right filename

2016-05-13 Thread David Faure 


> On May 14, 2016, 2:56 a.m., Michael Pyne wrote:
> > modules/ksb/RecursiveFH.pm, line 16
> > <https://git.reviewboard.kde.org/r/127910/diff/1/?file=464729#file464729line16>
> >
> > I think I would add a comment here to the effect that we don't maintain 
> > a full stack for current_file since we only need current_file when writing 
> > out error messages. It will help future me avoid some confusion that I 
> > worked through just now. ;)

Wait, you're right, what if we follow an include file, then come back to the 
main file, and there's an error in a line there?
My code would show the name of the included file rather than the one of the 
main file. I think you're right, we do need a stack, don't we?


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127910/#review95456
-------


On May 13, 2016, 7:36 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127910/
> ---
> 
> (Updated May 13, 2016, 7:36 p.m.)
> 
> 
> Review request for Build System and Michael Pyne.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> Before:
> "Don't use module libaccounts-qt on line 20 of /path/kdesrc-buildrc, use 
> options libaccounts-qt"
>  but line 20 is unrelated, some global option.
> 
> After:
> "Don't use module libaccounts-qt on line 20 of 
> /path/extragear/utils/kdesrc-build/kf5-workspace-build-include, use options 
> libaccounts-qt"
> 
> 
> Diffs
> -
> 
>   modules/ksb/Application.pm b5bab5a6eb24cba488572dbdbdbabd024db8dc91 
>   modules/ksb/RecursiveFH.pm 6892320bb5e8f8c1e4979ef137bb975775940908 
> 
> Diff: https://git.reviewboard.kde.org/r/127910/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127910: kdesrc-build: improve error messages by showing the right filename

2016-05-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127910/
---

(Updated May 15, 2016, 12:56 p.m.)


Review request for Build System and Michael Pyne.


Changes
---

Use a stack of filenames. Not exactly the solution you had in mind, but the 
"basepath" stuff could be refactored to use this new stack if wanted, 
pushBasePath being internal.


Repository: kdesrc-build


Description
---

Before:
"Don't use module libaccounts-qt on line 20 of /path/kdesrc-buildrc, use 
options libaccounts-qt"
 but line 20 is unrelated, some global option.

After:
"Don't use module libaccounts-qt on line 20 of 
/path/extragear/utils/kdesrc-build/kf5-workspace-build-include, use options 
libaccounts-qt"


Diffs (updated)
-

  modules/ksb/Application.pm 5dbd224c7ba06242b53cd77cfa0764c28da76579 
  modules/ksb/RecursiveFH.pm 6892320bb5e8f8c1e4979ef137bb975775940908 

Diff: https://git.reviewboard.kde.org/r/127910/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127910: kdesrc-build: improve error messages by showing the right filename

2016-05-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127910/
---

(Updated May 15, 2016, 12:59 p.m.)


Review request for Build System and Michael Pyne.


Changes
---

fix syntax issue in warning statement


Repository: kdesrc-build


Description
---

Before:
"Don't use module libaccounts-qt on line 20 of /path/kdesrc-buildrc, use 
options libaccounts-qt"
 but line 20 is unrelated, some global option.

After:
"Don't use module libaccounts-qt on line 20 of 
/path/extragear/utils/kdesrc-build/kf5-workspace-build-include, use options 
libaccounts-qt"


Diffs (updated)
-

  modules/ksb/Application.pm 5dbd224c7ba06242b53cd77cfa0764c28da76579 
  modules/ksb/RecursiveFH.pm 6892320bb5e8f8c1e4979ef137bb975775940908 

Diff: https://git.reviewboard.kde.org/r/127910/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 127910: kdesrc-build: improve error messages by showing the right filename

2016-05-15 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127910/
---

(Updated May 15, 2016, 10:37 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and Michael Pyne.


Changes
---

Submitted with commit 7cdbc4e0b1975bb150eabb6a82e3de142b1e1260 by David Faure 
to branch master.


Repository: kdesrc-build


Description
---

Before:
"Don't use module libaccounts-qt on line 20 of /path/kdesrc-buildrc, use 
options libaccounts-qt"
 but line 20 is unrelated, some global option.

After:
"Don't use module libaccounts-qt on line 20 of 
/path/extragear/utils/kdesrc-build/kf5-workspace-build-include, use options 
libaccounts-qt"


Diffs
-

  modules/ksb/Application.pm 5dbd224c7ba06242b53cd77cfa0764c28da76579 
  modules/ksb/RecursiveFH.pm 6892320bb5e8f8c1e4979ef137bb975775940908 

Diff: https://git.reviewboard.kde.org/r/127910/diff/


Testing
---


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

cmake forces c++11 on an app that needs c++14

2016-06-04 Thread David Faure 
Symptom: zanshin doesn't compile with Qt 5.7 and cmake from "release" branch,
error is "std::make_unique not found".

Reason: zanshin wants -std=c++14, but gets a compile line like this:
-std=c++0x [...] -std=c++14 [...] -std=gnu++11
so in the end only C++11 is enabled, not C++14.

In order to enable C++14, Zanshin does this:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")

Linking to Qt5::Core brings the -std=c++0x but that's fine it's before the 
other flags.

cmake itself however adds -std=gnu+11.
An ugly workaround is to do
   set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION "-std=c++14")
I looked into the "cmake-compile-features" mechanism, but that's only about 
language features, while zanshin only needs c++14 for a newer feature in the 
standard library (the fact that  provides std::make_unique).
I could hack it by picking a language feature and saying that zanshin requires 
that, but that's still a workaround.

Doesn't cmake have a better solution for this?

(For instance not adding -std=gnu+11 if the flags already contain -std=c++14?
Or providing a way to "force" c++14, without the indirection of required 
language features?)

PS: the above analysis is mostly deduced from grepping; it seems logical to 
me, but what's strange is that it only started happening when switching to Qt 
5.7... I don't understand why.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: cmake forces c++11 on an app that needs c++14

2016-06-10 Thread David Faure 
On dimanche 5 juin 2016 11:27:48 CEST Stephen Kelly wrote:
> On 06/04/2016 11:03 AM, David Faure wrote:
> > Symptom: zanshin doesn't compile with Qt 5.7 and cmake from "release"
> > branch, error is "std::make_unique not found".
> > 
> > Reason: zanshin wants -std=c++14, but gets a compile line like this:
> > -std=c++0x [...] -std=c++14 [...] -std=gnu++11
> > so in the end only C++11 is enabled, not C++14.
> > 
> > In order to enable C++14, Zanshin does this:
> > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")
> 
> This is likely:
> 
>  https://bugreports.qt.io/browse/QTBUG-53002
> 
> I don't know where the -std=c++0x comes from in your compile line
> (something in ECM?)

Indeed.

kde-modules/KDECompilerSettings.cmake:set(CMAKE_CXX_FLAGS "$
{CMAKE_CXX_FLAGS} -std=c++0x")

Should we only do this if cmake < 3.1 ?

> You probably want
> 
>  set(CMAKE_CXX_STANDARD 14)
> 
> in Zanshin. 

Works. Thanks, pushed.

> I don't know if the use of -std=c++11 instead of
> -std=gnu++11 is deliberate (usually it is not, but the internet got in
> the habit of recommending -std=c++11), but if it is, then you
> additionally want to disable gnu extensions with
> 
>  set(CMAKE_CXX_EXTENSIONS OFF)

No opinion. Kévin, I'll let you decide on that part.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 128232: The default level for logging categories should be Info rather than Warning.

2016-06-17 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128232/
---

Review request for Extra Cmake Modules and David Edmundson.


Repository: extra-cmake-modules


Description
---

The whole point of Info is to be used by apps who want to print out some
info for the user, not disabled by default.

Example use case: ksmserver could output the name of the autostart
files it's starting, so user can check their own scripts are started,
and associate any errors with the corresponding script.

In other words:
Debug = debugging for the developer
Info = debugging for the user :-)

This commit shows the benefit of having a central place for changing this
(many category definitions do not use this macro though)


Diffs
-

  modules/ECMQtDeclareLoggingCategory.cmake 
c125949a46c4b83544413f23d5e04b2d8ea2c4cf 

Diff: https://git.reviewboard.kde.org/r/128232/diff/


Testing
---

The autotests still pass -- somewhat to my surprise ;-)


Thanks,

David Faure

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Adding Python bindings for some frameworks in the next release

2016-06-25 Thread David Faure 
On dimanche 19 juin 2016 21:29:37 CEST Stephen Kelly wrote:
> Hi,
> 
> I would like to add the python bindings previously discussed to the next
> release of KF5.  This means adding the four most recent commits from
> 
>  https://github.com/steveire/extra-cmake-modules/commits/python-bindings
> 
> to ECM and generating the bindings for KItemModels and KGuiAddons,
> KDbusAddons.
> 
> I chose these three because they do not require non-default 'rules' files
> for the bindings. Eg:
> 
>  https://github.com/steveire/kitemmodels/commit/98bf569340a5a5049711e087429d
> 080708deb7b8

OK. Just one question: will this fail silently (as it should IMHO) when python 
is not available (e.g. on Windows) ?

> This way we can iron out any distribution related problems in the approach,
> then extend the system to further frameworks.

Doing things incrementally is a good idea indeed.

But you should try a "namespaced framework", their header installation is 
quite different. There's plenty to choose from, see
`grep -w '^ *PREFIX' **/CMakeLists.txt`  (zsh)
Maybe pick Attica for a simple one (simpler than KIO).

> Unfortunately this can not yet be CI tested:
> 
>  https://phabricator.kde.org/T2389
> 
> but there are unit tests in the ECM repo for this system.
> 
> Any objections?

No objections -- but I'm not very good at reviewing ECM code, or worse, python 
:-).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128231: Set slightly more unique header guard for logging categories

2016-06-28 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128231/#review96904
---



Isn't it much more common to name the guard after the header filename?

- David Faure


On June 20, 2016, 10:11 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128231/
> ---
> 
> (Updated June 20, 2016, 10:11 a.m.)
> 
> 
> Review request for Extra Cmake Modules.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> The default generated guard is based on _H . It's not
> unreasnoble to have another header file in the same project with the
> same name as the category name and thus same guard name.
> 
> 
> Diffs
> -
> 
>   modules/ECMQtDeclareLoggingCategory.cmake 
> c125949a46c4b83544413f23d5e04b2d8ea2c4cf 
> 
> Diff: https://git.reviewboard.kde.org/r/128231/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128427: Make sure ECMGeneratePriFile.cmake behaves like the rest of ECM

2016-07-16 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128427/#review97471
---


Ship it!




Ship It!

- David Faure


On July 12, 2016, 12:21 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128427/
> ---
> 
> (Updated July 12, 2016, 12:21 a.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Antonio Rojas.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> In `KDEInstallDirs` we have some code to make sure that qmake is asked when 
> the project shares the prefix with the installed Qt, to make sure that if 
> something was changed in the distribution it would reflect on the projects.
> Make sure PRI files are installed using the same reasoning.
> 
> 
> Diffs
> -
> 
>   modules/ECMGeneratePriFile.cmake af4b877 
> 
> Diff: https://git.reviewboard.kde.org/r/128427/diff/
> 
> 
> Testing
> ---
> 
> The issue was reported by `arojas`, I haven't been able to reproduce myself.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128427: Make sure ECMGeneratePriFile.cmake behaves like the rest of ECM

2016-07-19 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128427/#review97600
---



This seems to break when used with Qt4.
https://build.kde.org/job/extra-cmake-modules%20master%20latest-qt4/16/PLATFORM=Linux,compiler=gcc/console

Failed call: qmake-qt5 -query "QT_INSTALL_PREFIX"

(it is likely that this error was already happening with the other piece of 
code querying qmake the same way, this build has been yellow for some time)

- David Faure


On July 18, 2016, 1:08 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128427/
> ---
> 
> (Updated July 18, 2016, 1:08 p.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and Antonio Rojas.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> In `KDEInstallDirs` we have some code to make sure that qmake is asked when 
> the project shares the prefix with the installed Qt, to make sure that if 
> something was changed in the distribution it would reflect on the projects.
> Make sure PRI files are installed using the same reasoning.
> 
> 
> Diffs
> -
> 
>   modules/ECMGeneratePriFile.cmake af4b877 
> 
> Diff: https://git.reviewboard.kde.org/r/128427/diff/
> 
> 
> Testing
> ---
> 
> The issue was reported by `arojas`, I haven't been able to reproduce myself.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128488: Add a fallback method for query_qmake() when there's no Qt5 installation

2016-07-21 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128488/#review97710
---




modules/ECMQueryQmake.cmake (line 14)
<https://git.reviewboard.kde.org/r/128488/#comment65832>

If query_qmake isn't public API, it's not what the cmakelists.txt is 
calling. So it looks like an internal error message surfacing up to the user.
What should the user do when hitting this warning? (put qt5 qmake in PATH, 
right?). => I'd remove the mention of query_qmake() in the warning and explain 
more precisely what to do instead.

And what should a developer do if they want to use ECM for qt4? (not use 
this file, I suppose, but if that file is used elsewhere in ECM, it's not 
really a choice, is it?)


- David Faure


On July 20, 2016, 8:42 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128488/
> ---
> 
> (Updated July 20, 2016, 8:42 a.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Addresses its usage on systems where Qt5 isn't installed, it allows for 
> modules using it to decide what they should do.
> 
> 
> Diffs
> -
> 
>   modules/ECMQueryQmake.cmake 8f4cf17 
> 
> Diff: https://git.reviewboard.kde.org/r/128488/diff/
> 
> 
> Testing
> ---
> 
> Should fix this issue: 
> https://build.kde.org/job/extra-cmake-modules%20master%20latest-qt4/16/PLATFORM=Linux,compiler=gcc/console
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128488: Add a fallback method for query_qmake() when there's no Qt5 installation

2016-07-26 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128488/#review97851
---


Ship it!




Ship It!

- David Faure


On July 26, 2016, 12:12 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128488/
> ---
> 
> (Updated July 26, 2016, 12:12 a.m.)
> 
> 
> Review request for Extra Cmake Modules, KDE Frameworks and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Addresses its usage on systems where Qt5 isn't installed, it allows for 
> modules using it to decide what they should do.
> 
> 
> Diffs
> -
> 
>   modules/ECMQueryQmake.cmake 8f4cf17 
> 
> Diff: https://git.reviewboard.kde.org/r/128488/diff/
> 
> 
> Testing
> ---
> 
> Should fix this issue: 
> https://build.kde.org/job/extra-cmake-modules%20master%20latest-qt4/16/PLATFORM=Linux,compiler=gcc/console
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128543: Adds libkipi and kipi-plugins for kdegraphics

2016-08-01 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128543/#review97967
---


Ship it!




Yes please add any module that builds with kf5/qt5.

Otherwise they will not even appear on lxr.kde.org...

- David Faure


On July 28, 2016, 4:46 p.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128543/
> ---
> 
> (Updated July 28, 2016, 4:46 p.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> This is really userfull and needed for the plugins on gwenview.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> 
> Diffs
> -
> 
>   kf5-applications-build-include cd92434e38d0d5af7bfe970cb0d725ff778a3c5f 
> 
> Diff: https://git.reviewboard.kde.org/r/128543/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 128533: Create a test that validates projects' appstream information

2016-08-06 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128533/#review98152
---



The test fails in CI (and locally for me), please fix ;)

https://build.kde.org/view/Frameworks%20kf5-qt5/job/kpackage%20master%20kf5-qt5/88/PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/testfallbackpackage_appstream/

http://ci-logs.kde.flaska.net/1f/1fdab49485172a5693ecddf48d7640c481e23298/rebuilddep/rebuilddep-kf5-qt57-clang-el7/531a3ae/shell_output.log

Locally: diff -bB 
/kpackage/autotests/data/testfallbackpackage/testfallbackpackage.appdata.xml
 /kpackage/autotests/testfallbackpackage.appdata.xml
shows that the latter has many more translations, and uses en_GB while the 
former uses en-GB. 
http://www.davidfaure.fr/2016/testfallbackpackage.appdata.diff.txt

To compare XML files, what I did in kdsoap is to put them both into 
QDomDocument and then use toString(), and then compare. It even allows showing 
the actual line of the first difference (while the technique used here only 
shows "files differ"). You can reuse that code, it's LGPL: xmlBufferCompare() 
at https://github.com/KDAB/KDSoap/blob/master/testtools/httpserver_p.cpp
This would help with any sort of formatting issue (indentation, casing of 
"utf-8" etc), but obviously not with the different amount of translations, 
you'd need to remove the translations from the DOM tree first.

- David Faure


On Aug. 4, 2016, 11:03 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128533/
> ---
> 
> (Updated Aug. 4, 2016, 11:03 a.m.)
> 
> 
> Review request for Build System, Extra Cmake Modules, KDE Frameworks, 
> Matthias Klumpp, Scarlett Clark, and Harald Sitter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> At the moment, we're validating it in build.kde.org, but I feel it will be 
> easier for developers to test if we do so locally.
> This patch does it by seeing which `*.appdata.xml` files are being installed 
> and validating them. This way we can keep it generic for all KDE projects.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECMakeSettings.cmake dd37e7f 
>   kde-modules/appstreamtest.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/128533/diff/
> 
> 
> Testing
> ---
> 
> Tested on some projects, locally.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

Re: Review Request 126422: Allow to override the share install dir

2016-08-12 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126422/#review98322
---



Please use the extra-cmake-modules variables like KDE_INSTALL_DBUSDIR and 
KDE_INSTALL_DBUSINTERFACEDIR instead.

Hmm, cagibi hasn't been ported to Qt5/KF5/ECM?

- David Faure


On Feb. 7, 2016, 9:32 p.m., Niels Ole Salscheider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126422/
> ---
> 
> (Updated Feb. 7, 2016, 9:32 p.m.)
> 
> 
> Review request for Build System, Cagibi, David Faure, and Friedrich W. H. 
> Kossebau.
> 
> 
> Repository: cagibi
> 
> 
> Description
> ---
> 
> This is needed for multiarch layouts where the prefix is /usr/${host} but 
> where arch-independet files are installed to /usr/share.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt dac5ba5 
>   daemon/CMakeLists.txt 2c7b115 
> 
> Diff: https://git.reviewboard.kde.org/r/126422/diff/
> 
> 
> Testing
> ---
> 
> It still builds and installs the files to the correct location.
> 
> 
> Thanks,
> 
> Niels Ole Salscheider
> 
>

Re: Review Request 128714: Kexi needs breeze-icons as a binary resource.

2016-08-24 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128714/#review98586
---




kf5-frameworks-build-include (line 76)
<https://git.reviewboard.kde.org/r/128714/#comment66410>

The module breeze-icons is already defined here, no need to define it 
again. Please just use 

options breeze-icons
   cmake-options ...
end options


- David Faure


On Aug. 19, 2016, 2:02 p.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128714/
> ---
> 
> (Updated Aug. 19, 2016, 2:02 p.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> This patch fixes the configuration step of kexi, that
> needs breeze-icons, but as a binary resource.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> 
> Diffs
> -
> 
>   kf5-frameworks-build-include e684b0def9bb93370c82365e6c42827bb7297e69 
> 
> Diff: https://git.reviewboard.kde.org/r/128714/diff/
> 
> 
> Testing
> ---
> 
> Compiled kexi, that used to fail. now it compiles.
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

Re: Review Request 128232: The default level for logging categories should be Info rather than Warning.

2016-09-02 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128232/
---

(Updated Sept. 2, 2016, 2:36 p.m.)


Status
--

This change has been marked as submitted.


Review request for Extra Cmake Modules, KDE Frameworks and David Edmundson.


Changes
---

Submitted with commit 413eb26f5d9e7a7f174509f8a16d057d5c0e6578 by David Faure 
to branch master.


Repository: extra-cmake-modules


Description
---

The whole point of Info is to be used by apps who want to print out some
info for the user, not disabled by default.

Example use case: ksmserver could output the name of the autostart
files it's starting, so user can check their own scripts are started,
and associate any errors with the corresponding script.

In other words:
Debug = debugging for the developer
Info = debugging for the user :-)

This commit shows the benefit of having a central place for changing this
(many category definitions do not use this macro though)


Diffs
-

  modules/ECMQtDeclareLoggingCategory.cmake 
c125949a46c4b83544413f23d5e04b2d8ea2c4cf 

Diff: https://git.reviewboard.kde.org/r/128232/diff/


Testing
---

The autotests still pass -- somewhat to my surprise ;-)


Thanks,

David Faure

Re: Review Request 129117: Adds KF5Purpose and Kirigami to the default build

2016-10-22 Thread David Faure 


> On Oct. 15, 2016, 8:51 p.m., Michael Pyne wrote:
> > kf5-applications-build-include, line 26
> > 
> >
> > If the idea is to build everything in kdegraphics then it is probably 
> > better to replace all of these sub-modules with something like `use-modules 
> > kde/kdegraphics`.
> > 
> > The `kde/` is itself redundant and unnecessary, that's just an effort 
> > to make it clear it's not simply a single repository name.

Michael: my goal was to have a way to build *everything* that is KF5/Qt5 ready. 
This does mean adding each and every module into a file somewhere, although of 
course people don't have to include these files. My idea was, one file per 
"product", so people can grab "all of frameworks" or "all of plasma" or "all 
apps", and if they want a subset they can just copy/paste that subset they want 
to compile into their own file. Defining instead what is "essential" and what 
is not sounds like a very fuzzy topic, subject to endless debates.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129117/#review100026
---


On Oct. 10, 2016, 10:07 a.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129117/
> ---
> 
> (Updated Oct. 10, 2016, 10:07 a.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> Kirigami is now needed to run discover, so it should be build
> Purpose is needed by at least kamoso.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> Add Kamoso to the buildsystem.
> 
> Kamoso was missing from kdegraphics.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> 
> Diffs
> -
> 
>   kf5-applications-build-include f53c0233ba46322829076db3437cf9c62a65ff8e 
>   kf5-frameworks-build-include a88498e3248262d2e1fddacd726e1ef06a3ac1e4 
> 
> Diff: https://git.reviewboard.kde.org/r/129117/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

Re: Review Request 129117: Adds KF5Purpose and Kirigami to the default build

2016-11-05 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129117/#review100589
---


Ship it!




Ship It!

- David Faure


On Oct. 10, 2016, 10:07 a.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129117/
> ---
> 
> (Updated Oct. 10, 2016, 10:07 a.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> Kirigami is now needed to run discover, so it should be build
> Purpose is needed by at least kamoso.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> Add Kamoso to the buildsystem.
> 
> Kamoso was missing from kdegraphics.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> 
> Diffs
> -
> 
>   kf5-applications-build-include f53c0233ba46322829076db3437cf9c62a65ff8e 
>   kf5-frameworks-build-include a88498e3248262d2e1fddacd726e1ef06a3ac1e4 
> 
> Diff: https://git.reviewboard.kde.org/r/129117/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

Re: Review Request 128112: New module: ecm_win_resolve_symlinks

2016-11-05 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128112/#review100590
---


Fix it, then Ship it!





modules/ECMWinResolveSymlinks.cmake (line 21)
<https://git.reviewboard.kde.org/r/128112/#comment67524>

needs to be updated


- David Faure


On June 17, 2016, 8:32 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128112/
> ---
> 
> (Updated June 17, 2016, 8:32 a.m.)
> 
> 
> Review request for Extra Cmake Modules and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> When git is checking out repositories with UNIX symbolic links inside on 
> Windows machine, it writes them as plain text files, containing relative path 
> to the real file. This is the case for breeze-icons framework, for instance, 
> and this breaks some icons that are symlinked.
> 
> This macro is intended to fix that. There is some room for performance 
> improvement, but i wanted to get the feedback early.
> 
> 
> Diffs
> -
> 
>   modules/ECMWinResolveSymlinks.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/128112/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

Re: Review Request 128806: Make KDECMakeSettings work with KDE_INSTALL_DIRS_NO_DEPRECATED

2016-11-05 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128806/#review100591
---


Ship it!




Looks good to me. The flaw you mention seems to me like a feature. If someone 
uses GNUInstallDirs to define LIB_INSTALL_DIR, then that should be used, 
certainly. If someone uses both GNUInstallDirs and 
KDEInstallDirs+NO_DEPRECATED, then that someone is asking for trouble in any 
case, but obeying the more standard GNUInstallDirs doesn't seem like a bad 
thing to me.

- David Faure


On Aug. 31, 2016, 12:56 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128806/
> ---
> 
> (Updated Aug. 31, 2016, 12:56 a.m.)
> 
> 
> Review request for Extra Cmake Modules.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> The RPATH handling part of KDECMakeSettings.cmake relies on the var 
> LIB_INSTALL_DIR,
> expecting to be used very often in combination with the KDEInstallDirs module 
> which defines it,
> with the simple two-liner
> ```
> include(KDEInstallDirs)
> include(KDECMakeSettings)
> ```
> Though the variable LIB_INSTALL_DIR is one of the vars which is deprecated by 
> the KDEInstallDirs module,
> in favour of the namespaced KDE_INSTALL_LIBDIR.
> And when using the KDE_INSTALL_DIRS_NO_DEPRECATED setting, to no longer have 
> deprecated vars like LIB_INSTALL_DIR set (e.g. when integrating a 
> non-ECM-CMake build subproject where the vars are conflicting), the nice 
> cooperation between the two modules fails flat with a FATAL_ERROR. 
> 
> Which is annoying and should be fixed.
> 
> Existing 3rd-party code which might rely on LIB_INSTALL_DIR needs to be kept 
> working. So LIB_INSTALL_DIR needs
> to be interpreted as before if existing. But if not existing, I propose to 
> add the new official var KDE_INSTALL_LIBDIR
> to be used as fallback in KDECMakeSettings. That would unbreak the module 
> cooperation on KDE_INSTALL_DIRS_NO_DEPRECATED.
> 
> Just, there is the small flaw that something else might be injecting 
> LIB_INSTALL_DIR still,
> when otherwise KDE_INSTALL_DIRS_NO_DEPRECATED is set. Should we care about 
> that?
> Any idea how and when best to deprecate using LIB_INSTALL_DIR with 
> KDECMakeSettings?
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECMakeSettings.cmake 46fd10a 
> 
> Diff: https://git.reviewboard.kde.org/r/128806/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

extra-cmake-modules and FindPythonModuleGeneration

2016-11-05 Thread David Faure 
Problem 1: "make test" now requires cmake 3.3, which the CI doesn't have (it 
has 3.2.2)
https://build.kde.org/view/Frameworks%20kf5-qt5/job/extra-cmake-modules%20master%20kf5-qt5/36/PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/GenerateSipBindings/
What is required, from cmake 3.3?

Problem 2: on my own machine I get "Could not find libclang version 3.8"
even though I have /usr/lib64/libclang.so pointing to libclang.so.3.8

The problem is that FindPythonModuleGeneration.cmake says
   find_library(libclang_LIBRARY clang-3.${_LIBCLANG3_FIND_VERSION})
so it's expecting a libclang-3.8.so ? That's not the way it appears to be named 
on OpenSUSE.

I tried to fix that with (before the rest of the libclang-related code)
+if (NOT libclang_LIBRARY)
+  find_library(libclang_LIBRARY clang)
+endif()
and that works, but of course no version checks there.
Still, can I commit that?

Problem 3: It requires PyQt.
Can we make "make test" skip the test, rather than fail, if PyQt
isn't installed? Maybe like in the attached patch?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
diff --git i/tests/CMakeLists.txt w/tests/CMakeLists.txt
index 53008e1..755b0f0 100644
--- i/tests/CMakeLists.txt
+++ w/tests/CMakeLists.txt
@@ -81,21 +81,31 @@ endmacro()
 
 list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/find-modules)
 
-find_package(PythonModuleGeneration)
-
-foreach(pyversion 2 3)
-  if (GPB_PYTHON${pyversion}_COMMAND)
-if (pythonCommands)
-  list(APPEND pythonCommands " && ")
-endif()
-set(pythonCommands
-  ${GPB_PYTHON${pyversion}_COMMAND}
-  "${CMAKE_CURRENT_SOURCE_DIR}/GenerateSipBindings/testscript.py"
-  "${CMAKE_CURRENT_BINARY_DIR}/GenerateSipBindings/py${pyversion}"
-)
-  endif()
-endforeach()
-add_test_macro(GenerateSipBindings ${pythonCommands})
+# Skip if PyQt not available
+find_file(SIP_Qt5Core_Mod_FILE
+NAMES QtCoremod.sip
+PATH_SUFFIXES share/sip/PyQt5/QtCore
+)
+
+if(NOT SIP_Qt5Core_Mod_FILE)
+message(STATUS "WARNING: skipping tests that require PyQt")
+else()
+find_package(PythonModuleGeneration)
+
+foreach(pyversion 2 3)
+if (GPB_PYTHON${pyversion}_COMMAND)
+if (pythonCommands)
+list(APPEND pythonCommands " && ")
+endif()
+set(pythonCommands
+${GPB_PYTHON${pyversion}_COMMAND}
+"${CMAKE_CURRENT_SOURCE_DIR}/GenerateSipBindings/testscript.py"
+"${CMAKE_CURRENT_BINARY_DIR}/GenerateSipBindings/py${pyversion}"
+)
+   endif()
+   endforeach()
+   add_test_macro(GenerateSipBindings ${pythonCommands})
+endif()
 
 add_test_macro(ExecuteCoreModules dummy)
 add_test_macro(ExecuteKDEModules dummy)

Re: Review Request 129117: Adds KF5Purpose and Kirigami to the default build

2016-12-03 Thread David Faure 


> On Nov. 5, 2016, 9:14 a.m., David Faure wrote:
> > Ship It!

I withdraw my approval. Please revert.
I just noticed that these modules have been added for the "frameworks" 
module-set. This doesn't make sense, they are not part of frameworks. When I 
type "kdesrc-build frameworks" I expect that only the real KF5 modules will be 
built.

purpose is in playground/libs. If it's needed by kamoso, then it should be 
moved to extragear/libs and added to kf5-extragear-build-include. Follow the 
review process for this to happen.

kirigami is in extragear/libs. If it's required by discover, it should be moved 
to kde/workspace, and then it can be added in kf5-workspace-build-include (ask 
the plasma people if they agree, then file a sysadmin request for the move). If 
it's also needed by applications, then it needs to be turned into a proper 
framework.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129117/#review100589
---


On Nov. 7, 2016, 9:39 a.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129117/
> ---
> 
> (Updated Nov. 7, 2016, 9:39 a.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> Kirigami is now needed to run discover, so it should be build
> Purpose is needed by at least kamoso.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> Add Kamoso to the buildsystem.
> 
> Kamoso was missing from kdegraphics.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> 
> Diffs
> -
> 
>   kf5-applications-build-include f53c0233ba46322829076db3437cf9c62a65ff8e 
>   kf5-frameworks-build-include a88498e3248262d2e1fddacd726e1ef06a3ac1e4 
> 
> Diff: https://git.reviewboard.kde.org/r/129117/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

Re: Review Request 129708: C project also need Clang Sanitizer

2016-12-27 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129708/#review101590
---


Ship it!




Ship It!

- David Faure


On Dec. 27, 2016, 6:44 a.m., Leslie Zhai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129708/
> ---
> 
> (Updated Dec. 27, 2016, 6:44 a.m.)
> 
> 
> Review request for Extra Cmake Modules and Alex Merry.
> 
> 
> Bugs: 374195
> http://bugs.kde.org/show_bug.cgi?id=374195
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> So I just added
> 
> ```
> set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${XSAN_COMPILE_FLAGS}" )
> ```
> 
> for C project to use Clang Sanitizer.
> 
> 
> Diffs
> -
> 
>   modules/ECMEnableSanitizers.cmake 9c8a4de 
> 
> Diff: https://git.reviewboard.kde.org/r/129708/diff/
> 
> 
> Testing
> ---
> 
> testcase for Clang Static Analyzer, and also for Clang Sanitizer 
> https://github.com/LLVM-China/clang-analyzer.github.io/tree/master/tests
> 
> 
> Thanks,
> 
> Leslie Zhai
> 
>

Re: Review Request 129708: C project also need Clang Sanitizer

2016-12-29 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129708/#review101639
---


Ship it!




Ship It!

- David Faure


On Dec. 29, 2016, 2:48 a.m., Leslie Zhai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129708/
> ---
> 
> (Updated Dec. 29, 2016, 2:48 a.m.)
> 
> 
> Review request for Extra Cmake Modules and Alex Merry.
> 
> 
> Bugs: 374195
> http://bugs.kde.org/show_bug.cgi?id=374195
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> So I just added
> 
> ```
> set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${XSAN_COMPILE_FLAGS}" )
> ```
> 
> for C project to use Clang Sanitizer.
> 
> 
> Diffs
> -
> 
>   modules/ECMEnableSanitizers.cmake 9c8a4de 
> 
> Diff: https://git.reviewboard.kde.org/r/129708/diff/
> 
> 
> Testing
> ---
> 
> testcase for Clang Static Analyzer, and also for Clang Sanitizer 
> https://github.com/LLVM-China/clang-analyzer.github.io/tree/master/tests
> 
> ```
> cmake .. -DCMAKE_C_COMPILER=clang   \ 
>  
> -DCMAKE_CXX_COMPILER=clang++   \  
>  
> -DECM_ENABLE_SANITIZERS='address;leak;undefined'\ 
>  
> -DCMAKE_BUILD_TYPE=Debug
> ```
> 
> testcase for kcoreaddons and kjs with GNU compiler
> 
> ```
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr \
>  
> -DECM_ENABLE_SANITIZERS='address;leak;undefined'\ 
>  
> -DKDE_INSTALL_LIBDIR=lib \
>  
> -D_KDE4_DEFAULT_HOME_POSTFIX=4 \  
>  
> -DBUILD_TESTING=ON
> ```
> 
> ```
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr \
>  
> -DECM_ENABLE_SANITIZERS='address;leak;undefined'\ 
>  
> -DKDE_INSTALL_LIBDIR=lib \
>  
> -DBUILD_TESTING=ON
> ```
> 
> 
> Thanks,
> 
> Leslie Zhai
> 
>

[Differential] [Updated] D3826: Detect inotify.

2017-01-16 Thread David Faure 
dfaure added a reviewer: skelly.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D3826

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: adridg, apol, arrowdodger, #buildsystem, #frameworks, tcberner, dfaure, 
ervin, skelly
Cc: #freebsd

[Differential] [Commented On] D3826: Detect inotify.

2017-01-16 Thread David Faure 
dfaure added inline comments.

INLINE COMMENTS

> FindInotify.cmake:48
> +
> +find_path(Inotify_INCLUDE_DIRS sys/inotify.h)
> +

What's the difference with check_include_files as used by 
kcoreaddons/CMakeLists.txt?

It seems to me that find_path won't know where to look, no, at least 
check_include_files seems much more appropriate for includes?

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D3826

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: adridg, apol, arrowdodger, #buildsystem, #frameworks, tcberner, dfaure, 
ervin, skelly
Cc: #freebsd

[Differential] [Updated] D3826: Detect inotify.

2017-01-16 Thread David Faure 
dfaure added a comment.


  OK I see. On Linux it was enough to check that the header is present (-> in 
/usr/include) while on BSD it's part of a library that could in theory be 
installed anywhere. Makes sense to set an _INCLUDE_DIRS variable then.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3826

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: adridg, apol, arrowdodger, #buildsystem, #frameworks, tcberner, ervin, 
skelly, kfunk, dfaure
Cc: kfunk, #freebsd

[Differential] [Updated] D4363: Don't set gnu style parameter with Clang and MSVC

2017-01-31 Thread David Faure 
dfaure added a comment.


  I'm no expert but this seems ok, no objection from me.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D4363

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: vonreth, #windows, bcooksley, alexmerry, dfaure
Cc: #frameworks, #build_system

D4630: Only register APPLE_* options if(APPLE)

2017-03-04 Thread David Faure 
dfaure accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D4630

To: apol, #frameworks, dfaure
Cc: #build_system

D5017: Fix ecm_generate_pkgconfig_file compatibility with new cmake

2017-03-11 Thread David Faure 
dfaure accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5017

To: xuetianweng, #frameworks, dfaure
Cc: #build_system

D5302: Use -Wno-gnu-zero-variadic-macro-arguments more

2017-04-05 Thread David Faure 
dfaure added a comment.


  5.33 is tagged since last saturday, you can push without waiting. It's always 
summer in master, for KF5.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5302

To: kfunk, kossebau, apol, dfaure
Cc: apol, #frameworks, #build_system

cmake git (branch release) breaks compiling kconfig

2017-06-30 Thread David Faure 
git://anongit.kde.org/kconfig fails to build (even from scratch) with cmake 
from git.
Something went wrong with generated files with signals, in the automoc support.

cd /d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler && 
/d/kde/inst/kde_frameworks/bin/cmake -E cmake_link_script 
CMakeFiles/test_signal.dir/link.txt --verbose=1
/home/dfaure/txtsetup/bin/ccache-g++  -pipe -DQT_STRICT_ITERATORS 
-DQT_NO_URL_CAST_FROM_STRING -DQT_NO_CAST_TO_ASCII -DQT_NO_HTTP -DQT_NO_FTP 
-Wformat -Werror=format-security -Werror=return-type -Wno-variadic-macros 
-Wmissing-include-dirs -std=c++0x -fno-operator-names -fno-exceptions -Wall 
-Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long 
-Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual 
-Werror=return-type -Wvla -pedantic -g  -Wl,--enable-new-dtags  -rdynamic 
CMakeFiles/test_signal.dir/test_signal_main.cpp.o 
CMakeFiles/test_signal.dir/test_signal.cpp.o 
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o  -o 
test_signal 
-Wl,-rpath,/d/kde/build/5/frameworks/kconfig/src/gui:/d/qt/5/kde/build/qtbase/lib:/d/kde/build/5/frameworks/kconfig/src/core
 ../../src/gui/libKF5ConfigGui.so.5.36.0 
/d/qt/5/kde/build/qtbase/lib/libQt5Gui.so.5.9.1 
/d/qt/5/kde/build/qtbase/lib/libQt5Xml.so.5.9.1 
../../src/core/libKF5ConfigCore.so.5.36.0 
/d/qt/5/kde/build/qtbase/lib/libQt5Core.so.5.9.1 
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `QScopedPointer 
>::operator->() const':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:72:
 multiple definition of `TestSignal::qt_static_metacall(QObject*, 
QMetaObject::Call, int, void**)'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc:72:
 first defined here
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `TestSignal::emoticonSettingsChanged()':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:139:
 multiple definition of `TestSignal::emoticonSettingsChanged()'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc:139:
 first defined here
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `TestSignal::styleChanged(QString const&, QString const&)':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:145:
 multiple definition of `TestSignal::styleChanged(QString const&, QString 
const&)'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc:145:
 first defined here
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `QScopedPointer 
>::operator->() const':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:72:
 multiple definition of `TestSignal::staticMetaObject'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.cpp:16:
 first defined here
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `TestSignal::metaObject() const':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:108:
 multiple definition of `TestSignal::metaObject() const'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc:108:
 first defined here
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `TestSignal::qt_metacast(char const*)':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:113:
 multiple definition of `TestSignal::qt_metacast(char const*)'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc:113:
 first defined here
CMakeFiles/test_signal.dir/test_signal_autogen/mocs_compilation.cpp.o: In 
function `TestSignal::qt_metacall(QMetaObject::Call, int, void**)':
/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_autogen/EJRQKI7XPS/moc_test_signal.cpp:121:
 multiple definition of `TestSignal::qt_metacall(QMetaObject::Call, int, 
void**)'
CMakeFiles/test_signal.dir/test_signal.cpp.o:/d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc:121:
 first defined here
collect2: error: ld returned 1 exit status

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: cmake git (branch release) breaks compiling kconfig

2017-06-30 Thread David Faure 
Hi Sebastian, thanks for your prompt reply.

On vendredi 30 juin 2017 13:03:16 CEST Sebastian Holtermann wrote:
> I think the trouble comes from mixing AUTOMOC with qt5_generate_moc. The
> moc file is generated twice
> 
> 1. By AUTOMOC:
> /d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal_aut
> ogen/EJRQKI7XPS/moc_test_signal.cpp
> 
> 2. By qt5_generate_moc:
> /d/kde/build/5/frameworks/kconfig/autotests/kconfig_compiler/test_signal.moc

The code says:

qt5_generate_moc(${_header_FILE} ${_moc_FILE})
   set_property(SOURCE ${_src_FILE} PROPERTY SKIP_AUTOMOC TRUE)  # don't run 
automoc on this file

so it souds like SKIP_AUTOMOC is broken?

> Does this happen with CMake 3.8.2 as well?

It all builds fine with CMake 3.8.2, I just retried.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

  1   2   3   4   5   6   7   8   9   >