The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13559
==
Reported By:Yuchen Deng
Assigned To:
On 25.09.2012 14:53, Mantis Bug Tracker wrote:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13559
==
There is the
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13560
==
Reported By:Andreas Langs
Assigned To:
Hi there,
Given that the dashboard is multicolored today, and I noticed there was no
merge to master, is the release schedule affected?
Should the exports-set-2 merge simply be reverted, and proceed roughly as
planned, or is there another plan?
Thanks,
Steve.
--
Powered by
Go ahead and fix it. We can delay rc1 for a day to get the exports-set-2
cleaned up if it only takes one more day. If it still looks iffy tomorrow,
we'll talk more...
On Tue, Sep 25, 2012 at 1:11 PM, Alexander Neundorf neund...@kde.orgwrote:
On Tuesday 25 September 2012, Stephen Kelly wrote:
On Tuesday 25 September 2012, David Cole wrote:
On Tue, Sep 25, 2012 at 1:22 PM, Alexander Neundorf neund...@kde.orgwrote:
On Tuesday 25 September 2012, David Cole wrote:
Go ahead and fix it. We can delay rc1 for a day to get the
exports-set-2 cleaned up if it only takes one more day. If
On Tue, Sep 25, 2012 at 1:27 PM, Alexander Neundorf neund...@kde.orgwrote:
On Tuesday 25 September 2012, David Cole wrote:
On Tue, Sep 25, 2012 at 1:22 PM, Alexander Neundorf neund...@kde.org
wrote:
On Tuesday 25 September 2012, David Cole wrote:
Go ahead and fix it. We can delay rc1
Also, the design goal of ninja was to build things as fast as
possible. And when convenience and speed are in conflict, prefer speed.
Although I can't totally disagree with Loadens comment to keep it simple
and your comment that the speed is reasonable now.
Op 24-9-2012 18:06, Wouter van
Michael Jackson wrote:
Maybe I missed some other part of this conversation, but where are you
hanging out? IRC? Webcase? Mail list?
Oh, sorry. The main meeting point would be the #cmake channel on
irc.freenode.net. Of course I'll also have a look on the lists, but the
message delay makes that
On 25.09.2012 08:13, Loaden wrote:
*After change Core_pch.cpp (add #include iostream in it), here is the
build log:*
[1/2] Building CXX object
src\plugins\coreplugin\CMakeFiles\Core.dir\Core_pch.cpp.obj
[2/2] Linking CXX shared library lib\qtcreator\plugins\Nokia\Core.dll
Yes, lib.cpp is not
2012/9/25 Peter Kümmel syntheti...@gmx.net
OK, Core_pch.pch is listed, but only as Order-only dependency:
http://martine.github.com/**ninja/manual.html#ref_**dependencieshttp://martine.github.com/ninja/manual.html#ref_dependencies
Does it work when you make the pch a Implicit dependency:
On 25.09.2012 09:18, Loaden wrote:
2012/9/25 Peter Kümmel syntheti...@gmx.net
OK, Core_pch.pch is listed, but only as Order-only dependency:
http://martine.github.com/**ninja/manual.html#ref_**dependencieshttp://martine.github.com/ninja/manual.html#ref_dependencies
Does it work when you make
I don't think so.
See:
function(add_msvc_precompiled_header target)
set(pchBinaryFile ${CMAKE_CURRENT_BINARY_DIR}/${target}_pch.pch)
*set_source_files_properties(${${${target}_PCH_SOURCE_VAR}} PROPERTIES*
*COMPILE_FLAGS /Yc\${${target}_PCH_HEADER_FILE}\
/Fp\${pchBinaryFile}\*
*
Sorry, It's wrong. Here is the correct function:
function(use_msvc_precompiled_header target sources)
if(NOT ${target}_PCH_BINARY_FILE)
message(FATAL_ERROR [${target}] Precompiled binary does not exist)
return()
endif()
get_target_property(targetSources ${target}
I've started submitting nightly Dashboards for CMake and notice sporadic CMake
Error: Unable to open check cache file for write. errors when running the tests.
For example:
CMake Error: Unable to open check cache file for write.
C:/Users/ngladitz/Dashboards/My
Hm, I'm getting an incorrect link order when I try to link an SDL
application in MSYS.
The application linked via:
target_link_libraries(demo ${TEST_DEPS})
Where test deps is:
foreach(ITEM ${TEST_DEPS})
message(: ${ITEM})
endforeach()
--
: gdi32
: opengl32
: glu32
: winmm
:
If there really is a problem here, it looks like it comes from the
structure returned by a call to the readdir function which is implemented
by the system libraries. So if there's a problem here, I don't think it's
CMake's fault.
On Sat, Sep 22, 2012 at 9:57 PM, Sean McBride
Bug reported in here: http://public.kitware.com/Bug/view.php?id=13559
2012/9/25 Loaden loa...@gmail.com
Sorry, It's wrong. Here is the correct function:
function(use_msvc_precompiled_header target sources)
if(NOT ${target}_PCH_BINARY_FILE)
message(FATAL_ERROR [${target}]
I use check_function_exists() to do some platform checking. On Linux,
pthread_yield() returns int, and on FreeBSD, it returns void. Is there a cmake
way to distinguish between the two? check_function_exists seems to not use
strict enough warnings to make sure the symbol has the right
On Tuesday 25 September 2012 09:18:38 Leif Walsh wrote:
I use check_function_exists() to do some platform checking. On Linux,
pthread_yield() returns int, and on FreeBSD, it returns void. Is there a
cmake way to distinguish between the two? check_function_exists seems to
not use strict
On 25.09.2012 14:54, Loaden wrote:
Bug reported in here: http://public.kitware.com/Bug/view.php?id=13559
Yes, looks like a bug. Good catch!
For OBJECT_DEPENDS only order only dependency is used.
2012/9/25 Loaden loa...@gmail.com
Sorry, It's wrong. Here is the correct function:
Maybe you want check_prototype_definition?
Nils
On 09/25/2012 03:18 PM, Leif Walsh wrote:
I use check_function_exists() to do some platform checking. On Linux,
pthread_yield() returns int, and on FreeBSD, it returns void. Is there a cmake
way to distinguish between the two?
this works perfectly, thanks
On 25 Sep, 2012, at 9:45 AM, Nils Gladitz glad...@sci-vis.de wrote:
Maybe you want check_prototype_definition?
Nils
On 09/25/2012 03:18 PM, Leif Walsh wrote:
I use check_function_exists() to do some platform checking. On Linux,
pthread_yield() returns int,
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
the CMakeLists user file from qtcreator, deleting the build directory
and restarting qtcreator
On Tuesday 25 September 2012, Laszlo Papp wrote:
Hi,
Worked couple of days ago. Help welcome.
Laszlo
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib/libssl.so
-- Looking for _POSIX_TIMERS
-- Looking for _POSIX_TIMERS - found
CMake Error at
On 25.09.2012 17:29, Marcus D. Hanwell wrote:
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to 2.8.9. But only after deleting
the CMakeLists user file from qtcreator, deleting
On Tue, Sep 25, 2012 at 2:56 PM, Peter Kümmel syntheti...@gmx.net wrote:
On 25.09.2012 17:29, Marcus D. Hanwell wrote:
On Thu, Sep 20, 2012 at 7:26 AM, Peter Kümmel syntheti...@gmx.net wrote:
On 19.09.2012 08:08, Wouter van Kleunen wrote:
Peter,
i had 2.8.9-pre3 before, i upgraded to
CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(test)
add_executable(test main.cpp)
#find_package(Automoc4 REQUIRED)
find_package(KDE4 REQUIRED)
main.cpp
int main() {return 0;}
Command to execute:
cmake ../ (in the build directory)
cmake version: 2.8.9
automoc4: 0.9.88
Laszlo
Forgot to mention that, but the problem happens when the find KDE4 is in
action. If I comment that line, and I try to find the automoc4 directly,
there are no such issues.
Further information:
pacman -Qo /usr/share/cmake-2.8/Modules/FindKDE4.cmake
/usr/share/cmake-2.8/Modules/FindKDE4.cmake is
I am wrapping a library with SWIG and using CMake to generate the build
scripts for me, this is all working really well. My issue is the
location of the generated .cxx files.
I have my code laid out as follows:
swig/interface/*.i -- swig interface files
python/CMakeLists.txt -- Python
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 92be70d683b948cb3e6fc37d108f65f422f925a1 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via f5513f93bf8aa1e5c59334012abe9c1a01e06eda (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 8e29b375c415a77b41e41b3d98cb6e66aad3e2d5 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 8dbe39c6c7614b64aebe9a66eb96b8158b75643c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 021e66a25c86a293fb3ad19650b9fc4a80030875 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 3f3b731961c0ac1614fff67bdcd006428d2f08cb (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via afda02f43a69cbbd59f8320c2a79ee00656d7121 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via accd4f6540a2a0a9ed6bc5dccfae8360ddb0a63d (commit)
via
On 09/25/2012 04:53 PM, Stephen Kelly wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4525e712e8cd59c501eb34469f0c5d49fcddd6de
[snip]
Tests/IncludeDirectories/apath/Angle_L_in_path.h |1 +
Windows filesystems do not support '' in file names. This will
cause an update error on
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f53759e51af2eb3413106ff90330a420b7ef9db7 (commit)
via
40 matches
Mail list logo
