Re: Problem using Vc with CMake 3.0 and kf5

2015-05-28 Thread Matthias Kretz 
Hi,

On Monday 25 May 2015 11:50:35 Alex Merry wrote:
 The issue here is that Vc's macros implicitly assume that all compilation 
 flags (including include paths) are done at the directory level (with 
 include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is
 moving  towards doing things at the target level (with
 target_include_directories(), target_compile_options() and inheritance from
 targets passed to target_link_libraries()).

I have to admit I didn't know about this change in cmake. I think it's the 
right direction, though. I just started to read the relevant cmake 
documentation and then I'll see whether I can figure something out to make the 
macro work for target-based compiler flags.

Cheers,
Matthias

-- 
─
 Dipl.-Phys. Matthias Kretz

 Web:   http://compeng.uni-frankfurt.de/?mkretz

 SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
─
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-28 Thread Matthias Kretz 
On Wednesday 27 May 2015 11:19:08 Boudewijn Rempt wrote:
 On Wed, 27 May 2015, Matthias Kretz wrote:
  I have to admit I didn't know about this change in cmake. I think it's the
  right direction, though. I just started to read the relevant cmake
  documentation and then I'll see whether I can figure something out to make
  the macro work for target-based compiler flags.
 
 I tried to build our stuff with Vc 0.7 but the VcMacros.cmake from Vc
 master (which has b23418cd6494b90a20204b11f6cdb1f2bfd3877b, change
 vc_compile_for_all_implementations macro to use normal cmake compilation,
 which makes the small example app build), but that didn't build with our
 code: https://paste.kde.org/pysb0rhgk

Ah good. That looks like we're almost there. All you're missing (according to 
the error output) is the -fabi-version flag. I wonder why/how that got 
dropped, though.
The -fabi-version flag is in ${Vc_DEFINITIONS} (which should rather be called 
compile flags...).

Cheers,
Matthias

-- 
─
 Dipl.-Phys. Matthias Kretz

 Web:   http://compeng.uni-frankfurt.de/?mkretz

 SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
─
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-27 Thread Boudewijn Rempt 

On Wed, 27 May 2015, Matthias Kretz wrote:


Hi,

On Monday 25 May 2015 11:50:35 Alex Merry wrote:
The issue here is that Vc's macros implicitly assume that all compilation 
flags (including include paths) are done at the directory level (with 
include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is

moving  towards doing things at the target level (with
target_include_directories(), target_compile_options() and inheritance from
targets passed to target_link_libraries()).


I have to admit I didn't know about this change in cmake. I think it's the 
right direction, though. I just started to read the relevant cmake 
documentation and then I'll see whether I can figure something out to make the 
macro work for target-based compiler flags.




I tried to build our stuff with Vc 0.7 but the VcMacros.cmake from Vc 
master (which has b23418cd6494b90a20204b11f6cdb1f2bfd3877b, change 
vc_compile_for_all_implementations macro to use normal cmake compilation, 
which makes the small example app build), but that didn't build with our 
code: https://paste.kde.org/pysb0rhgk


Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

On Mon, 25 May 2015, Alex Merry wrote:


The issue here is that Vc's macros implicitly assume that all compilation
flags (including include paths) are done at the directory level (with
include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is moving
towards doing things at the target level (with target_include_directories(),
target_compile_options() and inheritance from targets passed to
target_link_libraries()).


Yes, exactly. I've tried to find some documenation about this change, but 
apart from the rather unhelpful info in e.g. 
http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html 
I couldn't find anything. I don't even understand why cmake is moving 
towards doing things at the target level.



Now, from the interface of the  vc_compile_for_all_implementations macro, I'm
guessing that it is run before you've even created the relevant target, let
alone called target_link_libraries() on it. That makes things a bit tricky.

Basically, as far as I can see, you have two options. One is to use the old
CMake style of calling include_directories() all over the place in your CMake
code (eg: include_directories(${Qt5Core_INCLUDE_DIRS}) when you are going to
be linking against Qt5::Core). I'm not sure if we expose the relevant variable
properly in KF5 for that approach, though.


No, it doesn't. Qt5Core_INCLUDE_DIRS is fine, gives the include 
directories, ${KDE4_INCLUDES} isn't -- it evaluates to that generator 
expression I quoted.



The other is to create a variant of vc_compile_for_all_implementations that
takes a target rather than a variable to receive object files - this should
ideally use generator expressions to extract include directories etc, but I'm
not sure if generator expressions are powerful enough to deal with the compile
flags properly.


Hm, that doesn't sound too hopeful :-(.

Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Alex Merry 
On Saturday 23 May 2015 11:51:55 Boudewijn Rempt wrote:
 Sorry for the extensive cross-posting in advance, please when replying, do
 a reply-all.
 
 Just so everyone is on the same page: Vc is a template library that makes
 it easy to build vectorized code using a single source file. Krita uses Vc
 to optimize blending colors, creating masks and much more. Krita uses the
 most recent Vc release, 0.7.4:
 http://code.compeng.uni-frankfurt.de/news/27
 
 We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc handle
 include directories is a big roadblock for us:
 https://git.reviewboard.kde.org/r/123179/ .
 
 In a nutshell: Vc builds many different object files from single cpp file.
 It does this by creating a custom command for each target vectorization
 extension. To do that, it needs to access the contents of
 INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
 http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMa
 cros.cmake?rev=0.7)
 
 get_directory_property(_inc INCLUDE_DIRECTORIES)
 foreach(_i ${_inc})
list(APPEND _flags -I${_i})
 endforeach()
 
 In the end the command is generated like this:
 
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
  COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
  -DVC_IMPL=${_impl}
  ${_outfile_flag}${_out}
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  IMPLICIT_DEPENDS CXX
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  COMMENT Building CXX object ${_out}
  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
  VERBATIM
  )
 KF5 uses cmake generator expressions to derive the include
 directories from the target_link_libraries lines. This means that when we
 try to build our per-extensions object files we get this:
 
 
 
  [  0%] Building CXX object
 KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
 -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a -Wabi -fabi-version=0 -ffp-contract=fast
 -mtune=core2 -fPIC -I/home/boud/kde/src/calligra/interfaces
 -I/home/boud/kde/build/calligra -I/home/boud/kde/src/calligra
 -I/home/boud/kde/src/calligra/libs/version
 -I/home/boud/kde/build/calligra/libs/version
 -I/home/boud/kde/src/calligra/libs/koplugin
 -I/home/boud/kde/src/calligra/libs/version
 -I/home/boud/kde/build/calligra/libs/version
 -I/home/boud/kde/src/calligra/libs/pigment
 -I/home/boud/kde/src/calligra/libs/pigment/compositeops
 -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
 -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX
 -c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOp
 FactoryPerArch.cpp
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOp
 FactoryPerArch.cpp:22:19: fatal error: QString: No such file or directory
   #include QString
 ^
  compilation terminated.
  libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for
 target 'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o'
 failed
 
 On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to be
 found.
 
 If we manually set include directories like this:
 
 if (HAVE_VC)
  message(. ${KDE4_INCLUDES})
  include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
 ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES} 
 ${Boost_INCLUDE_DIR}) endif()
 
 We end up with the entire include line for the contents of KDE4_INCLUDES
 ($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
 expanded to a string with quotes around it:
 
 [  0%] Building CXX object
 KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
 -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a -Wabi -fabi-version=0 -ffp-contract=fast
 -mtune=core2 -fPIC -I/home/boud/kde/src/calligra/interfaces
 -I/home/boud/kde/build/calligra -I/home/boud/kde/src/calligra
 -I/home/boud/kde/src/calligra/libs/version
 -I/home/boud/kde/build/calligra/libs/version
 -I/usr/include/KF5/KDELibs4Support;/usr/include/KF5/KDELibs4Support/KDE;/us
 r/include/KF5;/usr/include/x86_64-linux-gnu/qt5/;/usr/include/x86_64-linux-g
 nu/qt5/QtWidgets;/usr/include/x86_64-linux-gnu/qt5/;/usr/include/x86_64-linu
 x-gnu/qt5/QtGui;/usr/include/x86_64-linux-gnu/qt5/;/usr/include/x86_64-linux

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Alex Merry 
On Monday 25 May 2015 13:03:40 Boudewijn Rempt wrote:
 On Mon, 25 May 2015, Alex Merry wrote:
  The issue here is that Vc's macros implicitly assume that all compilation
  flags (including include paths) are done at the directory level (with
  include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is
  moving towards doing things at the target level (with
  target_include_directories(), target_compile_options() and inheritance
  from targets passed to
  target_link_libraries()).
 
 Yes, exactly. I've tried to find some documenation about this change, but
 apart from the rather unhelpful info in e.g.
 http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.ht
 ml I couldn't find anything. I don't even understand why cmake is moving
 towards doing things at the target level.

Well, a combination of convenience (linking against a target does all the 
things necessary, so you don't have to do three separate commands to use a 
library) and correctness (you'll get a configure-time error from a misspelled 
target name, but not a misspelled variable, and you don't end up adding 
include directories or compile flags to targets that don't need them).

  Now, from the interface of the  vc_compile_for_all_implementations macro,
  I'm guessing that it is run before you've even created the relevant
  target, let alone called target_link_libraries() on it. That makes things
  a bit tricky.
  
  Basically, as far as I can see, you have two options. One is to use the
  old
  CMake style of calling include_directories() all over the place in your
  CMake code (eg: include_directories(${Qt5Core_INCLUDE_DIRS}) when you are
  going to be linking against Qt5::Core). I'm not sure if we expose the
  relevant variable properly in KF5 for that approach, though.
 
 No, it doesn't. Qt5Core_INCLUDE_DIRS is fine, gives the include
 directories, ${KDE4_INCLUDES} isn't -- it evaluates to that generator
 expression I quoted.

Ah, yes. You may get somewhere with
include_directories($JOIN:${KDE4_INCLUDES}, -I)

Basically, this should replace all those semicolons in the generated output 
with  -I, which should produce a correct command line. This is untested, 
though.

  The other is to create a variant of vc_compile_for_all_implementations
  that
  takes a target rather than a variable to receive object files - this
  should
  ideally use generator expressions to extract include directories etc, but
  I'm not sure if generator expressions are powerful enough to deal with
  the compile flags properly.
 
 Hm, that doesn't sound too hopeful :-(.

Well, it should work for the include directories just fine, which seems to be 
the problem you're actually hitting. Vc does some relatively complex mangling 
of other compile flags, though, which I don't think can be implemented 
directly using generator expressions. But the flags it cares about are 
unlikely to be wrapped up in generator expressions anyway, so it probably 
won't be an issue in practice.

Alex

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

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

On Mon, 25 May 2015, Alex Merry wrote:


include_directories($JOIN:${KDE4_INCLUDES}, -I)


Well, I've tried that before, I think... It expands to this:

/usr/bin/c++ -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -O3 -g -Wabi 
-fabi-version=0 -ffp-contract=fast -mtune=core-avx-i -fPIC 
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra 
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version 
-I/home/boud/kde/build/calligra/libs/version 
-I/usr/include/KF5/KDELibs4Support -I/usr/include/KF5/KDELibs4Support/KDE 
-I/usr/include/KF5 -I/usr/include/qt5/ -I/usr/include/qt5/QtWidgets 
-I/usr/include/qt5/ -I/usr/include/qt5/QtGui -I/usr/include/qt5/ 
-I/usr/include/qt5/QtCore -I/usr/lib64/qt5//mkspecs/linux-g++ 
-I/usr/include/qt5/ -I/usr/include/qt5/QtDBus -I/usr/include/qt5/ 
-I/usr/include/qt5/QtPrintSupport -I/usr/include/KF5/KCoreAddons 
-I/usr/include/KF5 -I/usr/include/KF5/KCrash -I/usr/include/KF5 
-I/usr/include/KF5/KWidgetsAddons -I/usr/include/KF5 
-I/usr/include/KF5/KConfigCore -I/usr/include/KF5 
-I/usr/include/KF5/KConfigWidgets -I/usr/include/KF5 
-I/usr/include/KF5/KCodecs -I/usr/include/KF5 
-I/usr/include/KF5/KConfigGui -I/usr/include/KF5 -I/usr/include/qt5/ 
-I/usr/include/qt5/QtXml -I/usr/include/KF5/KAuth -I/usr/include/KF5 
-I/usr/include/KF5/KIOCore -I/usr/include/KF5 -I/usr/include/KF5/KService 
-I/usr/include/KF5 -I/usr/include/KF5/KIOFileWidgets -I/usr/include/KF5 
-I/usr/include/KF5/KIOWidgets -I/usr/include/KF5 
-I/usr/include/KF5/KJobWidgets -I/usr/include/KF5 -I/usr/include/qt5/ 
-I/usr/include/qt5/QtNetwork -I/usr/include/KF5/KCompletion 
-I/usr/include/KF5 -I/usr/include/KF5/KBookmarks -I/usr/include/KF5 
-I/usr/include/KF5/KItemViews -I/usr/include/KF5 
-I/usr/include/KF5/KXmlGui -I/usr/include/KF5 -I/usr/include/KF5/Solid 
-I/usr/include/KF5 -I/usr/include/KF5/KI18n -I/usr/include/KF5 
-I/usr/include/KF5/KNotifications -I/usr/include/KF5 
-I/usr/include/KF5/KIconThemes -I/usr/include/KF5 
-I/usr/include/KF5/KWindowSystem -I/usr/include -I/usr/include 
-I/usr/include/KF5 -I/usr/include/KF5 -I/usr/include/KF5/KGuiAddons 
-I/usr/include/KF5 -I/usr/include/KF5/KUnitConversion -I/usr/include/KF5 
-I/usr/include/KF5/KTextWidgets -I/usr/include/KF5 
-I/usr/include/KF5/SonnetUi -I/usr/include/KF5 -I/usr/include/KF5/KParts 
-I/usr/include/KF5 
-I/usr/include/KF5/KDELibs4Support;/usr/include/KF5/KDELibs4Support/KDE;/usr/include/KF5;/usr/include/qt5/;/usr/include/qt5/QtWidgets;/usr/include/qt5/;/usr/include/qt5/QtGui;/usr/include/qt5/;/usr/include/qt5/QtCore;/usr/lib64/qt5//mkspecs/linux-g++;/usr/include/qt5/;/usr/include/qt5/QtDBus;/usr/include/qt5/;/usr/include/qt5/QtPrintSupport;/usr/include/KF5/KCoreAddons;/usr/include/KF5;/usr/include/KF5/KCrash;/usr/include/KF5;/usr/include/KF5/KWidgetsAddons;/usr/include/KF5;/usr/include/KF5/KConfigCore;/usr/include/KF5;/usr/include/KF5/KConfigWidgets;/usr/include/KF5;/usr/include/KF5/KCodecs;/usr/include/KF5;/usr/include/KF5/KConfigGui;/usr/include/KF5;/usr/include/qt5/;/usr/include/qt5/QtXml;/usr/include/KF5/KAuth;/usr/include/KF5;/usr/include/KF5/KIOCore;/usr/include/KF5;/usr/include/KF5/KService;/usr/include/KF5;/usr/include/KF5/KIOFileWidgets;/usr/include/KF5;/usr/include/KF5/KIOWidgets;/usr/include/KF5;/usr/include/KF5/KJobWidgets;/usr/include/KF5;/usr/include/qt5/;/usr
/include/qt5/QtNetwork;/usr/include/KF5/KCompletion;/usr/include/KF5;/usr/include/KF5/KBookmarks;/usr/include/KF5;/usr/include/KF5/KItemViews;/usr/include/KF5;/usr/include/KF5/KXmlGui;/usr/include/KF5;/usr/include/KF5/Solid;/usr/include/KF5;/usr/include/KF5/KI18n;/usr/include/KF5;/usr/include/KF5/KNotifications;/usr/include/KF5;/usr/include/KF5/KIconThemes;/usr/include/KF5;/usr/include/KF5/KWindowSystem;/usr/include;/usr/include;/usr/include/KF5;/usr/include/KF5;/usr/include/KF5/KGuiAddons;/usr/include/KF5;/usr/include/KF5/KUnitConversion;/usr/include/KF5;/usr/include/KF5/KTextWidgets;/usr/include/KF5;/usr/include/KF5/SonnetUi;/usr/include/KF5;/usr/include/KF5/KParts;/usr/include/KF5 
-I/usr/include/qt5 -I/usr/include/qt5/QtCore 
-I/usr/lib64/qt5/mkspecs/linux-g++ -I/usr/include/qt5 
-I/usr/include/qt5/QtGui -I/usr/include/qt5/QtCore 
-I/usr/lib64/qt5/mkspecs/linux-g++ -I/usr/include/qt5 
-I/usr/include/qt5/QtXml -I/usr/include/qt5/QtCore 
-I/usr/lib64/qt5/mkspecs/linux-g++ 
-I/home/boud/kde/src/calligra/libs/koplugin 
-I/home/boud/kde/src/calligra/libs/version 
-I/home/boud/kde/build/calligra/libs/version 
-I/home/boud/kde/src/calligra/libs/pigment 
-I/home/boud/kde/src/calligra/libs/pigment/compositeops 
-I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include 
-I/usr/include -I/usr/include/OpenEXR -I/usr/local/include -mavx 
-DVC_IMPL=AVX -c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

On Mon, 25 May 2015, Alex Merry wrote:


Ah, yes. You may get somewhere with
include_directories($JOIN:${KDE4_INCLUDES}, -I)

Basically, this should replace all those semicolons in the generated output
with  -I, which should produce a correct command line. This is untested,
though.


Hm... No luck here. This outputs an error on running cmake:

CMake Error in libs/pigment/CMakeLists.txt:
  Found relative path while evaluating include directories of 
pigmentcms:


$JOIN:$KDE4_INCLUDES},

Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Alex Merry 
On Monday 25 May 2015 13:50:08 Boudewijn Rempt wrote:
 On Mon, 25 May 2015, Alex Merry wrote:
  Ah, yes. You may get somewhere with
  include_directories($JOIN:${KDE4_INCLUDES}, -I)
  
  Basically, this should replace all those semicolons in the generated
  output
  with  -I, which should produce a correct command line. This is untested,
  though.
 
 Hm... No luck here. This outputs an error on running cmake:
 
  CMake Error in libs/pigment/CMakeLists.txt:
Found relative path while evaluating include directories of
 pigmentcms:
 
  $JOIN:$KDE4_INCLUDES},

That looks like a combination of me missing some quotes and you missing the 
opening { of the variable. Try:

include_directories($JOIN:${KDE4_INCLUDES}, -I)

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

On Mon, 25 May 2015, Stephen Kelly wrote:


Boudewijn Rempt wrote:


Yes, exactly. I've tried to find some documenation about this change, but
apart from the rather unhelpful info in e.g.
http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html
I couldn't find anything. I don't even understand why cmake is moving
towards doing things at the target level.


You might also find 


http://www.cmake.org/cmake/help/v3.2/manual/cmake-buildsystem.7.html

helpful to your understanding.


Hm, that doesn't sound too hopeful :-(.


I haven't looked into what vc is yet. What is needed here is a SSCCE 


http://sscce.org/


and demonstrate that that doesn't work. If a SSCCE exists, I'm more likely 
to be able to help you.


http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to 
make it: you still need qt, KDELibs4Support and extra-cmake-modules 
installed. After that, running cmake and make VERBOSE=1 will give the 
exact problem I've got.


Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

Hi Elvis,

If you've got kdemacors.h in /usr/include (for instance because you've 
also got a kde4 dev env) then you won't encounter the error. The issue is 
that the expanded list of includes is enclosed in , which breaks the 
build.


On Mon, 25 May 2015, Elvis Stansvik wrote:


2015-05-25 16:13 GMT+02:00 Boudewijn Rempt b...@valdyas.org:
  Weird, it worked for me:

  https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or 
needed in the example at all.


I seem to be getting the same result as Alex (I think): 
https://paste.kde.org/pke2ztbok

I'm a little pussled by your paste, what is wrong with the compile line? You do 
have -I/usr/include/KF5/KDELibs4Support in there, which should
contain kdemacros.h?

Elvis
 


  On Mon, 25 May 2015, Alex Merry wrote:

On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote:
  http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as 
I know how to
  make it: you still need qt, KDELibs4Support and 
extra-cmake-modules
  installed. After that, running cmake and make VERBOSE=1 will 
give the
  exact problem I've got.


I get compiler issues with that, but the problems I'm getting are 
because
KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include
KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; 
after the class
definition, and when I fix those I get multiple definition errors 
for
Bla::bla(). The includes are ending up on the command line just 
fine.

This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or 
cmake-3.2.2.

Alex

  ___
  calligra-devel mailing list
  calligra-de...@kde.org
  https://mail.kde.org/mailman/listinfo/calligra-devel



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

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Alex Merry 
On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote:
 http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to
 make it: you still need qt, KDELibs4Support and extra-cmake-modules
 installed. After that, running cmake and make VERBOSE=1 will give the
 exact problem I've got.

I get compiler issues with that, but the problems I'm getting are because 
KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include 
KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the class 
definition, and when I fix those I get multiple definition errors for 
Bla::bla(). The includes are ending up on the command line just fine.

This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2.

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

Weird, it worked for me:

https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used 
or needed in the example at all.


On Mon, 25 May 2015, Alex Merry wrote:


On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote:

http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to
make it: you still need qt, KDELibs4Support and extra-cmake-modules
installed. After that, running cmake and make VERBOSE=1 will give the
exact problem I've got.


I get compiler issues with that, but the problems I'm getting are because
KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include
KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the class
definition, and when I fix those I get multiple definition errors for
Bla::bla(). The includes are ending up on the command line just fine.

This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2.

Alex


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

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 

On Mon, 25 May 2015, Stephen Kelly wrote:


Boudewijn Rempt wrote:


Here's an SSCCE that demonstrates the problem with Vc 0.7.4:

 cmake_minimum_required(VERSION 3.0)
 project(VcTest)

 set(CMAKE_INCLUDE_CURRENT_DIR ON)

 find_package(Qt5Core REQUIRED)
 find_package(Vc REQUIRED)

 # Uncomment this to make the build work
 # include_directories(${Qt5Core_INCLUDE_DIRS})

 vc_compile_for_all_implementations(__per_arch_factory_objs
   hello.cpp
   FLAGS -fPIC ONLY SSE2)

 message(Following objects are generated from the per-arch lib:

   ${__per_arch_factory_objs}

 )

 add_executable(hello ${__per_arch_factory_objs})
 target_link_libraries(hello Qt5::Core)



At first, I did not get a build failure because I used Vc from the master 
branch. Commit b23418cd (change vc_compile_for_all_implementations macro to 
use normal cmake compilation, 2013-10-05) removed the code which reads the 
INCLUDE_DIRECTORIES directory property.


That fact gives you more options for a way forward, right?



Yes, indeed - I can try copy the vcmacros from vc master to calligra and 
use those. We can't use vc master because we're dependent on released 
versions, but at least we've got something new to try!


Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Boudewijn Rempt 
Hm, to expand on that: if you're running into compile problems, well, then 
my problem would be solved. I've tested on kubuntu vivid, with cmake 3.0.2 
and the 5.9.0 packages.


On Mon, 25 May 2015, Boudewijn Rempt wrote:


Weird, it worked for me:

https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used 
or needed in the example at all.


On Mon, 25 May 2015, Alex Merry wrote:


On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote:

http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to
make it: you still need qt, KDELibs4Support and extra-cmake-modules
installed. After that, running cmake and make VERBOSE=1 will give the
exact problem I've got.


I get compiler issues with that, but the problems I'm getting are because
KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include
KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the 

class

definition, and when I fix those I get multiple definition errors for
Bla::bla(). The includes are ending up on the command line just fine.

This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2.

Alex


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


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

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-25 Thread Elvis Stansvik 
2015-05-25 16:13 GMT+02:00 Boudewijn Rempt b...@valdyas.org:

 Weird, it worked for me:

 https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or
 needed in the example at all.


I seem to be getting the same result as Alex (I think):
https://paste.kde.org/pke2ztbok

I'm a little pussled by your paste, what is wrong with the compile line?
You do have -I/usr/include/KF5/KDELibs4Support in there, which should
contain kdemacros.h?

Elvis




 On Mon, 25 May 2015, Alex Merry wrote:

  On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote:

 http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how
 to
 make it: you still need qt, KDELibs4Support and extra-cmake-modules
 installed. After that, running cmake and make VERBOSE=1 will give the
 exact problem I've got.


 I get compiler issues with that, but the problems I'm getting are because
 KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include
 KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the
 class
 definition, and when I fix those I get multiple definition errors for
 Bla::bla(). The includes are ending up on the command line just fine.

 This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2.

 Alex

  ___
 calligra-devel mailing list
 calligra-de...@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel

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

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-24 Thread Boudewijn Rempt 
Well, _I_ and using make and nmake... So that's not a solution either. It 
really just needs to be fixed properly!


On Sat, 23 May 2015, Yue Liu wrote:



Ninja dosen't generate that quoted include line, for the short term, how about 
stop supporting GNU Make, tell
distro maintainers to generate ninja target when running Cmake?

On May 23, 2015 5:06 AM, Aleix Pol aleix...@kde.org wrote:
  On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org 
wrote:
   Sorry for the extensive cross-posting in advance, please when replying, 
do a
   reply-all.
  
   Just so everyone is on the same page: Vc is a template library that 
makes it
   easy to build vectorized code using a single source file. Krita uses Vc 
to
   optimize blending colors, creating masks and much more. Krita uses the 
most
   recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27
  
   We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc 
handle
   include directories is a big roadblock for us:
   https://git.reviewboard.kde.org/r/123179/ .
  
   In a nutshell: Vc builds many different object files from single cpp 
file.
   It does this by creating a custom command for each target vectorization
   extension. To do that, it needs to access the contents of
   INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
   
http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7)
  
      get_directory_property(_inc INCLUDE_DIRECTORIES)
      foreach(_i ${_inc})
         list(APPEND _flags -I${_i})
      endforeach()
  
   In the end the command is generated like this:
  
            add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
               COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
               -DVC_IMPL=${_impl}
               ${_outfile_flag}${_out}
   ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
               MAIN_DEPENDENCY 
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
               IMPLICIT_DEPENDS CXX
   ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
               COMMENT Building CXX object ${_out}
               WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
               VERBATIM
               )
   KF5 uses cmake generator expressions to derive the include directories 
