Thank you Petr!
AUTOMOC is the culprit.
That pointed me in the right direction. I was able to find this
http://public.kitware.com/Bug/view.php?id=12873 and this
http://comments.gmane.org/gmane.comp.lib.qt.user/12063.
It seems as if it is something that can't be changed due to the design of
Hi Peter,
Thanks for your quick reply.
My file structure is as such
someFolder/
library/code/include/*sameName.h*
library/code/include/anotherName.h
library/code/source/sameName.cpp
library/code/source/anotherName.cpp
I can't see anything obviously wrong with your setup. Can you post the
error you're getting as well?
The only candidate for trouble I can think of is AUTOMOC. I don't have
experience with that, but is it possible the name clash comes from
AUTOMOC-generated files?
Petr
On Wed, Jul 8, 2015 at
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 b5b1405f2e1b8078acfb6954418bd5eeb993685c (commit)
via
On 07/08/2015 03:08 AM, darkapos...@rule506.net wrote:
C++14 is a first class citizen in Xcode 6.
Applied, thanks:
AppleClang: Use modern C++14 standard flags for Xcode 6
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0430c0a
-Brad
--
Powered by www.kitware.com
Please keep messages
On 02/24/2015 09:47 AM, Brad King wrote:
On 02/24/2015 08:25 AM, Mark Abraham wrote:
Some modules shoud use CMAKE_REQUIRED_FLAGS, not CMAKE_REQUIRED_DEFINITIONS,
I think.
Actually both technically support any flags, but the latter
only for legacy reasons. I agree CMAKE_REQUIRED_FLAGS is
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 5f69be6cb6110645b9bb5f45ae1cee565c4efc71 (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 17308871e7ddd1f2e3954c7da430ed5464ddc5b6 (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 6fdf1bdacf56d22121af6d0997ed88abce838f25 (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 8c1460653e8f21b9e09324617836aeec18f350b7 (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 66e0681ea0293aac6f3547224cef85593cbe4595 (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 0d457c319934e6f321b838ea58ad4365e41f6f0b (commit)
via
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15642
==
Reported By:Martin Sander
Assigned To:
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15641
==
Reported By:Nikolay Zapolnov
Assigned To:
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 1eb9a7476c6671ecfd5a6ffea5664a839c5badf5 (commit)
via
Hi, all!
I've extended the Nsight Tegra project generator in CMake and added a bunch of
properties with the backing variables to fine-tune the generated projects.
The patch adds the following new Target properties:
A new Target properties that maps to all Configuration PropertyGroups for
each
On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote:
Is there a single example of a policy wherein the OLD behavior has
actually been removed?
Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it
as NEW (because the new parser doesn't implement the
Hello,
I think I have found a “bug” in CMake and as suggested in the Mantis Bug
Tracker, I am writing here on the list before actually filing the bug report in
case it’s actually not a bug. I have also searched in the already filed bugs
for a few minutes to see if it already exists and it
Hello,
At the ned of this mail is a patch that adds generation of a macro for
the relaxed (c++14) constexpr in WriteCompilerDetectionHeader.
This is intended for compilers that support c++11 constexpr (with
everything on a single return statement) like GCC-4.9 and the upcoming
MSVC, but not
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 f14b78139f872d702d2198a4d137cb40cf3fde78 (commit)
via
John LaGrone wrote:
However, if I try to build the
examples and the library at the same time, the configuration fails
because it cannot find the library foo for examples because it has not
been compiled.
I know I can build everything at once and it will work, ...
I don't understand. Does
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 909239eba626468e8842303a06f2b12c19606a59 (commit)
via
On 07/08/2015 12:50 PM, Markus Grech wrote:
I've attached a patch to fix a bug in the Eclipse CDT generator under Cygwin.
Applied, thanks:
Eclipse: Fix paths in target links on cygwin
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a672b16a
-Brad
--
Powered by www.kitware.com
Please
Brad King wrote:
On 07/02/2015 07:54 PM, Eric Wing wrote:
Thank you Brad. When you are ready, let me know how I can help next.
I have basic support with the Xcode generator done.
Please try out this commit:
Add rudimentary support for the Apple Swift language with Xcode
On 07/08, Dan Kegel wrote:
So maybe the yasm source needs to have a keyword or two
added to select PIC addressing mode?
Random googling finds suggestions at
http://cvs.tortall.net/pipermail/bug-yasm/2011-October/86.html
Thanks for all the help. Upon further debugging with 'make
On 07/08/2015 02:35 PM, Stephen Kelly wrote:
Since Apple is the only vendor implementing the language
right now, the compiler id can be just `Apple`.
Even if another vendor implements it the one we're identifying
will still be provided by Apple. The above wording was poor.
This seems somehow
On Wed, Jul 08, 2015 at 14:11:44 -0400, David Cole wrote:
Interesting. So, sort of, but not really. At least not explicitly.
Well, the docs state it, but there's no error for setting CMP0010 OLD
and CMP0053 NEW at the same time other than the CMP0053 parser turning
any code which would have
On 07/07, Dan Kegel wrote:
On Tue, Jul 7, 2015 at 2:25 PM, Steve Borho st...@borho.org wrote:
We're already adding -fPIC to the compile flags for the two object
libraries. This way one set of objects can be used to output the shared
library and the static library. So the C++ files are
On 07/08/2015 10:58 AM, Ghyslain Leclerc wrote:
I think I have found a bug in CMake and as suggested in the
Mantis Bug Tracker, I am writing here on the list before
actually filing the bug report in case it’s actually not a bug.
I have also searched in the already filed bugs for a few minutes
I am trying to build a library along with examples on how to use the
library. For simplicity, let's say the structure is
CMakeLists.txt
src/
CMakeLists.txt
foo.c
foo.h
examples/
CMakeLists.txt
ex1/
CMakeLists.txt
ex1.c
ex2/
CMakeLists.txt
So maybe the yasm source needs to have a keyword or two
added to select PIC addressing mode?
Random googling finds suggestions at
http://cvs.tortall.net/pipermail/bug-yasm/2011-October/86.html
On Wed, Jul 8, 2015 at 10:11 AM, Steve Borho st...@borho.org wrote:
On 07/07, Dan Kegel wrote:
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 2685880c4ab31b159ebcbffdd5fd99ffb305b86a (commit)
via
The documentation states that OBJECT libraries may not be [...] used in the
right hand side of target_link_libraries().
However it turns out that they can't be used on the left hand side either:
add_library(objlib OBJECT ...)
target_link_libraries(objlib dep-of-objlib)
Result:
Interesting. So, sort of, but not really. At least not explicitly.
I'm still interested in seeing an example commit (even if it's only
theoretical and will never actually be merged in) whose explicit
purpose is removing the OLD behavior of a single policy. (Is there
such a commit which removed
Hi, Brad!
A very small patch single commit from multiple rows in a topic branch
'cpack-ifw-generator' on my server:
http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cpack-ifw-generator
Here is the commit itself:
CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking
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 e5d3d2a8723f304cd5f4b7008df60e2b2bd7df69 (commit)
via
Jean-Michaël Celerier wrote:
I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?
For sure, I'll do this asap.
Ok let's start with the simplest one, OUTPUT_NAME generator expressions
support, then we'll do the others.
Patch in attachment.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Tuesday, June 16, 2015 10:21 AM
To: Robert Goulet
Cc: cmake-developers@cmake.org
Since AUTHOR_WARNING is a superset of DEPRECATION_WARNING I think
-W[no-]dev can influence CMAKE_WARN_DEPRECATED. Please also add
-W[no-]error=dev to turn AUTHOR_WARNING into an error and also make
it influence CMAKE_ERROR_DEPRECATED. Then -Wdeprecated and friends
can still be used to control
On 07/08/2015 03:40 PM, Konstantin Podsvirov wrote:
I found that CPack IFW generator does not work on the basis QtIFW 2.0
and above for projects which include CPackIFW.cmake module... This
hotfix corrects this chip :-)
Applied, thanks:
CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION
Jean-Michaël Celerier wrote:
Hello,
At the ned of this mail is a patch that adds generation of a macro for
the relaxed (c++14) constexpr in WriteCompilerDetectionHeader.
Thanks for working on this.
I have some thoughts for archival purposes on the mailing list. These aren't
things you
I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?
For sure, I'll do this asap.
constexpr foo = ...;
If I read
Hi Jan,
it'simpossible to answer such questions without seeing your setup. Can you
post your CMakeList and your directory structure?
Petr
On Tue, Jul 7, 2015 at 6:36 PM, Jan Steinke jan.stei...@gmail.com wrote:
Dear all,
I came across a problem, for me it seems that cmake does not allow
C++14 is a first class citizen in Xcode 6.
*diff --git a/Modules/Compiler/AppleClang-CXX.cmake
b/Modules/Compiler/AppleClang-
CXX.cmake* *index 5194da4..27e4d8a 100644*
*--- a/Modules/Compiler/AppleClang-CXX.cmake*
*+++ b/Modules/Compiler/AppleClang-CXX.cmake*
@@ -13,7 +13,10 @@ if(NOT
Hello,
in my build process I need to call a compiler like tool with the same
include directories as a certain target.
I tried the following:
cmake_minimum_required(VERSION 3.2)
project(cmake-genex C)
add_library(dummy dummy.c foo.c)
target_include_directories(dummy PUBLIC foo bar)
set(prop
On 03-Jul-15 13:00, Daniel Dewald wrote:
Howdy folks,
I’m currently in the process of converting our internal projects from
premake to cmake. The process is almost complete. However I’ve been
stuck on a seemingly simple problem the last few days that I could
need some help /advise on. Since
20150708)
+set(CMake_VERSION_PATCH 20150709)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
The latest version of Sphinx generates this warning when building CMake
from the master:
WARNING: 'default' html theme has been renamed to 'classic'. Please change
your html_theme setting either to the new 'alabaster' default theme, or to
'classic' to keep using the old default.
See:
Stephen Kelly wrote:
* A method marked constexpr will fail to compile with a compiler which
does not support relaxed constexpr if the method uses language which
requires relaxed mode (such as a for loop), even if the method is
evaluated in a non- constant expression. I tested GCC and Clang.
Bill Somerville wrote:
Also this is all due to a
Mac issue where having MacPorts Qt4 installed causes it to be pulled in
when some other MacPorts library is used, in this case FFTW3. Most of
our developers work on Windows and Linux and are not going to know that
this abomination is required
Brad King wrote:
This seems somehow wrong. Naming it based on some state 'right now'
doesn't seem future proof. The 'MSVC' compiler id is not called
'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not
called 'IBM'.
The PGI compiler id is PGI. The PathScale compiler id is
On 07/08/2015 03:04 PM, Stephen Kelly wrote:
I guess. I think part of the reason it seems wrong to me is that there is a
platform id called 'APPLE' (different case) and a variable of that name
There is also an existing GNU platorm/compiler id (same case).
If the same name is to be used,
52 matches
Mail list logo
