Re: [CMake] cmake: Duplicate file name conflict
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
AUTOMOC.
On Wed, Jul 8, 2015 at 9:58 AM Petr Kmoch petr.km...@gmail.com wrote:
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 9:46 AM, Jan Steinke jan.stei...@gmail.com wrote:
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
application/code/include/*sameName.h*
application/code/include/yetAnotherName.h
application/code/source/*sameName.cpp*
application/code/source/yetAnotherName.cpp
*My CMakeLists.txt for the library:*
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(library)
set(Headers include/sameName.h
include/anotherName.h)
set(Sources source/sameName.cpp
sources/anotherName.h)
set(CMAKE_AUTOMOC ON)
include_directories(include)
add_library(${PROJECT_NAME} STATIC ${Headers} ${Sources})
target_link_libraries(${PROJECT_NAME})
*CMakeLists.txt for the application:*
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(application)
set(Headers include/sameName.h
include/yetAnotherName.h)
set(Sources source/sameName.cpp
source/yetAnotherName.cpp)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(LIBRARY_ROOT ${PROJECT_SOURCE_DIR}/../../library)
include_directories(include)
include_directories(include/remotes)
include_directories($LIBRARY_ROOT}/code/include)
include_directories(${PROJECT_BINARY_DIR}
add_subdirectory(${LIBRARY_ROOT}/code library)
add_executable(${PROJECT_NAME} ${Forms} ${Headers}
resources/${PROJECT_NAME}.qrc ${Sources})
target_link_libraries(${PROJECT_NAME} library)
I hope that helps understanding my problem. Since the content of
sameName.h and sameName.cpp of the library is different from those of the
application it doesn't build. However, it would be confusing to name them
differently since their job is the same.
Thanks in advance,
Jan
On Wed, Jul 8, 2015 at 9:03 AM Petr Kmoch petr.km...@gmail.com wrote:
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
header files to be have the same name. Or am I doing something wrong?
I have two projects, a library and an application. Both have files with
similar content, but the same file names. I am using cmake to compile the
app and the aim is that cmake also compiles the library if it doesn't yet
exist. I was stuck for a few days on that problem until I figured out that
it was due to the same file names. When renaming the files in my
application it builds correctly. Before I switched to cmake a week ago, I
used qmake integrated into Qt Creator, and it compiled just fine.
Is it wanted behavior, that cmake does not allow the same file names?
Am I doing something wrong? Altough it works with renaming the files I
would like to find a cleaner way that prevents this from happening in the
future, having same file names is nothing you can prevent if you work in a
team.
I hope you are able to help me,
Jan
--
Jan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For
more information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Jan
--
Jan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting:
Re: [CMake] cmake: Duplicate file name conflict
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
application/code/include/*sameName.h*
application/code/include/yetAnotherName.h
application/code/source/*sameName.cpp*
application/code/source/yetAnotherName.cpp
*My CMakeLists.txt for the library:*
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(library)
set(Headers include/sameName.h
include/anotherName.h)
set(Sources source/sameName.cpp
sources/anotherName.h)
set(CMAKE_AUTOMOC ON)
include_directories(include)
add_library(${PROJECT_NAME} STATIC ${Headers} ${Sources})
target_link_libraries(${PROJECT_NAME})
*CMakeLists.txt for the application:*
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(application)
set(Headers include/sameName.h
include/yetAnotherName.h)
set(Sources source/sameName.cpp
source/yetAnotherName.cpp)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(LIBRARY_ROOT ${PROJECT_SOURCE_DIR}/../../library)
include_directories(include)
include_directories(include/remotes)
include_directories($LIBRARY_ROOT}/code/include)
include_directories(${PROJECT_BINARY_DIR}
add_subdirectory(${LIBRARY_ROOT}/code library)
add_executable(${PROJECT_NAME} ${Forms} ${Headers}
resources/${PROJECT_NAME}.qrc ${Sources})
target_link_libraries(${PROJECT_NAME} library)
I hope that helps understanding my problem. Since the content of sameName.h
and sameName.cpp of the library is different from those of the application
it doesn't build. However, it would be confusing to name them differently
since their job is the same.
Thanks in advance,
Jan
On Wed, Jul 8, 2015 at 9:03 AM Petr Kmoch petr.km...@gmail.com wrote:
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 header
files to be have the same name. Or am I doing something wrong?
I have two projects, a library and an application. Both have files with
similar content, but the same file names. I am using cmake to compile the
app and the aim is that cmake also compiles the library if it doesn't yet
exist. I was stuck for a few days on that problem until I figured out that
it was due to the same file names. When renaming the files in my
application it builds correctly. Before I switched to cmake a week ago, I
used qmake integrated into Qt Creator, and it compiled just fine.
Is it wanted behavior, that cmake does not allow the same file names? Am
I doing something wrong? Altough it works with renaming the files I would
like to find a cleaner way that prevents this from happening in the
future, having same file names is nothing you can prevent if you work in a
team.
I hope you are able to help me,
Jan
--
Jan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Jan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake: Duplicate file name conflict
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 9:46 AM, Jan Steinke jan.stei...@gmail.com wrote:
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
application/code/include/*sameName.h*
application/code/include/yetAnotherName.h
application/code/source/*sameName.cpp*
application/code/source/yetAnotherName.cpp
*My CMakeLists.txt for the library:*
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(library)
set(Headers include/sameName.h
include/anotherName.h)
set(Sources source/sameName.cpp
sources/anotherName.h)
set(CMAKE_AUTOMOC ON)
include_directories(include)
add_library(${PROJECT_NAME} STATIC ${Headers} ${Sources})
target_link_libraries(${PROJECT_NAME})
*CMakeLists.txt for the application:*
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(application)
set(Headers include/sameName.h
include/yetAnotherName.h)
set(Sources source/sameName.cpp
source/yetAnotherName.cpp)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(LIBRARY_ROOT ${PROJECT_SOURCE_DIR}/../../library)
include_directories(include)
include_directories(include/remotes)
include_directories($LIBRARY_ROOT}/code/include)
include_directories(${PROJECT_BINARY_DIR}
add_subdirectory(${LIBRARY_ROOT}/code library)
add_executable(${PROJECT_NAME} ${Forms} ${Headers}
resources/${PROJECT_NAME}.qrc ${Sources})
target_link_libraries(${PROJECT_NAME} library)
I hope that helps understanding my problem. Since the content of
sameName.h and sameName.cpp of the library is different from those of the
application it doesn't build. However, it would be confusing to name them
differently since their job is the same.
Thanks in advance,
Jan
On Wed, Jul 8, 2015 at 9:03 AM Petr Kmoch petr.km...@gmail.com wrote:
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
header files to be have the same name. Or am I doing something wrong?
I have two projects, a library and an application. Both have files with
similar content, but the same file names. I am using cmake to compile the
app and the aim is that cmake also compiles the library if it doesn't yet
exist. I was stuck for a few days on that problem until I figured out that
it was due to the same file names. When renaming the files in my
application it builds correctly. Before I switched to cmake a week ago, I
used qmake integrated into Qt Creator, and it compiled just fine.
Is it wanted behavior, that cmake does not allow the same file names? Am
I doing something wrong? Altough it works with renaming the files I would
like to find a cleaner way that prevents this from happening in the
future, having same file names is nothing you can prevent if you work in a
team.
I hope you are able to help me,
Jan
--
Jan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Jan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-907-gb5b1405
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 c66d232c9c138dcf54f5314aafb7ab32590b106d (commit) from 17308871e7ddd1f2e3954c7da430ed5464ddc5b6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b5b1405f2e1b8078acfb6954418bd5eeb993685c commit b5b1405f2e1b8078acfb6954418bd5eeb993685c Merge: 1730887 c66d232 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 09:22:03 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jul 8 09:22:03 2015 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] AppleClang-CXX.cmake needs an update
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-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] fix use of CMAKE_REQUIRED_DEFINITIONS
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 clearer for this purpose. I've applied the patch with minor tweaks: Check*CompilerFlag: Refactor method used to pass flags http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d5067ae We need to revert this change from 3.3 because it caused a regression: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags https://public.kitware.com/Bug/view.php?id=15641 See issue tracker entry for further updates. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-900-g5f69be6
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 65de27b856496a756c5f234bba89bedae60dc476 (commit)
via 42272a82ca0992d40200bb881df41407f8386b8c (commit)
via b98574dab2f4fb28c53025c5204cc06ece7de0c2 (commit)
from 6e60ff567461859f22b5e81003fe4dd2d6cabf5e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f69be6cb6110645b9bb5f45ae1cee565c4efc71
commit 5f69be6cb6110645b9bb5f45ae1cee565c4efc71
Merge: 6e60ff5 65de27b
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 08:59:41 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 8 08:59:41 2015 -0400
Merge topic 'update-kwsys' into next
65de27b8 Merge branch 'upstream-kwsys' into update-kwsys
42272a82 KWSys 2015-07-07 (8504e845)
b98574da CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65de27b856496a756c5f234bba89bedae60dc476
commit 65de27b856496a756c5f234bba89bedae60dc476
Merge: b98574d 42272a8
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 08:58:51 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 8 08:58:51 2015 -0400
Merge branch 'upstream-kwsys' into update-kwsys
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42272a82ca0992d40200bb881df41407f8386b8c
commit 42272a82ca0992d40200bb881df41407f8386b8c
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Tue Jul 7 13:06:39 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 8 08:58:33 2015 -0400
KWSys 2015-07-07 (8504e845)
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ 8504e845 | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 1f19c187..8504e845
Brad King (1):
8504e845 Process: Simplify Windows command line construction
diff --git a/ProcessWin32.c b/ProcessWin32.c
index f630171..a7dd2ca 100644
--- a/ProcessWin32.c
+++ b/ProcessWin32.c
@@ -11,14 +11,12 @@
*/
#include kwsysPrivate.h
#include KWSYS_HEADER(Process.h)
-#include KWSYS_HEADER(System.h)
#include KWSYS_HEADER(Encoding.h)
/* Work-around CMake dependency scanning limitation. This must
duplicate the above list of headers. */
#if 0
# include Process.h.in
-# include System.h.in
# include Encoding_c.h.in
#endif
@@ -120,11 +118,6 @@ static void kwsysProcessSetupPipeNative(HANDLE native,
PHANDLE handle);
static void kwsysProcessCleanupHandle(PHANDLE h);
static void kwsysProcessCleanup(kwsysProcess* cp, int error);
static void kwsysProcessCleanErrorMessage(kwsysProcess* cp);
-static int kwsysProcessComputeCommandLength(kwsysProcess* cp,
-char const* const* command);
-static void kwsysProcessComputeCommandLine(kwsysProcess* cp,
- char const* const* command,
- char* cmd);
static int kwsysProcessGetTimeoutTime(kwsysProcess* cp, double* userTimeout,
kwsysProcessTime* timeoutTime);
static int kwsysProcessGetTimeoutLeft(kwsysProcessTime* timeoutTime,
@@ -602,37 +595,69 @@ int kwsysProcess_AddCommand(kwsysProcess* cp, char const*
const* command)
}
}
- /* We need to construct a single string representing the command
- and its arguments. We will surround each argument containing
- spaces with double-quotes. Inside a double-quoted argument, we
- need to escape double-quotes and all backslashes before them.
- We also need to escape backslashes at the end of an argument
- because they come before the closing double-quote for the
- argument. */
- {
- /* First determine the length of the final string. */
- int length = kwsysProcessComputeCommandLength(cp, command);
-
- /* Allocate enough space for the command. We do not need an extra
- byte for the terminating null because we allocated a space for
- the first argument that we will not use. */
- char* new_cmd = malloc(length);
- if(!new_cmd)
+ if (cp-Verbatim)
{
-/* Out of memory. */
+/* Copy the verbatim command line into the buffer. */
+newCommands[cp-NumberOfCommands] = kwsysEncoding_DupToWide(*command);
+}
+ else
+{
+/* Encode the arguments so CommandLineToArgvW can decode
+ them from the command line string in the child. */
+char buffer[32768]; /* CreateProcess max command-line length. */
+char* end =
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-905-g1730887
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 0d457c319934e6f321b838ea58ad4365e41f6f0b (commit) via 66e0681ea0293aac6f3547224cef85593cbe4595 (commit) via 8c1460653e8f21b9e09324617836aeec18f350b7 (commit) via ad91d0edd5b8e56dc6afffa38e01bcc7d0d265cd (commit) from 5f69be6cb6110645b9bb5f45ae1cee565c4efc71 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17308871e7ddd1f2e3954c7da430ed5464ddc5b6 commit 17308871e7ddd1f2e3954c7da430ed5464ddc5b6 Merge: 5f69be6 0d457c3 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 09:19:27 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jul 8 09:19:27 2015 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-911-g6fdf1bd
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 a639689c16039b2f7c8b63e31fbbbc753ccef8c8 (commit)
from 1eb9a7476c6671ecfd5a6ffea5664a839c5badf5 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fdf1bdacf56d22121af6d0997ed88abce838f25
commit 6fdf1bdacf56d22121af6d0997ed88abce838f25
Merge: 1eb9a74 a639689
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 09:59:02 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 8 09:59:02 2015 -0400
Merge topic 'CheckCompilerFlag-do-not-use-FLAGS' into next
a639689c Check*CompilerFlag: Revert to previous method used to pass flags
(#15641)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a639689c16039b2f7c8b63e31fbbbc753ccef8c8
commit a639689c16039b2f7c8b63e31fbbbc753ccef8c8
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 09:55:16 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 8 09:55:16 2015 -0400
Check*CompilerFlag: Revert to previous method used to pass flags (#15641)
Since commit v3.3.0-rc1~397^2 (Check*CompilerFlag: Refactor method used
to pass flags, 2015-02-24) these check modules pass the flags to the
compiler front-end during linking as well as during compilation. This
breaks checks for flags like '-x c++' that are meant only for the
compilation step. Revert the change and add a test covering a
compiler-only flag.
diff --git a/Modules/CheckCCompilerFlag.cmake b/Modules/CheckCCompilerFlag.cmake
index 750e4fb..53f3454 100644
--- a/Modules/CheckCCompilerFlag.cmake
+++ b/Modules/CheckCCompilerFlag.cmake
@@ -13,7 +13,7 @@
#Will be created as an internal cache variable.
#
# This internally calls the check_c_source_compiles macro and sets
-# CMAKE_REQUIRED_FLAGS to flag. See help for
+# CMAKE_REQUIRED_DEFINITIONS to flag. See help for
# CheckCSourceCompiles for a listing of variables that can otherwise
# modify the build. The result only tells that the compiler does not
# give an error message when it encounters the flag. If the flag has
@@ -38,8 +38,8 @@ include(CheckCSourceCompiles)
include(CMakeCheckCompilerFlagCommonPatterns)
macro (CHECK_C_COMPILER_FLAG _FLAG _RESULT)
- set(SAFE_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
- set(CMAKE_REQUIRED_FLAGS ${_FLAG})
+ set(SAFE_CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS})
+ set(CMAKE_REQUIRED_DEFINITIONS ${_FLAG})
# Normalize locale during test compilation.
set(_CheckCCompilerFlag_LOCALE_VARS LC_ALL LC_MESSAGES LANG)
@@ -60,5 +60,5 @@ macro (CHECK_C_COMPILER_FLAG _FLAG _RESULT)
unset(_CheckCCompilerFlag_LOCALE_VARS)
unset(_CheckCCompilerFlag_COMMON_PATTERNS)
- set (CMAKE_REQUIRED_FLAGS ${SAFE_CMAKE_REQUIRED_FLAGS})
+ set (CMAKE_REQUIRED_DEFINITIONS ${SAFE_CMAKE_REQUIRED_DEFINITIONS})
endmacro ()
diff --git a/Modules/CheckCXXCompilerFlag.cmake
b/Modules/CheckCXXCompilerFlag.cmake
index 71b3fd2..fab3a05 100644
--- a/Modules/CheckCXXCompilerFlag.cmake
+++ b/Modules/CheckCXXCompilerFlag.cmake
@@ -12,7 +12,7 @@
# var - variable to store the result
#
# This internally calls the check_cxx_source_compiles macro and sets
-# CMAKE_REQUIRED_FLAGS to flag. See help for
+# CMAKE_REQUIRED_DEFINITIONS to flag. See help for
# CheckCXXSourceCompiles for a listing of variables that can otherwise
# modify the build. The result only tells that the compiler does not
# give an error message when it encounters the flag. If the flag has
@@ -37,8 +37,8 @@ include(CheckCXXSourceCompiles)
include(CMakeCheckCompilerFlagCommonPatterns)
macro (CHECK_CXX_COMPILER_FLAG _FLAG _RESULT)
- set(SAFE_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
- set(CMAKE_REQUIRED_FLAGS ${_FLAG})
+ set(SAFE_CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS})
+ set(CMAKE_REQUIRED_DEFINITIONS ${_FLAG})
# Normalize locale during test compilation.
set(_CheckCXXCompilerFlag_LOCALE_VARS LC_ALL LC_MESSAGES LANG)
@@ -59,6 +59,6 @@ macro (CHECK_CXX_COMPILER_FLAG _FLAG _RESULT)
unset(_CheckCXXCompilerFlag_LOCALE_VARS)
unset(_CheckCXXCompilerFlag_COMMON_PATTERNS)
- set (CMAKE_REQUIRED_FLAGS ${SAFE_CMAKE_REQUIRED_FLAGS})
+ set (CMAKE_REQUIRED_DEFINITIONS ${SAFE_CMAKE_REQUIRED_DEFINITIONS})
endmacro ()
diff --git a/Modules/CheckFortranCompilerFlag.cmake
b/Modules/CheckFortranCompilerFlag.cmake
index c476661..53fd8d6 100644
--- a/Modules/CheckFortranCompilerFlag.cmake
+++ b/Modules/CheckFortranCompilerFlag.cmake
@@ -13,7 +13,7 @@
#Will be
[Cmake-commits] CMake branch, master, updated. v3.3.0-rc3-366-g8c14606
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 bf11253163b54f7c18b001cb00973a6341ee859b (commit)
from ad91d0edd5b8e56dc6afffa38e01bcc7d0d265cd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c1460653e8f21b9e09324617836aeec18f350b7
commit 8c1460653e8f21b9e09324617836aeec18f350b7
Merge: ad91d0e bf11253
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 09:19:10 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 8 09:19:10 2015 -0400
Merge topic 'add-apple-swift-language'
bf112531 Add rudimentary support for the Apple Swift language with Xcode
---
Summary of changes:
Help/release/dev/add-apple-swift-language.rst |9
Modules/CMakeDetermineSwiftCompiler.cmake | 53
Modules/CMakeSwiftCompiler.cmake.in|5 ++
Modules/CMakeSwiftInformation.cmake| 41 +++
Modules/CMakeTestSwiftCompiler.cmake | 15 ++
Modules/CompilerId/main.swift.in |1 +
Source/cmGlobalXCodeGenerator.cxx |4 ++
Tests/CMakeLists.txt |6 +++
Tests/RunCMake/CMakeLists.txt |5 ++
.../{GNUInstallDirs = Swift}/CMakeLists.txt |0
Tests/RunCMake/Swift/Enable-stdout.txt |1 +
Tests/RunCMake/Swift/Enable.cmake |1 +
.../NotSupported-result.txt} |0
Tests/RunCMake/Swift/NotSupported-stderr.txt |5 ++
Tests/RunCMake/Swift/NotSupported.cmake|1 +
Tests/RunCMake/Swift/RunCMakeTest.cmake| 11
.../XcodeTooOld-result.txt}|0
Tests/RunCMake/Swift/XcodeTooOld-stderr.txt|5 ++
Tests/RunCMake/Swift/XcodeTooOld.cmake |1 +
Tests/SwiftMix/CMain.c |4 ++
Tests/SwiftMix/CMakeLists.txt |5 ++
.../hello.f = Tests/SwiftMix/ObjC-Swift.h |0
Tests/SwiftMix/ObjCMain.m |4 ++
Tests/SwiftMix/SwiftMain.swift | 10
Tests/SwiftOnly/CMakeLists.txt |4 ++
Tests/SwiftOnly/main.swift |1 +
26 files changed, 192 insertions(+)
create mode 100644 Help/release/dev/add-apple-swift-language.rst
create mode 100644 Modules/CMakeDetermineSwiftCompiler.cmake
create mode 100644 Modules/CMakeSwiftCompiler.cmake.in
create mode 100644 Modules/CMakeSwiftInformation.cmake
create mode 100644 Modules/CMakeTestSwiftCompiler.cmake
create mode 100644 Modules/CompilerId/main.swift.in
copy Tests/RunCMake/{GNUInstallDirs = Swift}/CMakeLists.txt (100%)
create mode 100644 Tests/RunCMake/Swift/Enable-stdout.txt
create mode 100644 Tests/RunCMake/Swift/Enable.cmake
copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt =
Swift/NotSupported-result.txt} (100%)
create mode 100644 Tests/RunCMake/Swift/NotSupported-stderr.txt
create mode 100644 Tests/RunCMake/Swift/NotSupported.cmake
create mode 100644 Tests/RunCMake/Swift/RunCMakeTest.cmake
copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt =
Swift/XcodeTooOld-result.txt} (100%)
create mode 100644 Tests/RunCMake/Swift/XcodeTooOld-stderr.txt
create mode 100644 Tests/RunCMake/Swift/XcodeTooOld.cmake
create mode 100644 Tests/SwiftMix/CMain.c
create mode 100644 Tests/SwiftMix/CMakeLists.txt
copy Modules/IntelVSImplicitPath/hello.f = Tests/SwiftMix/ObjC-Swift.h (100%)
create mode 100644 Tests/SwiftMix/ObjCMain.m
create mode 100644 Tests/SwiftMix/SwiftMain.swift
create mode 100644 Tests/SwiftOnly/CMakeLists.txt
create mode 100644 Tests/SwiftOnly/main.swift
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.3.0-rc3-375-g66e0681
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 9ce7a663d6d50c6f2d7a3fbc76ed10c5af6a91a5 (commit)
via d7725a178bd498f7b50634490b6846ab9bb245f2 (commit)
via ecca26855a786bb126341e7fba59557325e54f7b (commit)
via c14f20f7dd827bd1b9164b3641db697776de85bf (commit)
via c823f04e0cbc4753cc5b6d5c9f45b9f015a12568 (commit)
via 7383e4d722809e2460bd4e87ea7fdbef5f64c303 (commit)
via 2531b9095491966c7dbcf717a8b6d3dc72c0fb9f (commit)
via 938bbc4352cf34532dc1f52998ec7d23532df765 (commit)
from 8c1460653e8f21b9e09324617836aeec18f350b7 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66e0681ea0293aac6f3547224cef85593cbe4595
commit 66e0681ea0293aac6f3547224cef85593cbe4595
Merge: 8c14606 9ce7a66
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 09:19:12 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 8 09:19:12 2015 -0400
Merge topic 'cmake-install-components'
9ce7a663 Utilities/Sphinx: Add CMake_OPTIONAL_COMPONENT macro
d7725a17 CMake: Add cmakexbuild component as REQUIRED to Tools group for
IFW installer
ecca2685 CMake: optional show LGPLv2.1 license when install cmake-gui
component
c14f20f7 CMake: Fix Web Site shortcut in IFW installer for Windows
c823f04e CMake: New option CMake_INSTALL_COMPONENTS
7383e4d7 CMake: Install COMPONENTs (sphinx-man)
2531b909 CMake: Install COMPONENTs (QtDialog)
938bbc43 CMake: Install COMPONENTs
---
Summary of changes:
CMakeCPack.cmake | 63 ++-
CMakeCPackOptions.cmake.in| 118 -
CMakeLists.txt| 11 ++
Source/CMakeLists.txt | 12 ++-
Source/CursesDialog/CMakeLists.txt|3 +-
Source/QtDialog/CMakeLists.txt| 33 --
Source/QtIFW/CMake.Dialogs.QtGUI.qs | 21
Source/QtIFW/CMake.Documentation.SphinxHTML.qs.in | 21
Source/QtIFW/{installscript.qs.in = CMake.qs.in} | 12 +--
Source/QtIFW/installscript.qs.in |8 +-
Utilities/Sphinx/CMakeLists.txt | 14 ++-
11 files changed, 285 insertions(+), 31 deletions(-)
create mode 100644 Source/QtIFW/CMake.Dialogs.QtGUI.qs
create mode 100644 Source/QtIFW/CMake.Documentation.SphinxHTML.qs.in
copy Source/QtIFW/{installscript.qs.in = CMake.qs.in} (81%)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.3.0-rc3-377-g0d457c3
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 3b60232ebcde69789a6c26f5c523ad107a7099c5 (commit) from 66e0681ea0293aac6f3547224cef85593cbe4595 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d457c319934e6f321b838ea58ad4365e41f6f0b commit 0d457c319934e6f321b838ea58ad4365e41f6f0b Merge: 66e0681 3b60232 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 09:19:14 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jul 8 09:19:14 2015 -0400 Merge topic 'preserve-generator-on-failure' 3b60232e cmake: Preserve cached CMAKE_GENERATOR when an error occurs (#15640) --- Summary of changes: Source/cmake.cxx | 13 - 1 file changed, 13 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[cmake-developers] [CMake 0015642]: ClCompile Include empty if case of drive letter changes
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15642 == Reported By:Martin Sander Assigned To: == Project:CMake Issue ID: 15642 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-08 10:13 EDT Last Modified: 2015-07-08 10:13 EDT == Summary:ClCompile Include empty if case of drive letter changes Description: If cmake is used within cmd.exe and a dependency in add_custom_command(...) has an upper case drive letter and this files occurs otherwise with a lower case drive letter, all ClCompile Include tags refererring to the containing directory are empty. The difference is produced with Archive.zip:cmakeBugHunting/build/ttt.bat and visible in Archive.zip:diff.png == Issue History Date ModifiedUsername FieldChange == 2015-07-08 10:13 Martin Sander New Issue 2015-07-08 10:13 Martin Sander File Added: Archive.zip == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015641]: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15641 == Reported By:Nikolay Zapolnov Assigned To: == Project:CMake Issue ID: 15641 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-08 09:27 EDT Last Modified: 2015-07-08 09:27 EDT == Summary:In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags Description: In CMake 3.2.3 the CHECK_CXX_COMPILER_FLAG macro launches compiler and then linker. But tested flag is passed *only* to the compiler and test passes. But in CMake 3.3.0-rc3 argument is passed to *both* the compiler and the linker. This causes an error for some flags, for example for '-x objective-c++'. Passing this flag to the linker makes it recognize .o files as objective-c++ sources and fail. Steps to Reproduce: Use the following CMakeLists.txt INCLUDE(CheckCXXCompilerFlag) CHECK_CXX_COMPILER_FLAG(-x objective-c++ HAVE_OBJC) This will work correctly in CMake 3.2.3 but in CMake 3.3.0-rc3 HAVE_OBJC will be always false. Additional Information: Part of CMakeOutput.log for good case and part of CMakeError.log for broken case are attached to the ticket. == Issue History Date ModifiedUsername FieldChange == 2015-07-08 09:27 Nikolay ZapolnovNew Issue 2015-07-08 09:27 Nikolay ZapolnovFile Added: good-cmake322.log == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-909-g1eb9a74
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 d0430c0a3eb965aca4f8df4496e06917b352d7fe (commit) from b5b1405f2e1b8078acfb6954418bd5eeb993685c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1eb9a7476c6671ecfd5a6ffea5664a839c5badf5 commit 1eb9a7476c6671ecfd5a6ffea5664a839c5badf5 Merge: b5b1405 d0430c0 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 09:46:21 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jul 8 09:46:21 2015 -0400 Merge topic 'compiler-feature-AppleClang-std-flags' into next d0430c0a AppleClang: Use modern C++14 standard flags for Xcode 6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0430c0a3eb965aca4f8df4496e06917b352d7fe commit d0430c0a3eb965aca4f8df4496e06917b352d7fe Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 09:25:02 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jul 8 09:26:57 2015 -0400 AppleClang: Use modern C++14 standard flags for Xcode 6 The Clang compiler that comes with Xcode 6 is aware of the modern -std=c++14 and -std=gnu++14 flags, so use them instead of the 1y flags. Suggested-by: darkapos...@rule506.net 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 CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() -if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) +if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 6.0) + set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++14) + set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++14) +elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) # AppleClang 5.0 knows this flag, but does not set a __cplusplus macro greater than 201103L set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y) set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++1y) --- Summary of changes: Modules/Compiler/AppleClang-CXX.cmake |5 - 1 file changed, 4 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[cmake-developers] [PATCH] Extended Nsight Tegra support for CMake
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 configuration defined for Target: ANDROID_ARCH ANDROID_STL_TYPE A new Target properties that maps to AntBuild section in generated Visual Studio project file: ANDROID_ANT_ADDITIONAL_OPTIONS ANDROID_ASSETS_DIRECTORIES ANDROID_JAR_DEPENDENCIES ANDROID_JAR_DIRECTORIES ANDROID_JAVA_SOURCE_DIR ANDROID_NATIVE_LIB_DEPENDENCIES ANDROID_NATIVE_LIB_DIRECTORIES ANDROID_PROCESS_MAX ANDROID_PROGUARD ANDROID_PROGUARD_CONFIG_PATH ANDROID_SECURE_PROPS_PATH ANDROID_SKIP_ANT_STEP Comments and suggestions is welcome, thanks in advance. -Mikhail --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ExtendedNsightTegraSupport.patch Description: ExtendedNsightTegraSupport.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
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 OLD behavior at all). But CMP0010 is one of those almost assuredly a bug policies and really easy to fix (just escape the '$' or add the closing '}'). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] Segmentation fault
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 does not seem to.
Here is the bug:
I have used the following call in my CMakeLists.txt:
set_property( TARGET cli PROPERTY LINK_LIBRARIES ${CUR_LINK_LIBS} )
When the CUR_LINK_LIBS variable is empty, CMake crashed with a segmentation
fault. Naively, I would have expected a CMake error saying incorrect number of
arguments or something like that, which CMake does all the time.
Maybe this is normal behaviour for set_property.
I am running CMake 3.2.3 compiled/installed via Macports on OSX 10.10.4 and
Xcode 6.4.
Thanks,
Ghyslain
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] [PATCH] Macro generation for relaxed constexpr
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 extended constexpr which allows for more complete
functions. This way, code bases can reap the benefits of most recent
compilers at no cost.
Best regards
Jean-Michaël Celerier
diff --git a/Modules/WriteCompilerDetectionHeader.cmake
b/Modules/WriteCompilerDetectionHeader.cmake
index a3b73bb..f7af7ec 100644
--- a/Modules/WriteCompilerDetectionHeader.cmake
+++ b/Modules/WriteCompilerDetectionHeader.cmake
@@ -144,6 +144,7 @@
# == ===
=
# ``c_restrict`` ``PREFIX_RESTRICT`` ``restrict``
# ``cxx_constexpr`` ``PREFIX_CONSTEXPR`` ``constexpr``
+# ``cxx_relaxed_constexpr`` ``PREFIX_RELAXED_CONSTEXPR`` ``constexpr``
# ``cxx_deleted_functions`` ``PREFIX_DELETED_FUNCTION`` ``= delete``
# ``cxx_extern_templates````PREFIX_EXTERN_TEMPLATE````extern``
# ``cxx_final`` ``PREFIX_FINAL`` ``final``
@@ -494,6 +495,16 @@ function(write_compiler_detection_header
# endif
\n)
endif()
+ if (feature STREQUAL cxx_relaxed_constexpr)
+set(def_value ${prefix_arg}_RELAXED_CONSTEXPR)
+set(file_content ${file_content}
+# if ${def_name}
+#define ${def_value} constexpr
+# else
+#define ${def_value}
+# endif
+\n)
+ endif()
if (feature STREQUAL cxx_final)
set(def_value ${prefix_arg}_FINAL)
set(file_content ${file_content}
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-915-gf14b781
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 d3d4d6275a2fdcc735da44d99a37644d90dd8338 (commit) from 2685880c4ab31b159ebcbffdd5fd99ffb305b86a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f14b78139f872d702d2198a4d137cb40cf3fde78 commit f14b78139f872d702d2198a4d137cb40cf3fde78 Merge: 2685880 d3d4d62 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 14:25:26 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jul 8 14:25:26 2015 -0400 Merge topic 'FindXercesC-versioned-library' into next d3d4d627 FindXercesC: Find versioned library on Windows http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3d4d6275a2fdcc735da44d99a37644d90dd8338 commit d3d4d6275a2fdcc735da44d99a37644d90dd8338 Author: Roger Leigh rle...@codelibre.net AuthorDate: Wed Jul 8 17:29:10 2015 + Commit: Roger Leigh rle...@codelibre.net CommitDate: Wed Jul 8 18:08:20 2015 + FindXercesC: Find versioned library on Windows diff --git a/Modules/FindXercesC.cmake b/Modules/FindXercesC.cmake index 5a8ea9d..984f1b9 100644 --- a/Modules/FindXercesC.cmake +++ b/Modules/FindXercesC.cmake @@ -62,7 +62,7 @@ find_path(XercesC_INCLUDE_DIR mark_as_advanced(XercesC_INCLUDE_DIR) # Find all XercesC libraries -find_library(XercesC_LIBRARY xerces-c +find_library(XercesC_LIBRARY NAMES xerces-c xerces-c_3 DOC Xerces-C++ libraries) mark_as_advanced(XercesC_LIBRARY) --- Summary of changes: Modules/FindXercesC.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [CMake] Finding internal libraries
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 building the examples and lib (ie, 'everything') together work or not? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-917-g909239e
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 a672b16a3a528d6dbfcba7758a798eeb87bd57ee (commit) from f14b78139f872d702d2198a4d137cb40cf3fde78 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=909239eba626468e8842303a06f2b12c19606a59 commit 909239eba626468e8842303a06f2b12c19606a59 Merge: f14b781 a672b16 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jul 8 14:31:25 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jul 8 14:31:25 2015 -0400 Merge topic 'eclipse-cygwin-paths' into next a672b16a Eclipse: Fix paths in target links on cygwin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a672b16a3a528d6dbfcba7758a798eeb87bd57ee commit a672b16a3a528d6dbfcba7758a798eeb87bd57ee Author: Markus Grech markus.gr...@gmail.com AuthorDate: Wed Jul 8 18:20:58 2015 +0200 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jul 8 14:29:11 2015 -0400 Eclipse: Fix paths in target links on cygwin Add a missing GetEclipsePath call to fix generation of incorrect paths for target links in Eclipse CDT generator which caused Eclipse to be unable to open files through such links. Without this the generator would generate invalid links for source files under [Targets], making Eclipse unable to open them. The old links looked like C:/cygdrive/c/..., while new links correctly are C:/ diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx index a81e53c..44bf586 100644 --- a/Source/cmExtraEclipseCDT4Generator.cxx +++ b/Source/cmExtraEclipseCDT4Generator.cxx @@ -598,7 +598,8 @@ void cmExtraEclipseCDT4Generator::CreateLinksForTargets( linkName4 += /; linkName4 += cmSystemTools::GetFilenameName(fullPath); this-AppendLinkedResource(fout, linkName4, - fullPath, LinkToFile); + this-GetEclipsePath(fullPath), + LinkToFile); } } } --- Summary of changes: Source/cmExtraEclipseCDT4Generator.cxx |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Patch to fix incorrect paths in Eclipse CDT generator under Cygwin
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 keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding Swift support to CMake
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 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 Since Apple is the only vendor implementing the language right now, the compiler id can be just `Apple`. 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'. Is there a better name? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] linking static libs into shared libs on Linux
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 VERBOSE=1' I discovered that when multilib was adding its extra link path it was overwriting the linux link flags instead of appending to them. There was a one-line fix for it. Cheers -- Steve Borho -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Adding Swift support to CMake
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 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 PathScale. The TI compiler id is TI. The GNU compiler id is GNU. The Cray compiler id is Cray. The Absoft compiler id is Absoft. There is plenty of precedent to use the vendor name. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
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 required CMP0010 into a parse error (and it warns about the two parsers disagreeing if CMP0053 is the default). 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 the OLD behavior of CMP0010, or is it too entwined in the parser improvement commits from the 3.1 release cycle as to be easily identifiable as a concise diff?) My initial attempt at the new parser removed the parser entirely (5000+ lines removed :D ), but it has too many corner cases (allowed escape sequences, CMP0010, and others; look at the tests which came with CMP0053 for a taste). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] linking static libs into shared libs on Linux
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 already compiled with -fPIC. It is only a problem when we need to link a static library from one build into the shared library of another build. The static library itself no longer supports PIC. Really? I didn't think ar was in the habit of modifying machine code like that. At this point maybe the thing to do is make a toy example that reproduces the problem. (Ideally something truly stipped down, like https://github.com/dankegel/winezeug/tree/master/cmake_examples/ex7 ) This rings a bell for me. We encountered this link failure once before. A little back history: Our project has two main source folders, common/ and encoder/, each with its own CMakeLists file. Originally we built each folder into a static library and then the root level CMakeLists file linked them into a shared library, static library, or executable. This broke when we introduced yasm-compiled assembly objects into the common/ folder. We begain getting these same exact PIC errors when trying to link the static common.lib and encoder.lib into libx265.so. And this is when we were forced to use cmake's object libraries. Now common/ and encoder/ generate object libraries and the root level CMakeLists links those objects into the final targets and this seemed to work ok. So the yasm objects are somehow the root cause. -- Steve Borho -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Segmentation fault
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
to see if it already exists and it does not seem to.
Great, thanks.
I have used the following call in my CMakeLists.txt:
set_property( TARGET cli PROPERTY LINK_LIBRARIES ${CUR_LINK_LIBS} )
When the CUR_LINK_LIBS variable is empty, CMake crashed with a
segmentation fault.
CMake is supposed to just set the property to empty in that case.
It does so for most properties but LINK_LIBRARIES has special
handling which has this bug. I've drafted a fix:
set_property: Fix crash when setting LINK_LIBRARIES to nothing
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7aa9e80e
I've queued this for merge to the 'release' branch for 3.3.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Finding internal libraries
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 ex2.c The cmake files for the examples are simple and look like cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR) project(ex1) find_package(foo REQUIRED) add_executable(ex1.x ex1.c) target_link_libraries(ex1.x foo) As I currently have it, I can built the library foo and install it with all the configuration files, etc. that it needs and everything with that process seems fine. I can then build the examples and everything works fine with that process as well. 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, but I would like to keep the cmake files for the examples essentially as they are so they can serve as a simple example of how an user might link to the library. Can this be done through Cmake or should I just write the documentation to indicate that the library needs to be compiled/installed then the examples can be built? Thanks, John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] linking static libs into shared libs on Linux
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: 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 already compiled with -fPIC. It is only a problem when we need to link a static library from one build into the shared library of another build. The static library itself no longer supports PIC. Really? I didn't think ar was in the habit of modifying machine code like that. At this point maybe the thing to do is make a toy example that reproduces the problem. (Ideally something truly stipped down, like https://github.com/dankegel/winezeug/tree/master/cmake_examples/ex7 ) This rings a bell for me. We encountered this link failure once before. A little back history: Our project has two main source folders, common/ and encoder/, each with its own CMakeLists file. Originally we built each folder into a static library and then the root level CMakeLists file linked them into a shared library, static library, or executable. This broke when we introduced yasm-compiled assembly objects into the common/ folder. We begain getting these same exact PIC errors when trying to link the static common.lib and encoder.lib into libx265.so. And this is when we were forced to use cmake's object libraries. Now common/ and encoder/ generate object libraries and the root level CMakeLists links those objects into the final targets and this seemed to work ok. So the yasm objects are somehow the root cause. -- Steve Borho -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-913-g2685880
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 7aa9e80e35f62ec5686d08b49ebe8b57cbc6cbc6 (commit)
from 6fdf1bdacf56d22121af6d0997ed88abce838f25 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2685880c4ab31b159ebcbffdd5fd99ffb305b86a
commit 2685880c4ab31b159ebcbffdd5fd99ffb305b86a
Merge: 6fdf1bd 7aa9e80
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 13:24:06 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 8 13:24:06 2015 -0400
Merge topic 'empty-LINK_LIBRARIES' into next
7aa9e80e set_property: Fix crash when setting LINK_LIBRARIES to nothing
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7aa9e80e35f62ec5686d08b49ebe8b57cbc6cbc6
commit 7aa9e80e35f62ec5686d08b49ebe8b57cbc6cbc6
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 13:14:37 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 8 13:23:16 2015 -0400
set_property: Fix crash when setting LINK_LIBRARIES to nothing
We use a special dedicated structure to store the LINK_LIBRARIES target
property. Do not try to construct a string from a NULL value. Instead
leave the property structure empty when no value is given.
Reported-by: Ghyslain Leclerc ghlecl...@gmail.com
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 70005b4..2d34747 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -1748,9 +1748,12 @@ void cmTarget::SetProperty(const std::string prop,
const char* value)
else if (prop == LINK_LIBRARIES)
{
this-Internal-LinkImplementationPropertyEntries.clear();
-cmListFileBacktrace lfbt = this-Makefile-GetBacktrace();
-cmValueWithOrigin entry(value, lfbt);
-this-Internal-LinkImplementationPropertyEntries.push_back(entry);
+if (value)
+ {
+ cmListFileBacktrace lfbt = this-Makefile-GetBacktrace();
+ cmValueWithOrigin entry(value, lfbt);
+ this-Internal-LinkImplementationPropertyEntries.push_back(entry);
+ }
}
else if (prop == SOURCES)
{
@@ -1834,9 +1837,12 @@ void cmTarget::AppendProperty(const std::string prop,
const char* value,
}
else if (prop == LINK_LIBRARIES)
{
-cmListFileBacktrace lfbt = this-Makefile-GetBacktrace();
-cmValueWithOrigin entry(value, lfbt);
-this-Internal-LinkImplementationPropertyEntries.push_back(entry);
+if (value)
+ {
+ cmListFileBacktrace lfbt = this-Makefile-GetBacktrace();
+ cmValueWithOrigin entry(value, lfbt);
+ this-Internal-LinkImplementationPropertyEntries.push_back(entry);
+ }
}
else if (prop == SOURCES)
{
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index 592b5e4..81029cd 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -146,6 +146,7 @@ add_RunCMake_test(list)
add_RunCMake_test(message)
add_RunCMake_test(project)
add_RunCMake_test(return)
+add_RunCMake_test(set_property)
add_RunCMake_test(string)
add_RunCMake_test(try_compile)
add_RunCMake_test(try_run)
diff --git a/Tests/RunCMake/set_property/CMakeLists.txt
b/Tests/RunCMake/set_property/CMakeLists.txt
new file mode 100644
index 000..18dfd26
--- /dev/null
+++ b/Tests/RunCMake/set_property/CMakeLists.txt
@@ -0,0 +1,3 @@
+cmake_minimum_required(VERSION 3.2)
+project(${RunCMake_TEST} NONE)
+include(${RunCMake_TEST}.cmake)
diff --git a/Tests/RunCMake/set_property/LINK_LIBRARIES.cmake
b/Tests/RunCMake/set_property/LINK_LIBRARIES.cmake
new file mode 100644
index 000..994e874
--- /dev/null
+++ b/Tests/RunCMake/set_property/LINK_LIBRARIES.cmake
@@ -0,0 +1,7 @@
+add_custom_target(CustomTarget)
+set_property(TARGET CustomTarget PROPERTY LINK_LIBRARIES)
+set_property(TARGET CustomTarget APPEND PROPERTY LINK_LIBRARIES)
+get_property(val TARGET CustomTarget PROPERTY LINK_LIBRARIES)
+if (NOT ${val} STREQUAL )
+ message(FATAL_ERROR LINK_LIBRARIES value is '${val}' but should be '')
+endif()
diff --git a/Tests/RunCMake/set_property/RunCMakeTest.cmake
b/Tests/RunCMake/set_property/RunCMakeTest.cmake
new file mode 100644
index 000..54e63f7
--- /dev/null
+++ b/Tests/RunCMake/set_property/RunCMakeTest.cmake
@@ -0,0 +1,3 @@
+include(RunCMake)
+
+run_cmake(LINK_LIBRARIES)
---
Summary of changes:
Source/cmTarget.cxx | 18 --
Tests/RunCMake/CMakeLists.txt|1 +
.../{AutoExportDll = set_property}/CMakeLists.txt
[cmake-developers] OBJECT library on left-hand-side of target_link_libraries
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:
CMake Error at CMakeLists.txt:13 (target_link_libraries):
Object library target objlib may not link to anything.
This makes it impossible to concisely specify if an OBJECT library has a
dependency which is an IMPORTED library.
Only the legacy way works:
add_library(objlib OBJECT ...)
target_include_directories(objlib ${ZLIB_INCLUDE_DIRS})
...
add_executable(maintarget $TARGET_OBJECTS:objlib)
target_link_libraries(maintarget ${ZLIB_LIBRARIES})
But it would be convenient if this would also work:
add_library(objlib OBJECT ...)
target_link_libraries(objlib ZLIB::ZLIB)
Question:
Is this restriction, that an OBJECT library can't be on the left hand side
of
target_link_libraries, is it a hard, final decision? Or is this issue
open for a possible improvement which would allow this and would forward
the link dependencies to the main target the OBJECT library is incorporated
into?
Tamas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] A policy for Policies
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 the OLD behavior of CMP0010, or is it too entwined in the parser improvement commits from the 3.1 release cycle as to be easily identifiable as a concise diff?) Weird are the things interesting to geeks, right? Thx, David C. On Wed, Jul 8, 2015 at 10:34 AM, Ben Boeckel ben.boec...@kitware.com wrote: 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 OLD behavior at all). But CMP0010 is one of those almost assuredly a bug policies and really easy to fix (just escape the '$' or add the closing '}'). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking
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 http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=2d8a3bd27b2f2be911a3c8c30dd667460281beaf 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 :-) Will be asked to contribute, what would this change was brought in release 3.3. -- Regards, Konstantin Podsvirov -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc3-919-ge5d3d2a
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 ad5c76af6460dad1fcdcd401ac9d2275663af445 (commit)
from 909239eba626468e8842303a06f2b12c19606a59 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5d3d2a8723f304cd5f4b7008df60e2b2bd7df69
commit e5d3d2a8723f304cd5f4b7008df60e2b2bd7df69
Merge: 909239e ad5c76a
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 8 16:07:25 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 8 16:07:25 2015 -0400
Merge topic 'cpack-ifw-framework-version' into next
ad5c76af CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad5c76af6460dad1fcdcd401ac9d2275663af445
commit ad5c76af6460dad1fcdcd401ac9d2275663af445
Author: Konstantin Podsvirov konstan...@podsvirov.pro
AuthorDate: Wed Jul 8 20:23:34 2015 +0300
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 8 16:02:03 2015 -0400
CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION
This setting was added to support QtIFW 2.0 in commit v3.3.0-rc1~70^2~1
(CPackIFW: Add QtIFW 2.0 support, 2015-04-27). We need to load the
CPackIFW module to initialize it if it is not set.
diff --git a/Source/CPack/IFW/cmCPackIFWGenerator.cxx
b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
index 80ba068..09e123c 100644
--- a/Source/CPack/IFW/cmCPackIFWGenerator.cxx
+++ b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
@@ -254,9 +254,11 @@ int cmCPackIFWGenerator::InitializeInternal()
const std::string BinCreatorOpt = CPACK_IFW_BINARYCREATOR_EXECUTABLE;
const std::string RepoGenOpt = CPACK_IFW_REPOGEN_EXECUTABLE;
+ const std::string FrameworkVersionOpt = CPACK_IFW_FRAMEWORK_VERSION;
if(!this-IsSet(BinCreatorOpt) ||
- !this-IsSet(RepoGenOpt))
+ !this-IsSet(RepoGenOpt) ||
+ !this-IsSet(FrameworkVersionOpt))
{
this-ReadListFile(CPackIFW.cmake);
}
@@ -296,7 +298,7 @@ int cmCPackIFWGenerator::InitializeInternal()
// Framework version
if(const char* FrameworkVersionSrt =
- this-GetOption(CPACK_IFW_FRAMEWORK_VERSION))
+ this-GetOption(FrameworkVersionOpt))
{
FrameworkVersion = FrameworkVersionSrt;
}
---
Summary of changes:
Source/CPack/IFW/cmCPackIFWGenerator.cxx |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
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.
constexpr foo = ...;
If I read http://en.cppreference.com/w/cpp/language/constexpr
correctly, there should be no differences in variable handling between
C++11 and 14 for constexpr, the changes are only for function bodies.
Right.
Qt 5 provides a macro for this context which expands to either 'const' or
'constexpr' depending on whether cxx_constexpr is available, and another
macro which expands to either 'const' or 'constexpr' depending on whether
cxx_relaxed_constexpr is available.
Compare the assembly of the following when compiled with -std=c++98/11/14:
#if __has_feature(cxx_constexpr)
#define DECL_CONSTEXPR constexpr
#else
#define DECL_CONSTEXPR
#endif
#if __has_feature(cxx_relaxed_constexpr)
#define DECL_RELAXED_CONSTEXPR constexpr
#else
#define DECL_RELAXED_CONSTEXPR
#endif
DECL_CONSTEXPR int getNumRegular()
{
return 42;
}
DECL_RELAXED_CONSTEXPR int getNumRelaxed()
{
int result = 0;
for (int i = 0; i 4; ++i)
result += 10;
return result + 2;
}
DECL_CONSTEXPR int betterIfConstexprParameter(int param)
{
return param / 2;
}
#if __has_feature(cxx_constexpr)
#define CXX11_CONSTEXPR_VARIABLE constexpr
#else
#define CXX11_CONSTEXPR_VARIABLE const
#endif
#if __has_feature(cxx_relaxed_constexpr)
#define CXX14_CONSTEXPR_VARIABLE constexpr
#else
#define CXX14_CONSTEXPR_VARIABLE const
#endif
int main()
{
CXX11_CONSTEXPR_VARIABLE int num1 = getNumRegular();
CXX11_CONSTEXPR_VARIABLE int result1 = betterIfConstexprParameter(num1);
CXX14_CONSTEXPR_VARIABLE int num2 = getNumRelaxed();
CXX14_CONSTEXPR_VARIABLE int result2 = betterIfConstexprParameter(num2);
return result1 - result2;
}
$ wc -l 98.s 11.s 14.s
126 98.s
90 11.s
31 14.s
Of course, such macros don't belong in the same patch as the one you
submitted and could be in a follow-up.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator expressions for output directory/name (and install?)
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
Subject: Re: [cmake-developers] Generator expressions for output directory/name
(and install?)
On 06/15/2015 03:03 PM, Robert Goulet wrote:
Updated with improved tests and added docs.
Thanks. Here are more comments.
Please split the patch to do the OUTPUT_NAME/dir changes first.
Update the Tests/PerConfig test to cover these. Since the
RUNTIME_OUTPUT_DIRECTORY properties are learning this, please do it for
ARCHIVE_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_DIRECTORY too for completeness.
Then do the install DESTINATION changes in a second patch.
That will simplify review.
In this hunk:
cmInstallTargetGenerator(
-cmTarget t, const char* dest, bool implib,
+cmMakefile* mf, cmTarget t, const char* dest, bool implib,
The cmTarget has a GetMakefile() method so there should be no need to pass the
mf separately.
In this hunk:
@@ -216,6 +216,7 @@ void
cmScriptGenerator::GenerateScriptActionsPerConfig(std::ostream os,
i != this-ConfigurationTypes-end(); ++i)
{
const char* config = i-c_str();
+ this-ConfigurationName = config;
if(this-GeneratesForConfig(config))
{
// Generate a per-configuration block.
This should not be needed if things are factored correctly.
Everything in that block already passes config through as a parameter.
Thanks,
-Brad
output-name-genex.patch
Description: output-name-genex.patch
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
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 the DEPRECATION messages separately. Making dev influence deprecation variables is not a problem. To support -Werror=dev we'll need a new variable I'm thinking though, something like a boolean CMAKE_SUPPRESS_DEVELOPER_ERRORS? What should be the expected behaviour when combining dev and deprecated now, as they affect each other. If for example the user used the options -Wno-deprecated -Wdev in a cmake invocation, the most logical to me would be that this causes CMAKE_SUPPRESS_DEVELOPER_WARNINGS to be TRUE and CMAKE_WARN_DEPRECATED to be FALSE, but implementing that might make the code more complicated than I'd hoped. Cheers, Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking
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 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad5c76af Will be asked to contribute, what would this change was brought in release 3.3. Yes, this falls in the bug in new feature category of allowed updates to the release. I've queued it for merge to the 'release' branch once it tests cleanly. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
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 necessarily need to address:
* I think I've read about constexpr being made even more relaxed in a
future CXX standard. Would we then call it 'yet_more_relaxed_constexpr'?
Clang, whose names CMake follows, likely won't introduce a name for it
because it will likely start to rely on SD-6 macros instead of extending
__has_feature. SD-6 doesn't have that problem because it would just use a
new value for the __cpp_constexpr macro (which already has two possible
values 200704 and 201304).
* The 'relaxed' name is already what is currently used for this feature.
Future developments don't really matter.
* It's appropriate for this macro to expand to empty if
cxx_relaxed_constexpr is not available, because a function marked constexpr
which is only cxx11-constexpr but not cxx14-constexpr will fail to compile
anyway. Programmers are aware of ways to implement methods in a way that is
cxx11-constexpr, even if making it cxx14-constexpr would be more
easy/readable.
* 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.
So assuming all that is correct, I think this patch is good.
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?
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
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 http://en.cppreference.com/w/cpp/language/constexpr
correctly, there should be no differences in variable handling between
C++11 and 14 for constexpr, the changes are only for function bodies.
Jean-Michaël
On Wed, Jul 8, 2015 at 9:49 PM, Stephen Kelly steve...@gmail.com wrote:
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.
Are there any values of '...' where
constexpr foo = ...;
would compile or not depending only on whether using cxx11-constexpr or
cxx14-constexpr?
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] cmake: Duplicate file name conflict
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 header files to be have the same name. Or am I doing something wrong? I have two projects, a library and an application. Both have files with similar content, but the same file names. I am using cmake to compile the app and the aim is that cmake also compiles the library if it doesn't yet exist. I was stuck for a few days on that problem until I figured out that it was due to the same file names. When renaming the files in my application it builds correctly. Before I switched to cmake a week ago, I used qmake integrated into Qt Creator, and it compiled just fine. Is it wanted behavior, that cmake does not allow the same file names? Am I doing something wrong? Altough it works with renaming the files I would like to find a cleaner way that prevents this from happening in the future, having same file names is nothing you can prevent if you work in a team. I hope you are able to help me, Jan -- Jan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] AppleClang-CXX.cmake needs an update
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 CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() -if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) +if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 6.0) + set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++14) + set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++14) +elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) # AppleClang 5.0 knows this flag, but does not set a __cplusplus macro greater than 201103L set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y) set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION -std=gnu++1y) AppleClang-CXX.cmake.diff Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] Create space delimited string with $JOIN: genex
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 $TARGET_PROPERTY:dummy,INCLUDE_DIRECTORIES)
set(lst $$BOOL:${prop}:-I$JOIN:${prop}, -I)
add_custom_command(OUTPUT foo.c
COMMAND echo ${lst}
)
Unfortunately this results in an escaped space before the -I :
echo -I/Users/gjasny/src/cmake-genex/foo\
-I/Users/gjasny/src/cmake-genex/bar
Is there a way to convince CMake not to escape the space? It looks like
whatever I do, the generator expression is handled like a single string.
Thanks,
Gregor
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Icon and Launch image support for iOS apps
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 premake as well as CMake don’t have an option to integrate Icon and LaunchImage support for iOS builds in XCode, we have a bash script, that patches the generated project files, to insert the appropriate lines to enable the icon support (this basically is 1.) copying the images into the app folder 2.) including the prepared xcasset file into the resource “folder” of the *project* (not the target) and 3.) creating a “Copy Bundle Resources” build phase step with the .xcassets file in the target’s build phases tab). The script is currently run after cmake is done (in our projects batch file) and this works fine so far for premake as well as cmake. The problem now is that if something is changed, cmake will regenerate the project files and erase those changes. The logical idea would be to execute the script whenever cmake is run. However there is no such functionality in cmake as far as anyone could tell me. Anybody has any clue as to whether cmake supports anything in that area. All ow this has to be done *BEFORE* the build process is started and *AFTER* the project files have been created. Otherwise it won’t work. We really need this because some genius from Apple decided it would be a good idea for the apps to decide what resolution an app should use on whatever lauch image resolution was choosen O_o. I have no idea about .xcassets but you can use default icon names and just add them to the RESOURCE property of the target. Launch images can be set in template plist.in file (which became Info.plist of your application). This might be helpful: * https://github.com/forexample/testapp * https://github.com/ruslo/weather Ruslo -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.3.0-rc3-380-gaa550e0
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 aa550e04f3e3a44db9ba02649f3b15929f3226a6 (commit) from c66d232c9c138dcf54f5314aafb7ab32590b106d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aa550e04f3e3a44db9ba02649f3b15929f3226a6 commit aa550e04f3e3a44db9ba02649f3b15929f3226a6 Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Jul 9 00:01:06 2015 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Jul 9 00:01:06 2015 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 1348c27..eadcb9e 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 3) -set(CMake_VERSION_PATCH 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 ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[CMake] Sphinx warning.
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: https://github.com/sphinx-doc/sphinx/issues/1346#issuecomment-75538604 I'm not sure but it may be possible to import version_info from sphinx into the conf.py containing the version of Sphinx that is installed, and then use that in an if statement. Regards Andrew -- ___ Andrew J. P. Maclean ___ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
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. Are there any values of '...' where constexpr foo = ...; would compile or not depending only on whether using cxx11-constexpr or cxx14-constexpr? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] cmake-qt: controlling includes order
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 to stop the Mac build breaking. Yes, I've hit this issue before too. I filed http://public.kitware.com/Bug/view.php?id=15643 to track it. I see target_include_directories() has a BEFORE option but no AFTER option, I would have thought that is necessary to be the equivalent of the directory level include_directories() command. It would also help to understand how the Qt5 include directories get added when they are not specified at all, i.e. when something like: add_executable(hello main.cpp) target_link_libraries(hello Qt5::Widgets) is used alone. In this case: add_executable(hello main.cpp) target_include_directories(hello PRIVATE /opt/foo) target_link_libraries(hello Qt5::Widgets) target_include_directories(hello PRIVATE /opt/bar) the order will be -I/opt/foo -I/opt/bar -I/opt/qt5/include/Qt5Widgets etc... When generating the list of directories to include, the ordered contents of the INCLUDE_DIRECTORIES property is processed first, and after that, the include directories of any ordered linked targets are appended. The ordering is the order of each different set of commands. Hope that helps. If you think the documentation can be clarified here, please contribute a patch, possibly to the cmake-buildsystem manual. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Adding Swift support to CMake
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 PathScale. The TI compiler id is TI. The GNU compiler id is GNU. The Cray compiler id is Cray. The Absoft compiler id is Absoft. There is plenty of precedent to use the vendor name. 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, is there any reason not to use the same case? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding Swift support to CMake
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, is there any reason not to use the same case? All compiler id values use CamelCase or are acronyms. The variable named APPLE is historical and meant to match the __APPLE__ preprocessor macro. Compiler id values are different. What do you think of Ben's AppleSwift suggestion? -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