from
   the target_link_libraries lines. This means that when we try to build 
our
   per-extensions object files we get this:
  
  
  
       [  0%] Building CXX object
   KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
       cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++ 
-std=c++0x
   -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
   -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor
   -Woverloaded-virtual -Werror=return-type 
-D__GNUC_UBUNTU_VERSION__=0xf040a
   -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
   -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
   -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
   -I/home/boud/kde/build/calligra/libs/version
   -I/home/boud/kde/src/calligra/libs/koplugin
   -I/home/boud/kde/src/calligra/libs/version
   -I/home/boud/kde/build/calligra/libs/version
   -I/home/boud/kde/src/calligra/libs/pigment
   -I/home/boud/kde/src/calligra/libs/pigment/compositeops
   -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
   -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx 
-DVC_IMPL=AVX -c
   -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
   
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
  
  
  
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
   fatal error: QString: No such file or directory
        #include QString
                          ^
       compilation terminated.
       libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for 
target
   'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed
  
   On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to 
be
   found.
  
   If we manually set include directories like this:
  
   if (HAVE_VC)
       message(. ${KDE4_INCLUDES})
       include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
   ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
   ${Boost_INCLUDE_DIR})
   endif()
  
   We end up with the entire include line for the contents of KDE4_INCLUDES
   ($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
   expanded to a string with quotes around it:
  
      [  0%] Building CXX object

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-24 Thread Yue Liu 
Ninja dosen't generate that quoted include line, for the short term, how
about stop supporting GNU Make, tell distro maintainers to generate ninja
target when running Cmake?
On May 23, 2015 5:06 AM, Aleix Pol aleix...@kde.org wrote:

 On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org
 wrote:
  Sorry for the extensive cross-posting in advance, please when replying,
 do a
  reply-all.
 
  Just so everyone is on the same page: Vc is a template library that
 makes it
  easy to build vectorized code using a single source file. Krita uses Vc
 to
  optimize blending colors, creating masks and much more. Krita uses the
 most
  recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27
 
  We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc
 handle
  include directories is a big roadblock for us:
  https://git.reviewboard.kde.org/r/123179/ .
 
  In a nutshell: Vc builds many different object files from single cpp
 file.
  It does this by creating a custom command for each target vectorization
  extension. To do that, it needs to access the contents of
  INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
 
 http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7
 )
 
 get_directory_property(_inc INCLUDE_DIRECTORIES)
 foreach(_i ${_inc})
