Re: [cmake-developers] push of LinkOptionsCommand topic branch
Steve Wilson wrote:
Fixed.
Updated
Fixed
Great, thanks for all of that. I have force-pushed your branch, which means
you need to do this before proceeding with further work.
1) Get remote changes, including my change to your branch.
You'll see output comparable to this, where your branch is listed as having
a forced update:
$ git fetch
remote: Counting objects: 27, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 11 (delta 8), reused 2 (delta 1)
Unpacking objects: 100% (11/11), done.
From git://cmake.org/cmake
+ 74c3875...31b4965 gcc-ipo- origin/gcc-ipo (forced update)
53cffda..d582809 master - origin/master
3283439..930141d next - origin/next
You can run
gitk 74c3875...31b4965
on any of the ranges on the left to see the old and new branch in one view.
2)
git checkout LinkOptionsCommand
3) Assuming you still have no local changes,
git reset --hard origin/LinkOptionsCommand
That makes your local copy in sync with the remote as I have updated it.
The reason is that I made non-fast-forward changes to your branch. For
example, the fixup for an earlier commit should be squashed into the commit
that introduced the need for the fixup. I generally review commits from the
bottom up by running `gitk origin/LinkOptionsCommand`, so seeing unchanged
commits early with fixups later in the branch is confusing and harder to
review. The commits need to be self-contained and reviewable now and in the
future. Also, self-contained commits make it easier to see whether all
relevant features in the commit have a unit test.
Additionally, commits which are incomplete, such as the `cmTarget: Make
processCompileOptionsInternal more general.` one can not be tested properly
by the test suite.
After checking out your branch, I ran `git rebase -i master`, moved the
`Help: Adjust LINK_OPTIONS property and command docs to common style.`
commit up, and then changed the `pick` to a `f` and saved the file.
pick 643a9c9 cmTarget: Make processCompileOptionsInternal more general.
pick 0ead6e2 cmLocalGenerator: Add AddLinkOptions method for LINK_FLAGS.
pick 279368f Add support for {INTERFACE_}LINK_OPTIONS.
f e44de8a Help: Adjust LINK_OPTIONS property and command docs to common
style.
pick 36f5c3b Add support for add_link_options() command.
pick dbbfc49 Add support for target_link_options() command.
pick 71f48a1 Export: Enable support for export()/install(EXPORT) of
LINK_OPTIONS.
pick c0033d7 Help: Update buildsystem documentation for
link_options/LINK_OPTIONS.
pick f364b08 Help: Remove extra dashes from titles in documentation.
pick cfa9be7 Tests: Remove tabs from add_link_options test source file.
pick 0a4b066 Tests: Add content to target_link_options test file foo.cpp.
For more on interactive rebase see here:
https://help.github.com/articles/interactive-rebase
Other than squashing in fixups, I've made the following changes:
1) Add a comma to {INTERFACE_,}LINK_OPTIONS in the commit message so that it
is more like what is used in a shell.
2) Move the
-std::string(Used compile ) + logName
+std::string(Used ) + logName
snippet from `Add support for {INTERFACE_,}LINK_OPTIONS.` to `cmTarget: Make
processCompileOptionsInternal more general.` to complete that commit.
[git reset -p helps with this]
3) Split the STATIC_LIBRARY and OBJECT_LIBRARY differences out of
`cmLocalGenerator: Add AddLinkOptions method for LINK_FLAGS.`
Especially changes like this need to be in a commit on their own instead of
buried in a different commit which is aiming to do a very different thing.
This way it can be considered/reviewed/reasoned separately with its own
commit message.
4) Split the directory-scoped changes out of `Add support for
{INTERFACE_,}LINK_OPTIONS.`
Commits should be indivisible, where possible and where it makes sense.
Also, when introducing a new feature, it helps to introduce a minimal way of
testing it first and then add all further 'porcelain' user interface in
follow up commits. It helps to do that because the commit that introduces it
also introduces the supporting infrastructure/tests etc and it is easier
then to see the core of the implementation without anything extra.
The target property is the most-low level existence of this feature, so it
makes sense to add that, together with supporting infrastructure, in the
first commit.
5) Add a test for the LINK_OPTIONS target property.
6) Note that LINK_OPTIONS can be origin-tracked with
CMAKE_DEBUG_TARGET_PROPERTIES.
7) Re-order the introduction of the target_link_options and add_link_options
commands. This is only because I see the target_link_options as more
relevant.
8) Simplify the addition of the command test. I didn't see any reason/need
to expand the macro.
- add_test(CMakeCommands.target_link_options ${CMAKE_CTEST_COMMAND}
---build-and-test
-
Re: [cmake-developers] Request for review of topic intel-visibility
Nils Gladitz wrote: Does that work if the direct preprocessor flag -Wp,-isystem, I can't find -Wp or an equivalent in the documentation Great, thanks for checking! Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Preparing for CMake 3.0-rc1
Brad King wrote: There is one more change I'd like to make as part of the change to the 3.0 version number. I propose that we drop the fourth version component and use only two components for the feature level. Makes sense to me. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [New Module] FindOpenCL, FindHg
Hi,
I would like to propose two new modules for inclusion in CMake:
FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.)
FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is
basically the equivalent of FindSubversion for Mercurial.
The modules have been tested on Windows, Linux, and Mac, using a variety
of OpenCL runtimes.
I would be happy to be the maintainer of these modules, if they get
accepted into the CMake distribution.
Cheers,
Matthäus
#.rst:
# FindOpenCL
# --
#
# Try to find OpenCL
#
# Once done this will define
#
# ::
#
# OPENCL_FOUND- system has OpenCL
# OPENCL_INCLUDE_DIR - the OpenCL include directory
# OPENCL_LIBRARY - Link against this library to use OpenCL
# OPENCL_VERSION - OpenCL version (eg. 1.0)
#
#
FUNCTION(_FIND_OPENCL_VERSION)
INCLUDE(CheckSymbolExists)
INCLUDE(CMakePushCheckState)
CMAKE_PUSH_CHECK_STATE()
FOREACH(VERSION 2_0 1_2 1_1 1_0)
SET(CMAKE_REQUIRED_INCLUDES ${OPENCL_INCLUDE_DIR})
IF(APPLE)
CHECK_SYMBOL_EXISTS(
CL_VERSION_${VERSION}
${OPENCL_INCLUDE_DIR}/OpenCL/cl.h
OPENCL_VERSION_${VERSION})
ELSE()
CHECK_SYMBOL_EXISTS(
CL_VERSION_${VERSION}
${OPENCL_INCLUDE_DIR}/CL/cl.h
OPENCL_VERSION_${VERSION})
ENDIF()
IF(OPENCL_VERSION_${VERSION})
STRING(REPLACE _ . VERSION ${VERSION})
SET(OPENCL_VERSION_FOUND ${VERSION} CACHE
STRING Highest supported OpenCL version)
BREAK()
ENDIF()
ENDFOREACH()
CMAKE_POP_CHECK_STATE()
ENDFUNCTION()
FIND_PATH(OPENCL_INCLUDE_DIR
NAMES
CL/cl.h OpenCL/cl.h
PATHS
$ENV{PROGRAMFILES(X86)}/AMD APP/include
$ENV{AMDAPPSDKROOT}/include
$ENV{INTELOCLSDKROOT}/include
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/inc
$ENV{CUDA_PATH}/include
# Legacy Stream SDK
$ENV{ATISTREAMSDKROOT}/include)
IF(CMAKE_SIZEOF_VOID_P EQUAL 4)
SET(OPENCL_LIB_SEARCH_PATH
${OPENCL_LIB_SEARCH_PATH}
$ENV{PROGRAMFILES(X86)}/AMD APP/lib/x86
$ENV{AMDAPPSDKROOT}/lib/x86
$ENV{INTELOCLSDKROOT}/lib/x86
$ENV{CUDA_PATH}/lib/Win32
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/lib/Win32
# Legacy Stream SDK
$ENV{ATISTREAMSDKROOT}/lib/x86)
ELSEIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(OPENCL_LIB_SEARCH_PATH
${OPENCL_LIB_SEARCH_PATH}
$ENV{PROGRAMFILES(X86)}/AMD APP/lib/x86_64
$ENV{AMDAPPSDKROOT}/lib/x86_64
$ENV{INTELOCLSDKROOT}/lib/x64
$ENV{CUDA_PATH}/lib/x64
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/lib/x64
# Legacy stream SDK
$ENV{ATISTREAMSDKROOT}/lib/x86_64)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 4)
FIND_LIBRARY(
OPENCL_LIBRARY
NAMES OpenCL
PATHS ${OPENCL_LIB_SEARCH_PATH})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(
OpenCL
DEFAULT_MSG
OPENCL_LIBRARY OPENCL_INCLUDE_DIR)
if(OPENCL_FOUND)
set(OPENCL_LIBRARIES ${OPENCL_LIBRARY})
_FIND_OPENCL_VERSION()
else(OPENCL_FOUND)
set(OPENCL_LIBRARIES)
endif(OPENCL_FOUND)
mark_as_advanced(
OPENCL_INCLUDE_DIR
OPENCL_LIBRARY
)
#.rst:
# FindHg
# --
#
# Extract information from a mercurial working copy
#
# The module defines the following variables:
#
# ::
#
# Hg_EXECUTABLE - path to mercurial command line client
# Hg_FOUND - true if the command line client was found
#
#
# If the command line client executable is found the following macro is defined:
#
# ::
#
# Hg_WC_INFO(dir var-prefix)
#
# Hg_WC_INFO extracts information of a mercurial working copy
# at a given location. This macro defines the following variables:
#
# ::
#
# var-prefix_WC_CHANGESET - current changeset
# var-prefix_WC_REVISION - current revision
#
# Example usage:
#
# ::
#
# find_package(Hg)
# if(Hg_FOUND)
# Hg_WC_INFO(${PROJECT_SOURCE_DIR} Project)
# message(Current revision is ${Project_WC_REVISION})
# message(Current changeset is ${Project_WC_CHANGESET})
# endif()
SET(Hg_FOUND FALSE)
FIND_PROGRAM(Hg_EXECUTABLE
NAMES hg hg.exe
HINTS /usr/bin
PATHS [HKEY_LOCAL_MACHINE\\Software\\TortoiseHg]
[HKEY_LOCAL_MACHINE\\Software\\Wow6432Node\\TortoiseHg]
DOC hg command line client)
MARK_AS_ADVANCED(Hg_EXECUTABLE)
IF(Hg_EXECUTABLE)
SET(Hg_FOUND TRUE)
MACRO(Hg_WC_INFO dir prefix)
EXECUTE_PROCESS(COMMAND ${Hg_EXECUTABLE} id -i -n
WORKING_DIRECTORY ${dir}
ERROR_VARIABLE Hg_error
OUTPUT_VARIABLE ${prefix}_WC_DATA
OUTPUT_STRIP_TRAILING_WHITESPACE)
IF(NOT ${Hg_error} EQUAL 0)
MESSAGE(SEND_ERROR Command \${Hg_EXECUTBALE} id -n\ in directory ${dir} failed with output:\n${Hg_error})
ENDIF(NOT ${Hg_error} EQUAL 0)
STRING(REPLACE ; ${prefix}_WC_DATA ${${prefix}_WC_DATA})
LIST(GET ${prefix}_WC_DATA 0 ${prefix}_WC_CHANGESET)
LIST(GET ${prefix}_WC_DATA 1 ${prefix}_WC_REVISION)
STRING(REGEX REPLACE \\+$ ${prefix}_WC_REVISION ${${prefix}_WC_REVISION})
STRING(REGEX REPLACE \\+$ ${prefix}_WC_CHANGESET ${${prefix}_WC_CHANGESET})
ENDMACRO(Hg_WC_INFO)
ENDIF(Hg_EXECUTABLE)
IF(NOT Hg_FOUND)
IF(NOT Hg_FIND_QUIETLY)
MESSAGE(STATUS Mercurial was not found)
ELSE(NOT Hg_FIND_QUIETLY)
IF(Hg_FIND_REQUIRED)
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Am Samstag, 8. Februar 2014, 14:28:37 schrieb Matthäus G. Chajdas: Hi, I would like to propose two new modules for inclusion in CMake: FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.) FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is basically the equivalent of FindSubversion for Mercurial. The modules have been tested on Windows, Linux, and Mac, using a variety of OpenCL runtimes. I would be happy to be the maintainer of these modules, if they get accepted into the CMake distribution. Without looking much into the details: -the hg.exe should not be needed, CMake should add that itself -use FPHSA in that module, too -please add version detection to the Hg module I have not really looked into FindOpenCL yet. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, thanks for taking a look. I've changed the module accordingly. Is there a recommendation whether to use HG_ or Hg_ as the prefix for the variables? As I guess there will be a bit back forth here, I've also pushed them to a repository on github: https://github.com/Anteru/findhgcl Cheers, Matthäus On 08.02.2014 14:59, Rolf Eike Beer wrote: Am Samstag, 8. Februar 2014, 14:28:37 schrieb Matthäus G. Chajdas: Hi, I would like to propose two new modules for inclusion in CMake: FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.) FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is basically the equivalent of FindSubversion for Mercurial. The modules have been tested on Windows, Linux, and Mac, using a variety of OpenCL runtimes. I would be happy to be the maintainer of these modules, if they get accepted into the CMake distribution. Without looking much into the details: -the hg.exe should not be needed, CMake should add that itself -use FPHSA in that module, too -please add version detection to the Hg module I have not really looked into FindOpenCL yet. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Request for review of topic intel-visibility
On 08.02.2014 12:10, Stephen Kelly wrote: Nils Gladitz wrote: Does that work if the direct preprocessor flag -Wp,-isystem, I can't find -Wp or an equivalent in the documentation I did find /Qoption,cpp, by looking through the command line help but it doesn't seem to like -isystem either :/ Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Am Samstag, 8. Februar 2014, 16:38:02 schrieb Matthäus G. Chajdas: Hi Eike, thanks for taking a look. I've changed the module accordingly. Is there a recommendation whether to use HG_ or Hg_ as the prefix for the variables? As I guess there will be a bit back forth here, I've also pushed them to a repository on github: https://github.com/Anteru/findhgcl That's simple: the same way as the module is called. CMake set's some automatic variables, e.g. to reflect the REQUIRED and version arguments given to the find_package() call. These are set the same way as the module name is spelled, and so does FPHSA. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Unnecessary rebuild of ExternalProject_Add target
Is there something that I am missing that will prevent make from *always*
calling autogen and configure even though the target has been built and has
not been changed ?
Here is the offending project.
## Grub boot loader
set(PROJECT_NAME grub)
set(PROJECT_URL git://git.savannah.gnu.org/grub.git)
set(PROJECT_DEPENDS bison)
set(PROJECT_CONFIGURE_COMMAND ./autogen.sh ./configure)
ExternalProject_Add(
${PROJECT_NAME}
DEPENDS ${PROJECT_DEPENDS}
GIT_REPOSITORY ${PROJECT_URL}
CONFIGURE_COMMAND ${PROJECT_CONFIGURE_COMMAND}
BUILD_COMMAND make -j 2
BUILD_IN_SOURCE 1 # What's up with that !
CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}
INSTALL_COMMAND
)
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unnecessary rebuild of ExternalProject_Add target
When you give a git repo for ExternalProject, it will *always* execute the UPDATE_COMMAND by default. And then, all the steps after update will re-execute since update re-ran. If you want to use a git repo, but prevent this behavior, you can say: UPDATE_COMMAND to eliminate the default update step. You can also snap to a known commit in the repo by using GIT_TAG. HTH, David C. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unnecessary rebuild of ExternalProject_Add target
On 8. Feb 2014, at 14:28, David Cole dlrd...@aol.com wrote: When you give a git repo for ExternalProject, it will *always* execute the UPDATE_COMMAND by default. And then, all the steps after update will re-execute since update re-ran. We solved this by using a CMake script as an update step for autoconf projects, which does nothing if configure ran already: https://github.com/Eyescale/Buildyard/blob/master/CMake/UseExternalAutoconf.cmake#L26 Used here, which feeds into ExternalProject just below: https://github.com/Eyescale/Buildyard/blob/master/CMake/UseExternal.cmake#L320 HTH, Stefan. -- http://www.eyescale.ch https://github.com/Eyescale/ http://www.linkedin.com/in/eilemann signature.asc Description: Message signed with OpenPGP using GPGMail -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] find_library fails with local target but finds symbolic link to the same framework from ${CMAKE_OSX_SYSROOT}/System/Library/Frameworks
I'm unable to find an iOS framework on OS X using find_library, but it works
well if I create a symbolic link to the same target from the standard
framework location: ${CMAKE_OSX_SYSROOT}/System/Library/Frameworks. I'd
like to avoid a symlink in my system folders in order to get this working.
Given the following symbolic link and iOS framework target on OS X:
The following 4 lines in my CMakeLists.txt file (ADD_LOCAL_FRAMEWORK shown
at bottom):
lead to the following failure and success messages. Is there a workaround
for this, or does the CMake find_library command only work with the standard
system path? How would I fix (or debug) this?
The find_library macro is as follows:
Note: I removed an earlier post from last week after isolating the problem
to this scenario, since most of the details from that post are now
irrelevant.
--
View this message in context:
http://cmake.3232098.n2.nabble.com/find-library-fails-with-local-target-but-finds-symbolic-link-to-the-same-framework-from-CMAKE-OSX-SYs-tp7586731.html
Sent from the CMake mailing list archive at Nabble.com.
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and shared|static/release|debug?
hello:
thanks all for the help--I really appreciate it. that cleaned up my file
quite a lot and was exactly what I was aiming for.
Thanks again,
On 2/5/2014 6:17 AM, Johannes Zarl wrote:
Hi,
On Tuesday, 4. February 2014, 23:41:55, Littlefield, Tyler wrote:
I've tried this a few different ways and ran into issues. If someone
wouldn't mind pointing out where I'm going wrong, I would appreciate it.
(for example if there's a better way to do what I'm trying).
It would help if you also included a textual description of the thing you want
to achieve and your issues. Since the cmake compiler does not do what you want
it to do, it is quite plausible that the people on this list having a good
understanding of cmake will misinterpret your cmake code...
That aside, as Jakub pointed out, it seems that you try to reimplement the
CMAKE_BUILD_TYPE support on your own.
As to the shared library stuff: CMake can already build shared and static
libraries in the same build:
set( MYLIB_SRCS mylibsource1.cxx mylibsource2.cxx)
add_library( mylib-static STATIC ${MYLIB_SRCS})
add_library( mylib-static SHARED ${MYLIB_SRCS})
If you want to make it a choice, you could do it like this:
set( BUILD_LIBTYPE SHARED CACHE STRING SHARED or STATIC )
# enforce string in the gui:
set_property(CACHE BUILD_LIBTYPE PROPERTY STRINGS SHARED STATIC)
if ( NOT BUILD_LIBTYPE STREQUAL STATIC )
set ( BUILD_LIBTYPE SHARED CACHE STRING FORCE)
endif()
add_library( mylib-static ${BUILD_LIBTYPE} ${MYLIB_SRCS})
HTH,
Johannes
--
Take care,
Ty
http://tds-solutions.net
He that will not reason is a bigot; he that cannot reason is a fool; he that
dares not reason is a slave.
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] execute command during ctest timeout
When ctest times out a test, is it possible to tell it to execute a command before killing the subprocess? I'd like to be able to use pstree gdb to determine where a nightly test is intermittently getting stuck. Thanks, Jayen -- Marathon Targets Pty Ltd Marathon, like the run from Marathon to Athens Targets, like the things at which one shoots for practice Sydney, Australia http://www.marathon-targets.com/ -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7526-g930141d
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 930141dec3c7814855b53dd5d79ce682bab73211 (commit)
via 31b49654bc3d90dc74836a560ab9f3e2d95a1acf (commit)
from 3283439d6da10b1e37df7ab41cf2314df02d7ee9 (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=930141dec3c7814855b53dd5d79ce682bab73211
commit 930141dec3c7814855b53dd5d79ce682bab73211
Merge: 3283439 31b4965
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Sat Feb 8 03:38:04 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 8 03:38:04 2014 -0500
Merge topic 'gcc-ipo' into next
31b49654 IPO: implemented INTERPROCEDURAL_OPTIMIZATION for gcc (-flto)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=31b49654bc3d90dc74836a560ab9f3e2d95a1acf
commit 31b49654bc3d90dc74836a560ab9f3e2d95a1acf
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Jan 31 23:56:40 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Sat Feb 8 09:37:46 2014 +0100
IPO: implemented INTERPROCEDURAL_OPTIMIZATION for gcc (-flto)
Using the IPO specific rule variables in the Ninja generator should
fix intel IPO as well.
diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
index f01255c..e40fa9f 100644
--- a/Modules/Compiler/GNU.cmake
+++ b/Modules/Compiler/GNU.cmake
@@ -55,4 +55,92 @@ macro(__compiler_gnu lang)
if(NOT APPLE)
set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} -isystem )
endif()
+
+ # LTO/IPO
+ if(NOT CMAKE_GCC_AR OR NOT CMAKE_GCC_RANLIB)
+if(IS_ABSOLUTE ${CMAKE_${lang}_COMPILER})
+ string(REGEX MATCH ^([0-9]+.[0-9]+) _version
+${CMAKE_${lang}_COMPILER_VERSION})
+ get_filename_component(_dir ${CMAKE_${lang}_COMPILER} DIRECTORY)
+
+ find_program(CMAKE_GCC_AR NAMES
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ar
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ar-${_version}
+ )
+
+ find_program(CMAKE_GCC_RANLIB NAMES
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ranlib
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ranlib-${_version}
+ )
+endif()
+ endif()
+
+ if(CMAKE_GCC_AR AND CMAKE_GCC_RANLIB)
+set(__lto_flags -flto)
+
+if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.7)
+ list(APPEND __lto_flags -fno-fat-lto-objects)
+endif()
+
+if(NOT DEFINED CMAKE_${lang}_PASSED_LTO_TEST)
+ set(__output_dir ${CMAKE_PLATFORM_INFO_DIR}/LtoTest${lang})
+ file(MAKE_DIRECTORY ${__output_dir})
+ set(__output_base ${__output_dir}/lto-test-${lang})
+
+ execute_process(
+COMMAND ${CMAKE_COMMAND} -E echo void foo() {}
+COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -c -xc -
+ -o ${__output_base}.o
+RESULT_VARIABLE __result
+ERROR_QUIET
+OUTPUT_QUIET
+ )
+
+ if(${__result} STREQUAL 0)
+execute_process(
+ COMMAND ${CMAKE_GCC_AR} cr ${__output_base}.a ${__output_base}.o
+ COMMAND ${CMAKE_GCC_RANLIB} ${__output_base}.a
+ RESULT_VARIABLE __result
+ ERROR_QUIET
+ OUTPUT_QUIET
+)
+ endif()
+
+ if(${__result} STREQUAL 0)
+execute_process(
+ COMMAND ${CMAKE_COMMAND} -E echo void foo(); int main() {foo();}
+ COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -xc -
+-x none ${__output_base}.a -o ${__output_base}
+ RESULT_VARIABLE __result
+ ERROR_QUIET
+ OUTPUT_QUIET
+)
+ endif()
+
+ if(${__result} STREQUAL 0)
+set(__lto_found TRUE)
+ endif()
+
+ set(CMAKE_${lang}_PASSED_LTO_TEST
+${__lto_found} CACHE INTERNAL
+If the compiler passed a simple LTO test compile)
+endif()
+
+if(CMAKE_${lang}_PASSED_LTO_TEST)
+
+ set(CMAKE_${lang}_COMPILE_OPTIONS_IPO ${__lto_flags})
+
+ set(CMAKE_${lang}_ARCHIVE_CREATE_IPO
+${CMAKE_GCC_AR} cr TARGET LINK_FLAGS OBJECTS
+ )
+
+ set(CMAKE_${lang}_ARCHIVE_APPEND_IPO
+${CMAKE_GCC_AR} r TARGET LINK_FLAGS OBJECTS
+ )
+
+ set(CMAKE_${lang}_ARCHIVE_FINISH_IPO
+${CMAKE_GCC_RANLIB} TARGET
+ )
+endif()
+ endif()
endmacro()
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx
b/Source/cmMakefileLibraryTargetGenerator.cxx
index d6a0cd4..38d3c3c 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@ -140,11 +140,7 @@ void
cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules()
}
linkRuleVar += _CREATE_STATIC_LIBRARY;
- if(this-GetFeatureAsBool(INTERPROCEDURAL_OPTIMIZATION)
-
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7529-g99332a1
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 99332a16361aec03e7eec2eca6e5c533fc28f9a3 (commit)
via b78d74de64c989444210b203fb8f1183b2fd0929 (commit)
via d58280949745660508aa203335dca9b1368817fe (commit)
from 930141dec3c7814855b53dd5d79ce682bab73211 (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=99332a16361aec03e7eec2eca6e5c533fc28f9a3
commit 99332a16361aec03e7eec2eca6e5c533fc28f9a3
Merge: 930141d b78d74d
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Sat Feb 8 13:31:58 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 8 13:31:58 2014 -0500
Merge topic 'wix_desktop' into next
b78d74de CPackWiX: Add support for CPACK_CREATE_DESKTOP_LINKS
d5828094 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b78d74de64c989444210b203fb8f1183b2fd0929
commit b78d74de64c989444210b203fb8f1183b2fd0929
Author: Timo Rothenpieler b...@btbn.de
AuthorDate: Tue Feb 4 18:40:45 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Sat Feb 8 19:19:33 2014 +0100
CPackWiX: Add support for CPACK_CREATE_DESKTOP_LINKS
diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake
index ccc36eb..89547af 100644
--- a/Modules/CPack.cmake
+++ b/Modules/CPack.cmake
@@ -174,7 +174,7 @@
# create Start Menu shortcuts. For example, setting this to the list
# ccmake;CMake will create a shortcut named CMake that will execute the
# installed executable ccmake. Not all CPack generators use it (at least
-# NSIS and OSXX11 do).
+# NSIS, WIX and OSXX11 do).
#
# .. variable:: CPACK_STRIP_FILES
#
@@ -261,6 +261,8 @@
# .. variable:: CPACK_CREATE_DESKTOP_LINKS
#
# List of desktop links to create.
+# Each desktop link requires a corresponding start menu shortcut
+# as created by :variable:`CPACK_PACKAGE_EXECUTABLES`.
#=
# Copyright 2006-2009 Kitware, Inc.
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 998b5f1..43119d6 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -31,6 +31,12 @@
#include sys/types.h
#include sys/stat.h
+cmCPackWIXGenerator::cmCPackWIXGenerator():
+ HasDesktopShortcuts(false)
+{
+
+}
+
int cmCPackWIXGenerator::InitializeInternal()
{
componentPackageMethod = ONE_PACKAGE;
@@ -519,6 +525,11 @@ bool cmCPackWIXGenerator::CreateWiXSourceFiles()
CreateStartMenuFolder(directoryDefinitions);
}
+ if(this-HasDesktopShortcuts)
+{
+CreateDesktopFolder(directoryDefinitions);
+}
+
directoryDefinitions.EndElement(Directory);
directoryDefinitions.EndElement(Fragment);
@@ -733,10 +744,20 @@ bool cmCPackWIXGenerator::AddComponentsToFeature(
}
}
+ std::vectorstd::string cpackPackageDesktopLinksList;
+ const char *cpackPackageDesktopLinks =
+GetOption(CPACK_CREATE_DESKTOP_LINKS);
+ if(cpackPackageDesktopLinks)
+{
+ cmSystemTools::ExpandListArgument(cpackPackageDesktopLinks,
+cpackPackageDesktopLinksList);
+}
+
AddDirectoryAndFileDefinitons(
rootPath, INSTALL_ROOT,
directoryDefinitions, fileDefinitions, featureDefinitions,
-cpackPackageExecutablesList, shortcutMap);
+cpackPackageExecutablesList, cpackPackageDesktopLinksList,
+shortcutMap);
featureDefinitions.EndElement(FeatureRef);
@@ -750,6 +771,8 @@ bool cmCPackWIXGenerator::CreateStartMenuShortcuts(
cmWIXSourceWriter fileDefinitions,
cmWIXSourceWriter featureDefinitions)
{
+ bool thisHasDesktopShortcuts = false;
+
featureDefinitions.BeginElement(FeatureRef);
featureDefinitions.AddAttribute(Id, featureId);
@@ -797,6 +820,11 @@ bool cmCPackWIXGenerator::CreateStartMenuShortcuts(
fileDefinitions.AddAttribute(WorkingDirectory,
shortcut.workingDirectoryId);
fileDefinitions.EndElement(Shortcut);
+
+if (shortcut.desktop)
+ {
+thisHasDesktopShortcuts = true;
+ }
}
if(cpackComponentName.empty())
@@ -805,7 +833,8 @@ bool cmCPackWIXGenerator::CreateStartMenuShortcuts(
}
fileDefinitions.BeginElement(RemoveFolder);
- fileDefinitions.AddAttribute(Id, PROGRAM_MENU_FOLDER + idSuffix);
+ fileDefinitions.AddAttribute(Id,
+CM_REMOVE_PROGRAM_MENU_FOLDER + idSuffix);
fileDefinitions.AddAttribute(On, uninstall);
fileDefinitions.EndElement(RemoveFolder);
@@ -836,6 +865,56 @@ bool cmCPackWIXGenerator::CreateStartMenuShortcuts(
featureDefinitions.AddAttribute(Id, componentId);
[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1374-g1cc3e9f
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 1cc3e9f2e73b96370257b55f9c96586a898fe9a4 (commit) from d58280949745660508aa203335dca9b1368817fe (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=1cc3e9f2e73b96370257b55f9c96586a898fe9a4 commit 1cc3e9f2e73b96370257b55f9c96586a898fe9a4 Author: Kitware Robot kwro...@kitware.com AuthorDate: Sun Feb 9 00:01:05 2014 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sun Feb 9 00:01:05 2014 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 6e8329a..1e65e94 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 20140208) +set(CMake_VERSION_TWEAK 20140209) #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/cgi-bin/mailman/listinfo/cmake-commits
