Re: [cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
Stephen Kelly steveire@... writes: Matthew Woehlke wrote: Perhaps that is a misreading on my part, but I was getting the impression this change would make it so that imported targets can only ever be SYSTEM. I didn't really make that clear as the discussion developed, but yes, I think it makes sense to allow treating the include directories as non-system somehow, even if not by default. I've pushed the IMPORTED-target-SYSTEM-includes topic to my clone for review. It introduces a policy-controlled default handling of INTERFACE_INCLUDE_DIRECTORIES from IMPORTED targets as SYSTEM. It also introduces a default-initialized target property to get the opposite behavior in the cases where that is wanted. It also introduces a SYSTEM option to target_link_libraries because I'd already written the patch, but I'm not certain that's needed anymore. 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
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/29/2013 11:14 AM, Stephen Kelly wrote:
Another option would be not to have the VERSION in the signature, but
always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary
being run, so it relieves users of the need to additionally maintain the
VERSION here and figure out how that maps to their minimum cmake version.
A project may wish to update to a newer required CMake version for some
other feature but is not ready to port their header generation. We
could define the versions w.r.t. the CMake version and make VERSION
optional. If not present use CMAKE_MINIMUM_VERSION_REQUIRED. If
present then fail if VERSION is newer than CMAKE_MINIMUM_VERSION_REQUIRED.
I put an untested pseudo-code version of this in my compiler_features
branch. It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
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
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake. Otherwise I
wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in Modules/CompilerFeatures/${ID}-${LANG}.cmake
instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
We also need a plan to phase out support for ancient versions in the
future.
Any ideas on how to do that?
Perhaps we can document for each value of CMAKE_MINIMUM_VERSION_REQUIRED
the oldest VERSION value supported. That way it is up to the project
author to update VERSION and port code when bumping the minimum required
version of CMake. It will allow us to move forward but give projects
a long grace period.
-Brad
--
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] c++ feature detection and usage requirements
Brad King wrote:
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake.
Otherwise I wouldn't be able to check the MSVC features while using GNU.
Maybe they should be listed in
Modules/CompilerFeatures/${ID}-${LANG}.cmake instead?
Why do you need to check features of a compiler not currently enabled?
Without being enabled we don't even know what version of the other
compiler to check.
CMake has the information for all compilers, and the idea was to use that
information to generate a header for use with all of them.
Stephen Kelly wrote:
The header file would have the preprocessor tests and version checks for
the known compilers. That is, the generated header file would be the same
on all platforms, and would look something like qcompilerdetection.h, but
with a customizable prefix for the macros.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7655
However, thinking about it again, I think you're right that that is not
necessary. The built package and generated header is compiler/platform
specific anyway, unlike qcompilerdetection.h, which is a source file
identical in the packages for all platforms.
I thought the idea was to specify in target_compiler_features the
features needed so they would be published in the target interface.
Then whatever compiler is used can have its feature set tested against
the requirements. This would work both in-project and in consumers, no?
Yes, I went on something of a tangent here.
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
Re: [cmake-developers] c++ feature detection and usage requirements
On 08/30/2013 08:15 AM, Stephen Kelly wrote: However, thinking about it again, I think you're right that that is not necessary. Okay, it can always be factored out into separate files later anyway. I thought the idea was to specify in target_compiler_features the features needed so they would be published in the target interface. Then whatever compiler is used can have its feature set tested against the requirements. This would work both in-project and in consumers, no? Yes, I went on something of a tangent here. BTW, I think a better name may be language features rather than compiler features because we are declaring features of language versions and variants, not of the compilers. It is only in the implementation that we need to deal with compiler support for the features. -Brad -- 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] CMake 2.8.12-rc2 Released
The CMake 2.8.12 release candidate stream continues! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Some of the notable changes in this release are: - Introduced target_compile_options command - Specify compile options to use when compiling a given target. Supports PUBLIC, PRIVATE, and INTERFACE options. PRIVATE and PUBLIC items will populate the COMPILE_OPTIONS property of the target. PUBLIC and INTERFACE items will populate the INTERFACE_COMPILE_OPTIONS property of the target. Supports generator expressions. - Introduced add_compile_options command - Adds options to the compiler command line for sources in the current directory and below. Supports generator expressions. - Introduced CMake Policy 21: - It is now an error to add relative paths to the INCLUDE_DIRECTORIES target property. - Introduced CMake Policy 22: - Target properties matching (IMPORTED_)LINK_INTERFACE_LIBRARIES(_CONFIG) are ignored, and will no longer be populated by the target_link_libraries command. It is now an error to populate the properties directly in user code. Instead use the INTERFACE keyword with target_link_libraries, or the target property INTERFACE_LINK_LIBRARIES. - Introduced CMake Policy 23: - Plain and keyword target_link_libraries signatures cannot be mixed for a given target when this policy is enabled. Once PUBLIC,PRIVATE, or INTERFACE keywords are used, all subsequent target_link_libraries calls to the target must use one of these keywords. - Introduced: Support for RPATH under OSX - Please see the blog post by Clinton Stimpson about using RPATH on OSX (http://www.kitware.com/blog/home/post/510) - CMake: New PUBLIC PRIVATE and INTERFACE options for target_link_libraries - CMake: New ALIAS targets feature - CMake: Automatically process Headers directory of Apple Frameworks as a usage requirement - CMake: File command now supports the GENERATE command to produce files at generate time - CMake: target_include_directories now supports the SYSTEM parameter - CMake: Add support for Java in cross compilation toolchains - CMake: Improved support for the IAR toolchain - CMake: Improved support for the ARM toolchain under Visual Studio - CMake: Improvements to the Visual Studio Generators Including - Separate compiler and linker PDB files - Support for subdirectory MSBuild projects - Support for assembly code to VS10 - Support for Windows CE to VS11 - CMake: Added COMPILE_OPTIONS target property. - CMake: Added INTERFACE_LINK_LIBRARIES added as a property to targets - CMake: Now supports .zip files with the tar command - CMake: try_compile now supports multiple source files - CMake: Optimized custom command dependency lookup - CMake: Removal of configured files will retrigger CMake when issuing a build command - CMake: Ninja now tracks custom command generated files that aren't listed as output - CMake: Added generator expression support for compiler versions - CMake-Gui: Add search functions for Output window - CTest: Improved memory checker support - FindGTK2: General Improvements - FindCUDA: Multiple improvements to the custom commands The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=112 The complete list of changes in this rc since the previous release can be found at: http://www.cmake.org/Wiki/CMake/ChangeLog Thanks -- 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] CMake Code Beautifier
Hi We have environment in which we are maintain bunch of cmake scripts as separate component. Since the bunch of script is used by other developers it's growing quite fast. I'm looking for any CMake script code beautifier so others can easily read it ? Anyone know such a one ? BR, Tomasz -- Pozdrawiam/Best regards/Mit freundlichen Grüßen, Tomasz Majchrowski, Information Technology and Services Consultant and Contractor -- 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 with Team Foundation Server?
Thank you both, Fabian and Petr, for your responses. I haven't had time to experiment with your suggestions yet, but at first glance this is extremely valuable information. -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-with-Team-Foundation-Server-tp7585293p7585310.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
[CMake] ERROR when trying to Configure CMake
Hello, I'm getting an error when I try to Configure CMake. This is the error: CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindQt4.cmake:1382 (message): Found unsuitable Qt version from NOTFOUND, this code requires Qt 4.x Call Stack (most recent call first): CMakeModules/ODQtUtils.cmake:32 (FIND_PACKAGE) CMakeLists.txt:38 (OD_INIT_QT) I do have a Qt version 4.x installed here. But the installer can't find it. What I have to do? -- View this message in context: http://cmake.3232098.n2.nabble.com/ERROR-when-trying-to-Configure-CMake-tp7585311.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
[CMake] Building on Windows, with NMake, without Unicode Support
I can't figure out how to get CMake to build my code with setting -D_UNICODE
and -DUNICODE. I don't want those manifest constants set, but they appear in
the generated DependInfo.cmake files when generating code for NMake Makefiles:
SET(CMAKE_CXX_COMPILER_ID MSVC)
# Preprocessor definitions for this target.
SET(CMAKE_TARGET_DEFINITIONS
NT
_UNICODE
UNICODE
_CRT_SECURE_NO_WARNINGS
_SCL_SECURE_NO_WARNINGS
NOMINMAX
NT
WIN32_LEAN_AND_MEAN
)
The definitions following those for Unicode are from this command in my
CMakeLists.txt:
add_definitions(
/D_CRT_SECURE_NO_WARNINGS
/D_SCL_SECURE_NO_WARNINGS
/DNOMINMAX
/DNT
/DWIN32_LEAN_AND_MEAN)
I've tried every which way I can think of to remove those definitions, but
nothing has worked:
- get_target_property() finds nothing for COMPILE_DEFINITIONS or DEFINITIONS.
- add_definitions(/U_UNICODE /UUNICODE) doesn't work because those precede the
-D_UNICODE -DUNICODE arguments generated by the above. (CMake helpfully sorts
the flags, it seems. That's a bug, if you ask me. Order dependent flags, at
least, should appear in the order the user gives them.)
- set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /U_UNICODE /UUNICODE) doesn't work.
(I could probably force an update to the cache, but then that would apply
globally and not to the current project.
How can I convince CMake to remove those definitions from my builds?
_
Rob Stewart
Software Engineer
Dev Tools Components
Susquehanna International Group, LLP
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
--
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] Possible FindQt issue with CMake 2.8.12-rc1? (And Freetype / GTK issues in 'next' ... )
I'm using CMake 2.8.12-rc1, and configuring a build tree for the CMake source (master, at commit 452882eb). On second and later incremental cmake runs, I'm getting this cmake output: C:\dev\...\cmake-buildcmake . -- Found unsuitable Qt version from NOTFOUND -- Configuring done -- Generating done -- Build files have been written to: ... Is this an expected message now, when I have no Qt on the machine? Seems like an odd way to phrase it... Perhaps Qt not found would be better? This seems to be a newly introduced FindQt issue. Also, building cmake 'next' and using it to configure itself demonstrates the same issue. In fact, using 'next' to configure itself is a little bit worse, with extra chatter about FreeType and GTK as well: -- Found unsuitable Qt version from NOTFOUND -- Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS) -- Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY GTK2_GTK_INCLUDE_DIR GTK2_GDK_INCLUDE_DI R GTK2_GDKCONFIG_INCLUDE_DIR GTK2_GDK_LIBRARY GTK2_GLIB_INCLUDE_DIR GTK2_GLIBCONFIG_INCLUDE_DIR GTK2_GLIB_LIBRARY) -- Configuring done -- Generating done -- Build files have been written to: ... Thanks, 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] Building on Windows, with NMake, without Unicode Support
Bill Hoffman wrote: On 8/30/2013 2:57 PM, Stewart, Robert wrote: I can't figure out how to get CMake to build my code with setting -D_UNICODE and -DUNICODE. I don't want those manifest constants set, but they appear in the generated DependInfo.cmake files when generating code for NMake Makefiles: I just did a git grep in the cmake source tree, and I don't think UNICODE is being defined by CMake. Is your project open source? Can you grep in your source tree for UNICODE? I had searched before, but I missed a directory, for part of the build environment, that I picked up from someone else. That code was setting it before mine. Sorry for the noise. The argument reordering remains an issue. The following commands: add_definitions(-DUNICODE) add_definitions(-UUNICODE) should produce the following on the command line: -DUNICODE -UUNICODE Instead, I see the following: -UUNICODE -DUNICODE That's wrong. CMake should honor the order in which the definitions are set, at least when order matters. _ Rob Stewart Software Engineer Dev Tools Components Susquehanna International Group, LLP IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Building on Windows, with NMake, without Unicode Support
On 8/30/2013 2:57 PM, Stewart, Robert wrote: I can't figure out how to get CMake to build my code with setting -D_UNICODE and -DUNICODE. I don't want those manifest constants set, but they appear in the generated DependInfo.cmake files when generating code for NMake Makefiles: I just did a git grep in the cmake source tree, and I don't think UNICODE is being defined by CMake. Is your project open source? Can you grep in your source tree for UNICODE? -Bill -- 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] ERROR when trying to Configure CMake
On Friday 30 August 2013, Rikkin wrote: Hello, I'm getting an error when I try to Configure CMake. This is the error: CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindQt4.cmake:1382 (message): Found unsuitable Qt version from NOTFOUND, this code requires Qt 4.x This message looks a bit strange... Call Stack (most recent call first): CMakeModules/ODQtUtils.cmake:32 (FIND_PACKAGE) CMakeLists.txt:38 (OD_INIT_QT) I do have a Qt version 4.x installed here. But the installer can't find it. What I have to do? For Qt, set the cmake variable QT_QMAKE_EXECUTABLE to the qmake.exe of teh Qt you want to use. Or, as a more general solution, set the CMAKE_PREFIX_PATH environment variable so that it includes the base install directory of Qt. Alex -- 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 Code Beautifier
On 8/30/2013 10:06 AM, Tomasz Majchrowski wrote: Hi We have environment in which we are maintain bunch of cmake scripts as separate component. Since the bunch of script is used by other developers it's growing quite fast. I'm looking for any CMake script code beautifier so others can easily read it ? Anyone know such a one ? BR, Tomasz I use the emacs mode to reformat CMake code. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] Possible FindQt issue with CMake 2.8.12-rc1? (And Freetype / GTK issues in 'next' ... )
In fact, using 'next' to configure itself is a little bit worse, with extra chatter about FreeType and GTK as well: -- Found unsuitable Qt version from NOTFOUND -- Configuring done -- Generating done -- Build files have been written to: ... Never mind on the Freetype / GTK report. That was pilot error. (I was not running cmake 'next' when I saw those I was running 2.8.12-rc1 against 'next') However the FindQt message is still in 'next' -- and strange in my opinion. -- 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] Possible FindQt issue with CMake 2.8.12-rc1? (And Freetype / GTK issues in 'next' ... )
However the FindQt message is still in 'next' -- and strange in my opinion. One more addendum: This is the output when configuring with CMake 2.8.10.2: -- Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE QT_UIC_EXECUTABLE QT_INCLUDE_DI R QT_LIBRARY_DIR QT_QTCORE_LIBRARY) It was actually introduced in CMake 2.8.11.2...: -- Found unsuitable Qt version from NOTFOUND D -- 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] set_directory_properties() Isn't
I'm effectively doing the following, with CMake 2.8, but it doesn't work. What am I missing? get_directory_property(before DEFINITIONS) set_directory_properties(PROPERTIES DEFINITIONS -DFOO) get_directory_property(after DEFINITIONS) before and after are the same, and before isn't -DFOO. _ Rob Stewart Software Engineer Dev Tools Components Susquehanna International Group, LLP IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] CMake 2.8.12-rc2 Released
The CMake 2.8.12 release candidate stream continues! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Some of the notable changes in this release are: - Introduced target_compile_options command - Specify compile options to use when compiling a given target. Supports PUBLIC, PRIVATE, and INTERFACE options. PRIVATE and PUBLIC items will populate the COMPILE_OPTIONS property of the target. PUBLIC and INTERFACE items will populate the INTERFACE_COMPILE_OPTIONS property of the target. Supports generator expressions. - Introduced add_compile_options command - Adds options to the compiler command line for sources in the current directory and below. Supports generator expressions. - Introduced CMake Policy 21: - It is now an error to add relative paths to the INCLUDE_DIRECTORIES target property. - Introduced CMake Policy 22: - Target properties matching (IMPORTED_)LINK_INTERFACE_LIBRARIES(_CONFIG) are ignored, and will no longer be populated by the target_link_libraries command. It is now an error to populate the properties directly in user code. Instead use the INTERFACE keyword with target_link_libraries, or the target property INTERFACE_LINK_LIBRARIES. - Introduced CMake Policy 23: - Plain and keyword target_link_libraries signatures cannot be mixed for a given target when this policy is enabled. Once PUBLIC,PRIVATE, or INTERFACE keywords are used, all subsequent target_link_libraries calls to the target must use one of these keywords. - Introduced: Support for RPATH under OSX - Please see the blog post by Clinton Stimpson about using RPATH on OSX (http://www.kitware.com/blog/home/post/510) - CMake: New PUBLIC PRIVATE and INTERFACE options for target_link_libraries - CMake: New ALIAS targets feature - CMake: Automatically process Headers directory of Apple Frameworks as a usage requirement - CMake: File command now supports the GENERATE command to produce files at generate time - CMake: target_include_directories now supports the SYSTEM parameter - CMake: Add support for Java in cross compilation toolchains - CMake: Improved support for the IAR toolchain - CMake: Improved support for the ARM toolchain under Visual Studio - CMake: Improvements to the Visual Studio Generators Including - Separate compiler and linker PDB files - Support for subdirectory MSBuild projects - Support for assembly code to VS10 - Support for Windows CE to VS11 - CMake: Added COMPILE_OPTIONS target property. - CMake: Added INTERFACE_LINK_LIBRARIES added as a property to targets - CMake: Now supports .zip files with the tar command - CMake: try_compile now supports multiple source files - CMake: Optimized custom command dependency lookup - CMake: Removal of configured files will retrigger CMake when issuing a build command - CMake: Ninja now tracks custom command generated files that aren't listed as output - CMake: Added generator expression support for compiler versions - CMake-Gui: Add search functions for Output window - CTest: Improved memory checker support - FindGTK2: General Improvements - FindCUDA: Multiple improvements to the custom commands The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=112 The complete list of changes in this rc since the previous release can be found at: http://www.cmake.org/Wiki/CMake/ChangeLog Thanks -- 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 Code Beautifier
On 2013-08-30 15:50-0400 Bill Hoffman wrote: On 8/30/2013 10:06 AM, Tomasz Majchrowski wrote: Hi We have environment in which we are maintain bunch of cmake scripts as separate component. Since the bunch of script is used by other developers it's growing quite fast. I'm looking for any CMake script code beautifier so others can easily read it ? Anyone know such a one ? BR, Tomasz I use the emacs mode to reformat CMake code. I use that as well, but the problem is that appears to be the only choice and some developers (although very few, of course :-) ) don't use emacs. Seriously, though I wonder if something like uncrustify (which currently has many powerful features to beautify C, C++, C#, D, Java and Pawn) could be adapted to provide a standalone CMake code beautifier. We use uncrustify to keep PLplot C, C++, D, and Java code beautified, and it works great for those so I would welcome an extension of uncrustify to also beautify CMake code (although I don't have time to work on such an uncrustify extension myself). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] set_directory_properties() Isn't
Hi Rob, The DEFINITIONS directory property is read-only. COMPILE_DEFINITIONS or the configuration-specific versions are mutable I believe. Cheers, Fraser. On 30/08/2013 22:30, Stewart, Robert wrote: I'm effectively doing the following, with CMake 2.8, but it doesn't work. What am I missing? get_directory_property(before DEFINITIONS) set_directory_properties(PROPERTIES DEFINITIONS -DFOO) get_directory_property(after DEFINITIONS) before and after are the same, and before isn't -DFOO. _ Rob Stewart Software Engineer Dev Tools Components Susquehanna International Group, LLP IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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 -- 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] set_directory_properties() Isn't
Fraser Hutchison wrote: On 30/08/2013 22:30, Stewart, Robert wrote: I'm effectively doing the following, with CMake 2.8, but it doesn't work. What am I missing? get_directory_property(before DEFINITIONS) set_directory_properties(PROPERTIES DEFINITIONS -DFOO) get_directory_property(after DEFINITIONS) before and after are the same, and before isn't -DFOO. The DEFINITIONS directory property is read-only. COMPILE_DEFINITIONS or the configuration-specific versions are mutable I believe. Thanks! That worked. Why doesn't CMake generate an error when one tries to set a read-only property! Indeed, the error message should say which property to set. _ Rob Stewart Software Engineer Dev Tools Components Susquehanna International Group, LLP IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] CMAKE_FRAMEWORK_SYSTEM_FLAG_CXX?
Hi all I'd like to change -Fpath to -iframework path (or -iframework path.) With non-frameworks code, CMAKE_INCLUDE_SYSTEM_FLAG_CXX can be set to -isystem, so system includes are being included via -isystem path instead of -I path. Is there any such option for frameworks? Mihai smime.p7s Description: S/MIME Cryptographic Signature -- 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] Resetting cmake variables
I am trying to build traverso-daw. In CMakeLists.txt file, wavpack.h was edited to use the full path; however, when trying this with the vorbis/vorbisfile.h, the path was ignored. Yes, I am quite aware that this is not the traverso mailing list; yet, at the same time, I need to be able to unravel cmake and re-edit the input variables. -- 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.11.2-4056-g0570e2d
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 0570e2d1470add3f03b0dfdec7532092b8317079 (commit)
via bb501a2a648f4c2e2dd008b925b87b575b4e2cf1 (commit)
from a4bb7f463a9b0ea19a27955b461d0a63f468fce9 (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=0570e2d1470add3f03b0dfdec7532092b8317079
commit 0570e2d1470add3f03b0dfdec7532092b8317079
Merge: a4bb7f4 bb501a2
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 30 07:12:36 2013 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 30 07:12:36 2013 -0400
Merge topic 'add-find_dependency-macro' into next
bb501a2 CMakePackageConfigHelpers: Add a find_dependency macro
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb501a2a648f4c2e2dd008b925b87b575b4e2cf1
commit bb501a2a648f4c2e2dd008b925b87b575b4e2cf1
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 30 12:59:42 2013 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 30 13:03:10 2013 +0200
CMakePackageConfigHelpers: Add a find_dependency macro
This macro handles the EXACT, REQUIRED and QUIET options
and sets an appropriate NOT_FOUND_MESSAGE for the package
if a dependency is not found.
diff --git a/Modules/CMakePackageConfigHelpers.cmake
b/Modules/CMakePackageConfigHelpers.cmake
index d042d5e..3c56b7f 100644
--- a/Modules/CMakePackageConfigHelpers.cmake
+++ b/Modules/CMakePackageConfigHelpers.cmake
@@ -3,7 +3,8 @@
#CONFIGURE_PACKAGE_CONFIG_FILE(input output INSTALL_DESTINATION path
# [PATH_VARS var1 var2
... varN]
# [NO_SET_AND_CHECK_MACRO]
-#
[NO_CHECK_REQUIRED_COMPONENTS_MACRO])
+#
[NO_CHECK_REQUIRED_COMPONENTS_MACRO]
+# [NO_FIND_DEPENDENCY_MACRO])
#
# CONFIGURE_PACKAGE_CONFIG_FILE() should be used instead of the plain
# configure_file() command when creating the NameConfig.cmake or
Name-config.cmake
@@ -154,7 +155,7 @@ endmacro()
function(CONFIGURE_PACKAGE_CONFIG_FILE _inputFile _outputFile)
- set(options NO_SET_AND_CHECK_MACRO NO_CHECK_REQUIRED_COMPONENTS_MACRO)
+ set(options NO_SET_AND_CHECK_MACRO NO_CHECK_REQUIRED_COMPONENTS_MACRO
NO_FIND_DEPENDENCY_MACRO)
set(oneValueArgs INSTALL_DESTINATION )
set(multiValueArgs PATH_VARS )
@@ -240,6 +241,40 @@ endmacro()
)
endif()
+ if(NOT CCF_NO_FIND_DEPENDENCY_MACRO)
+set(PACKAGE_INIT ${PACKAGE_INIT}
+macro(find_dependency dep)
+ if (NOT \${dep}_FOUND)
+if (\${ARGV1})
+ set(version \${ARGV1})
+endif()
+set(exact_arg)
+if(\${CMAKE_FIND_PACKAGE_NAME}_FIND_VERSION_EXACT)
+ set(exact_arg EXACT)
+endif()
+set(quiet_arg)
+if(\${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY)
+ set(quiet_arg QUIET)
+endif()
+set(required_arg)
+if(\${CMAKE_FIND_PACKAGE_NAME}_FIND_REQUIRED)
+ set(required_arg REQUIRED)
+endif()
+
+find_package(\${dep} \${version} \${exact_arg} \${quiet_arg}
\${required_arg})
+if (NOT \${dep}_FOUND)
+ set(\${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
\\${CMAKE_FIND_PACKAGE_NAME} could not be found because dependency \${dep}
could not be found.\)
+ set(\${CMAKE_FIND_PACKAGE_NAME}_FOUND False)
+ return()
+endif()
+set(required_arg)
+set(quiet_arg)
+set(exact_arg)
+ endif()
+endmacro()
+)
+ endif()
+
set(PACKAGE_INIT ${PACKAGE_INIT}
)
---
Summary of changes:
Modules/CMakePackageConfigHelpers.cmake | 39 +-
1 files changed, 37 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.11.2-814-gb62042d
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 b62042dbfb422563dc9a240bd89efc28de8e4b17 (commit) via 5e15f398860712930387b78e36a7ae5ab8a9b775 (commit) from b6fe422a4c0e48d6ae10a5a44892bdac5146acdb (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=b62042dbfb422563dc9a240bd89efc28de8e4b17 commit b62042dbfb422563dc9a240bd89efc28de8e4b17 Merge: b6fe422 5e15f39 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 30 08:09:39 2013 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Aug 30 08:09:39 2013 -0400 Merge topic 'normalize-system-includes-check' 5e15f39 Normalize system directories from the interface target property --- Summary of changes: Source/cmGeneratorTarget.cxx |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.11.2-816-g452882e
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 452882ebeb032b25a08d35f2b2df3a785093ca6c (commit) via 782eba3a0c74009e24708d28fd520b1ba919d326 (commit) from b62042dbfb422563dc9a240bd89efc28de8e4b17 (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=452882ebeb032b25a08d35f2b2df3a785093ca6c commit 452882ebeb032b25a08d35f2b2df3a785093ca6c Merge: b62042d 782eba3 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 30 08:10:35 2013 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Aug 30 08:10:35 2013 -0400 Merge topic 'ctest-gtm-coverage-fileoffset-bug' 782eba3 CTest: Fix GTM coverage parsing line offset bug --- Summary of changes: Source/CTest/cmParseGTMCoverage.cxx |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.11.2-4060-g5448723
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 5448723ee0ac88ef1f215e41a12c5d15558978aa (commit) via 452882ebeb032b25a08d35f2b2df3a785093ca6c (commit) via b62042dbfb422563dc9a240bd89efc28de8e4b17 (commit) via b6fe422a4c0e48d6ae10a5a44892bdac5146acdb (commit) from 0570e2d1470add3f03b0dfdec7532092b8317079 (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=5448723ee0ac88ef1f215e41a12c5d15558978aa commit 5448723ee0ac88ef1f215e41a12c5d15558978aa Merge: 0570e2d 452882e Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 30 08:09:45 2013 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Aug 30 08:09:45 2013 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v2.8.11.2-819-gab9c7e3
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, release has been updated via ab9c7e36e598eb2fae3f3ee67c99c4afee7b8411 (commit) via 90b51230d93eef07e16000c6bdfe2eb0cef65a82 (commit) via 452882ebeb032b25a08d35f2b2df3a785093ca6c (commit) via b62042dbfb422563dc9a240bd89efc28de8e4b17 (commit) via b6fe422a4c0e48d6ae10a5a44892bdac5146acdb (commit) via 549b95f115d1f98a68ed390816d5ac9e1eb38806 (commit) via 782eba3a0c74009e24708d28fd520b1ba919d326 (commit) via ddff7ae0ceb4b77448c8780b8e45f4012131572c (commit) via 5e15f398860712930387b78e36a7ae5ab8a9b775 (commit) via 4e7a4a0453f1bd7264d414e6f5b62ff61b0d2396 (commit) via 0264eec9d32200c692ddfb756871ac4a4465863c (commit) via b6f6802b3d0dc1a9ab7beb62a17bd0651d87a64f (commit) via 3580b9f338398c74575be56e98299361cd985a09 (commit) via 150bc7da3dba160acab5cb11387c9a29255973ac (commit) via 15d98a42fd2b7cadfdbc9268da3c79f389c5a3cc (commit) via b15ad0d1de7524be3b32d6691b68d3578ee00ca5 (commit) via 23b88ecd8580670d6ecefade583ed2db39a74f74 (commit) via fd09fd78a902086410852229f7609edbe3874d9f (commit) via 9b2940875e51457c77dd946b18b1314a6904454d (commit) via ae4630fb1dd2f5d51f9fbea7007336af07eb83c9 (commit) via df62f64db72b6f00657e9e739e1e117639dea9da (commit) via c5baca780472a6e2ec1615bed2619be98482b992 (commit) via cc8f79670e6c6533a76b80656c87342c0c1696a4 (commit) via fd4fb9ef040dde7961500e2241b43909a9e6b1a4 (commit) via 889527aa9cd9f2b69d429ed766926105242fb0a8 (commit) via 4d5d8df0cdd1d413853a0e8b64b20a8e63c05230 (commit) via 757de2bb784789caab5e0a5498b1321814c16a65 (commit) via 4923c6c724ffa64043d1bac5ec148e8d01f5d02a (commit) via 32ea090a70a2d5cc8fbcfe2511492f74e97f7dff (commit) via 3064f80d254fae7ce395bbd744133a53b11170f9 (commit) via 141ce010621319f9b5e54d41b3b34cd05da63374 (commit) via 464456646fbb4e7500ef4b982a3ed9317493f565 (commit) via beffeb1ffe474870c09630dcd7a801d2a27b86b3 (commit) via eef6df5c7d97680f9c20729555c061cf3e2b2482 (commit) via 898d920d54ed2f0520f97b8221575769b25da2f1 (commit) via b864a5396a1abd22f995c3b376ff2021a8cd4d4e (commit) via 374af6529a08fc1c9c9c16e5d55929c450db6e35 (commit) via 78cd8842966efb6d54668d47ee92bdeed35cc79e (commit) via 7324eb896eb7337aaec2baf44d11d419a9d87b30 (commit) via d7c9d60d9fa552a22944d9a912dd61539e012102 (commit) via 56cf74e73446f61b9ac84837931ea79c8e90d42c (commit) via 79af005cf8d58575315916c24d8cd518065ab3c2 (commit) via 10ad7e458c5eaffb090068a62cf6c4d1eb2df6a6 (commit) via 2dce48ff80dd77bd788952b10a481aa90dfad20e (commit) via 31719643c5ae54c063a50938a467f3cfc8e0d7df (commit) via 807a564e7a123f139770406d2c4a02d062be28c6 (commit) via 293ecfeb79f9c0ac3e9018fa66d7cc944b9a21d9 (commit) via 5803b94a8b11b89d81f5492891430e2d55723346 (commit) from 330db97e64e9e370ecf636aae2275044286537bf (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=ab9c7e36e598eb2fae3f3ee67c99c4afee7b8411 commit ab9c7e36e598eb2fae3f3ee67c99c4afee7b8411 Author: Robert Maynard robert.mayn...@kitware.com AuthorDate: Fri Aug 30 09:28:27 2013 -0400 Commit: Robert Maynard robert.mayn...@kitware.com CommitDate: Fri Aug 30 11:52:13 2013 -0400 CMake 2.8.12-rc2 diff --git a/ChangeLog.manual b/ChangeLog.manual index d8f33e2..bc56e8f 100644 --- a/ChangeLog.manual +++ b/ChangeLog.manual @@ -1,3 +1,39 @@ +Changes in CMake 2.8.12-rc2 (since 2.8.12-rc1) +-- +Brad King (2): + Fix RunCMake.Configure test expectation newline matching + Clean up install rules of CMake itself (#14371) + +Clinton Stimpson (1): + OSX: Allow an empty INSTALL_NAME_DIR to override MACOSX_RPATH. + +Eric Bélanger (1): + FindImageMagick: Find libraries named with HDRI support (#14348) + +Raphael Kubo da Costa (1): + FindTCL: Add BSD paths for Tcl/Tk 8.6 + +Robert Maynard (2): + VS: Generate ToolsVersion matching each VS version + cmMakefile: Do not track configured files known to be temporary + +Rolf Eike Beer (1): + CheckC*CompilerFlag: add documentation what to expect from a positive result + +Stephen Kelly (6): + Fix OLD behavior of CMP0021. + try_compile: Extract IMPORTED targets from LINK_DEPENDENT_LIBRARIES + try_compile: Extract IMPORTED targets from INTERFACE_LINK_LIBRARIES + Genex: Fix evaluation of MAP_IMPORTED_CONFIG_CONFIG +
[Cmake-commits] CMake branch, next, updated. v2.8.11.2-4062-g03556af
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 03556af64277597a98025d2e638b01f54a215bb6 (commit)
via b49472264213b2d829e7c6d118660190f5238a14 (commit)
from 5448723ee0ac88ef1f215e41a12c5d15558978aa (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=03556af64277597a98025d2e638b01f54a215bb6
commit 03556af64277597a98025d2e638b01f54a215bb6
Merge: 5448723 b494722
Author: David Cole dc...@neocisinc.com
AuthorDate: Fri Aug 30 10:48:25 2013 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 30 10:48:25 2013 -0400
Merge topic 'add-policy-version-test' into next
b494722 Tests: Verify policies are introduced only in official versions
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b49472264213b2d829e7c6d118660190f5238a14
commit b49472264213b2d829e7c6d118660190f5238a14
Author: David Cole dc...@neocisinc.com
AuthorDate: Tue Aug 27 23:47:36 2013 -0400
Commit: David Cole dc...@neocisinc.com
CommitDate: Wed Aug 28 17:22:49 2013 -0400
Tests: Verify policies are introduced only in official versions
Add the CMake.PolicyCheck test.
This test uses git grep to look for policies added in a dated
version of CMake. It will fail if a policy is added as of,
for example, CMake 2.8.11.20130828.
The intent is to prevent such constructs from making it into an
official release. Three instances actually appeared in the first
attempted release candidate for 2.8.12.
This test may sometimes yield false positives. After all, it's just
using a regular expression to detect this condition, and something
in a comment could possibly match it. As of right now, that's not
true, but it's easy to imagine such a comment being added.
The new test may also not catch all future problems of this sort.
However, it will catch problems of this sort for all code that follows
the present layout style in Source/cmPolicies.cxx.
diff --git a/Tests/CMakeTests/CMakeLists.txt b/Tests/CMakeTests/CMakeLists.txt
index 344b772..4c49c6a 100644
--- a/Tests/CMakeTests/CMakeLists.txt
+++ b/Tests/CMakeTests/CMakeLists.txt
@@ -55,6 +55,15 @@ set(GetPrerequisites_PreArgs
)
AddCMakeTest(GetPrerequisites ${GetPrerequisites_PreArgs})
+if(GIT_EXECUTABLE)
+ set(PolicyCheck_PreArgs
+-DCMake_BINARY_DIR:PATH=${CMake_BINARY_DIR}
+-DCMake_SOURCE_DIR:PATH=${CMake_SOURCE_DIR}
+-DGIT_EXECUTABLE:STRING=${GIT_EXECUTABLE}
+)
+ AddCMakeTest(PolicyCheck ${PolicyCheck_PreArgs})
+endif()
+
# Run CheckSourceTree as the very last test in the CMake/CTest/CPack test
# suite. It detects if any changes have been made to the CMake source tree
# by any previous configure, build or test steps.
diff --git a/Tests/CMakeTests/PolicyCheckTest.cmake.in
b/Tests/CMakeTests/PolicyCheckTest.cmake.in
new file mode 100644
index 000..416dc0a
--- /dev/null
+++ b/Tests/CMakeTests/PolicyCheckTest.cmake.in
@@ -0,0 +1,154 @@
+# Check the CMake source tree for suspicious policy introdcutions...
+#
+message(=)
+message(CTEST_FULL_OUTPUT (Avoid ctest truncation of output))
+message()
+message(CMake_BINARY_DIR='${CMake_BINARY_DIR}')
+message(CMake_SOURCE_DIR='${CMake_SOURCE_DIR}')
+message(GIT_EXECUTABLE='${GIT_EXECUTABLE}')
+message()
+
+
+# If this does not appear to be a git checkout, just pass the test here
+# and now. (Do not let the test fail if it is run in a tree *exported* from a
+# repository or unpacked from a .zip file source installer...)
+#
+set(is_git_checkout 0)
+if(EXISTS ${CMake_SOURCE_DIR}/.git)
+ set(is_git_checkout 1)
+endif()
+
+message(is_git_checkout='${is_git_checkout}')
+message()
+
+if(NOT is_git_checkout)
+ message(source tree is not a git checkout... test passes by early
return...)
+ return()
+endif()
+
+# If no GIT_EXECUTABLE, see if we can figure out which git was used
+# for the ctest_update step on this dashboard...
+#
+if(is_git_checkout AND NOT GIT_EXECUTABLE)
+ set(ctest_ini_file )
+ set(exe )
+
+ # Use the old name:
+ if(EXISTS ${CMake_BINARY_DIR}/DartConfiguration.tcl)
+set(ctest_ini_file ${CMake_BINARY_DIR}/DartConfiguration.tcl)
+ endif()
+
+ # But if it exists, prefer the new name:
+ if(EXISTS ${CMake_BINARY_DIR}/CTestConfiguration.ini)
+set(ctest_ini_file ${CMake_BINARY_DIR}/CTestConfiguration.ini)
+ endif()
+
+ # If there is a ctest ini file, read the update command or git command
+ # from it:
+ #
+ if(ctest_ini_file)
+file(STRINGS ${ctest_ini_file} line REGEX ^GITCommand: (.*)$)
+string(REGEX
[Cmake-commits] CMake branch, master, updated. v2.8.11.2-817-gce6c736
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 ce6c7366f77d019d4a04c0e55199b568098a5adb (commit) from 452882ebeb032b25a08d35f2b2df3a785093ca6c (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=ce6c7366f77d019d4a04c0e55199b568098a5adb commit ce6c7366f77d019d4a04c0e55199b568098a5adb Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat Aug 31 00:01:11 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat Aug 31 00:01:11 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 92c9618..14dece6 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 11) -set(CMake_VERSION_TWEAK 20130830) +set(CMake_VERSION_TWEAK 20130831) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