list(APPEND _flags -I${_i})
 endforeach()
 
  In the end the command is generated like this:
 
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
  COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
  -DVC_IMPL=${_impl}
  ${_outfile_flag}${_out}
  ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  MAIN_DEPENDENCY
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  IMPLICIT_DEPENDS CXX
  ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  COMMENT Building CXX object ${_out}
  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
  VERBATIM
  )
  KF5 uses cmake generator expressions to derive the include directories
 from
  the target_link_libraries lines. This means that when we try to build our
  per-extensions object files we get this:
 
 
 
  [  0%] Building CXX object
  KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x
  -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
  -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor
  -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a
  -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
  -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
  -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
  -I/home/boud/kde/src/calligra/libs/koplugin
  -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
  -I/home/boud/kde/src/calligra/libs/pigment
  -I/home/boud/kde/src/calligra/libs/pigment/compositeops
  -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
  -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX
 -c
  -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
 
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
  fatal error: QString: No such file or directory
   #include QString
 ^
  compilation terminated.
  libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for
 target
  'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed
 
  On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to
 be
  found.
 
  If we manually set include directories like this:
 
  if (HAVE_VC)
  message(. ${KDE4_INCLUDES})
  include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
  ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
  ${Boost_INCLUDE_DIR})
  endif()
 
  We end up with the entire include line for the contents of KDE4_INCLUDES
  ($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
  expanded to a string with quotes around it:
 
 [  0%] Building CXX object
 KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x
  -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
  -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor
  -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a
  -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
  -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
  -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version

Problem using Vc with CMake 3.0 and kf5

2015-05-24 Thread Boudewijn Rempt 
Sorry for the extensive cross-posting in advance, please when replying, do 
a reply-all.


Just so everyone is on the same page: Vc is a template library that makes 
it easy to build vectorized code using a single source file. Krita uses Vc 
to optimize blending colors, creating masks and much more. Krita uses the 
most recent Vc release, 0.7.4: 
http://code.compeng.uni-frankfurt.de/news/27


We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc handle 
include directories is a big roadblock for us: 
https://git.reviewboard.kde.org/r/123179/ .


In a nutshell: Vc builds many different object files from single cpp file. 
It does this by creating a custom command for each target vectorization 
extension. To do that, it needs to access the contents of 
INCLUDE_DIRECTORIES, like this (in VcMacros.cmake: 
http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7)


   get_directory_property(_inc INCLUDE_DIRECTORIES)
   foreach(_i ${_inc})
  list(APPEND _flags -I${_i})
   endforeach()

In the end the command is generated like this:

 add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
-DVC_IMPL=${_impl}
${_outfile_flag}${_out} 
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}

MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
IMPLICIT_DEPENDS CXX 
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}

COMMENT Building CXX object ${_out}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
VERBATIM
)
KF5 uses cmake generator expressions to derive the include 
directories from the target_link_libraries lines. This means that when we 
try to build our per-extensions object files we get this:




[  0%] Building CXX object 
KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++ 
-std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts 
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type 
-D__GNUC_UBUNTU_VERSION__=0xf040a -Wabi -fabi-version=0 -ffp-contract=fast 
-mtune=core2 -fPIC -I/home/boud/kde/src/calligra/interfaces 
-I/home/boud/kde/build/calligra -I/home/boud/kde/src/calligra 
-I/home/boud/kde/src/calligra/libs/version 
-I/home/boud/kde/build/calligra/libs/version 
-I/home/boud/kde/src/calligra/libs/koplugin 
-I/home/boud/kde/src/calligra/libs/version 
-I/home/boud/kde/build/calligra/libs/version 
-I/home/boud/kde/src/calligra/libs/pigment 
-I/home/boud/kde/src/calligra/libs/pigment/compositeops 
-I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include 
-I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX 
-c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o 
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp


/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19: 
fatal error: QString: No such file or directory

 #include QString
   ^
compilation terminated.
libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for 
target 'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' 
failed


On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to be 
found.


