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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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,
22 matches
Mail list logo