If we manually set include directories like this:

if (HAVE_VC)
message(. ${KDE4_INCLUDES})
include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS} 
${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}  
${Boost_INCLUDE_DIR})
endif()

We end up with the entire include line for the contents of KDE4_INCLUDES 
($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES) 
expanded to a string with quotes around it:


   [  0%] Building CXX object 
KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++ 
-std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts 
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type 
-D__GNUC_UBUNTU_VERSION__=0xf040a -Wabi -fabi-version=0 -ffp-contract=fast 
-mtune=core2 -fPIC -I/home/boud/kde/src/calligra/interfaces 
-I/home/boud/kde/build/calligra -I/home/boud/kde/src/calligra 
-I/home/boud/kde/src/calligra/libs/version 
-I/home/boud/kde/build/calligra/libs/version

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-24 Thread Boudewijn Rempt 

On Sat, 23 May 2015, Andrius da Costa Ribas wrote:



I'm not sure if I understood the issue. If we need to pass the -I parameters to 
vc_compile_for_all_implementations, then
something like https://git.reviewboard.kde.org/r/115110/diff/1/ might work.




Well, it's not that, it's also not windows-specific, we haven't even tried 
frameworks builds of calligra on windows yet :-). The issue is that Vc 
grabs the INCLUDE_DIRECTORIES variables and iterates over it, constructing 
-I arguments for the custom commands it generates to build the object 
files for each vectorization instruction set.


Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-23 Thread Aleix Pol 
On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org wrote:
 Sorry for the extensive cross-posting in advance, please when replying, do a
 reply-all.

 Just so everyone is on the same page: Vc is a template library that makes it
 easy to build vectorized code using a single source file. Krita uses Vc to
 optimize blending colors, creating masks and much more. Krita uses the most
 recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27

 We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc handle
 include directories is a big roadblock for us:
 https://git.reviewboard.kde.org/r/123179/ .

 In a nutshell: Vc builds many different object files from single cpp file.
 It does this by creating a custom command for each target vectorization
 extension. To do that, it needs to access the contents of
 INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
 http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7)

get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
   list(APPEND _flags -I${_i})
endforeach()

 In the end the command is generated like this:

  add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
 COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
 -DVC_IMPL=${_impl}
 ${_outfile_flag}${_out}
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
 MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
 IMPLICIT_DEPENDS CXX
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
 COMMENT Building CXX object ${_out}
 WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
 VERBATIM
 )
 KF5 uses cmake generator expressions to derive the include directories from
 the target_link_libraries lines. This means that when we try to build our
 per-extensions object files we get this:



 [  0%] Building CXX object
 KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++ -std=c++0x
 -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
 -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor
 -Woverloaded-virtual -Werror=return-type -D__GNUC_UBUNTU_VERSION__=0xf040a
 -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
 -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
 -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
 -I/home/boud/kde/build/calligra/libs/version
 -I/home/boud/kde/src/calligra/libs/koplugin
 -I/home/boud/kde/src/calligra/libs/version
 -I/home/boud/kde/build/calligra/libs/version
 -I/home/boud/kde/src/calligra/libs/pigment
 -I/home/boud/kde/src/calligra/libs/pigment/compositeops
 -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
 -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX -c
 -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp

 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
 fatal error: QString: No such file or directory
  #include QString
^
 compilation terminated.
 libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for target
 'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed

 On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to be
 found.

 If we manually set include directories like this:

 if (HAVE_VC)
 message(. ${KDE4_INCLUDES})
 include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
 ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
 ${Boost_INCLUDE_DIR})
 endif()

 We end up with the entire include line for the contents of KDE4_INCLUDES
 ($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
 expanded to a string with quotes around it:

[  0%] Building CXX object KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++ -std=c++0x
 -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
 -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor
 -Woverloaded-virtual -Werror=return-type -D__GNUC_UBUNTU_VERSION__=0xf040a
 -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
 -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
 -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
 -I/home/boud/kde/build/calligra/libs/version

Re: Problem using Vc with CMake 3.0 and kf5

2015-05-23 Thread Andrius da Costa Ribas 
I'm not sure if I understood the issue. If we need to pass the -I
parameters to vc_compile_for_all_implementations, then something like
https://git.reviewboard.kde.org/r/115110/diff/1/ might work.
 Em 23/05/2015 09:07, Aleix Pol aleix...@kde.org escreveu:

 On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org
 wrote:
  Sorry for the extensive cross-posting in advance, please when replying,
 do a
  reply-all.
 
  Just so everyone is on the same page: Vc is a template library that
 makes it
  easy to build vectorized code using a single source file. Krita uses Vc
 to
  optimize blending colors, creating masks and much more. Krita uses the
 most
  recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27
 
  We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc
 handle
  include directories is a big roadblock for us:
  https://git.reviewboard.kde.org/r/123179/ .
 
  In a nutshell: Vc builds many different object files from single cpp
 file.
  It does this by creating a custom command for each target vectorization
  extension. To do that, it needs to access the contents of
  INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
 
 http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7
 )
 
 get_directory_property(_inc INCLUDE_DIRECTORIES)
 foreach(_i ${_inc})
list(APPEND _flags -I${_i})
 endforeach()
 
  In the end the command is generated like this:
 
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
  COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
  -DVC_IMPL=${_impl}
  ${_outfile_flag}${_out}
  ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  MAIN_DEPENDENCY
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  IMPLICIT_DEPENDS CXX
  ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  COMMENT Building CXX object ${_out}
  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
  VERBATIM
  )
  KF5 uses cmake generator expressions to derive the include directories
 from
  the target_link_libraries lines. This means that when we try to build our
  per-extensions object files we get this:
 
 
 
  [  0%] Building CXX object
  KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x
  -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
  -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor
  -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a
  -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
  -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
  -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
  -I/home/boud/kde/src/calligra/libs/koplugin
  -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
  -I/home/boud/kde/src/calligra/libs/pigment
  -I/home/boud/kde/src/calligra/libs/pigment/compositeops
  -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
  -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX
 -c
  -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
 
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
  fatal error: QString: No such file or directory
   #include QString
 ^
  compilation terminated.
  libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for
 target
  'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed
 
  On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to
 be
  found.
 
  If we manually set include directories like this:
 
  if (HAVE_VC)
  message(. ${KDE4_INCLUDES})
  include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
  ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
  ${Boost_INCLUDE_DIR})
  endif()
 
  We end up with the entire include line for the contents of KDE4_INCLUDES
  ($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
  expanded to a string with quotes around it:
 
 [  0%] Building CXX object
 KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x
  -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
  -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor
  -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a
  -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
  -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
  -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version