Re: [cmake-developers] push of LinkOptionsCommand topic branch
Steve Wilson wrote: On Feb 6, 2014, at 3:56 PM, Stephen Kelly steve...@gmail.com wrote: There are a few things I'd like to touch up a bit. How comfortable are you with git? Would it cause problems for you if I force push your branch, or would you know how to handle that? Do you have further local changes? I’m a relative git newbie. I can get around ok and am learning a bunch as I go. The term ‘force push’ isn’t familiar though so I’m afraid you’ll have to explain (or I can look it up). I do not have any more local changes. I’ve switched to working on a different feature. Ok, I'll not force push it yet but will do that later and tell you what you need to do in reaction then. You still have extra dashes in the titles in the target property documentation. Please also rebase to master. The documentation has been updated to add more relevant links, markup etc. Please follow the same patterns in all the new docs on your branch. Note also that your add_link_options doc copied some content from add_compile_commands without modifying it (re include directories). Here's some guidance Brad gave me a while ago regarding writing commit messages with an imperative mood: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6904 The new tests look good to me. Please use spaces not tabs in foo.cpp in the add_link_options test. You also add a foo.cpp in the target_link_options test, but it has no content. Is that deliberate, or should it be the same as the other? In the 'cmLocalGenerator: Add AddLinkOptions method for LINK_FLAGS.' commit message, you mention that the differences regarding static and object libraries from the xcode generator are included. You don't say what impact that has on other generators though. Were the other generators buggy by not doing the same thing before? Or was the xcode generator special for needing this? If the xcode generator has a special need, then that snippet should stay in the xcode generator, right? 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] Request for review of topic intel-visibility
CMAKE_LANG_COMPILE_OPTIONS_VISIBILITY is being set up for the Intel compiler in general but the -fvisibility option is not supported on Windows and will result in compiler warnings. I set up the intel-visibility topic which moves the option into the Windows and Darwin specific Platform files. 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
[cmake-developers] CMake adds libgcc_eh.a to the linker line on AIX
Hi I'm building binaries for AIX using GCC and native ld (also testing with GCC cross-compiler with GNU binutils) and I get issues with exceptions not being caught like they should. I'm linking a number of static C and C++ archives into several binaries and I notice that under certain conditions CMake adds libgcc_eh.a to the linker line. It actually appears twice in between target_link_libraries libs and the RPATH section at the end. Something like this: c++ -g object_files -o executable -Wl,-brtl,-bexpall \ link_libraries \ full_path_to/libgcc_eh.a \ full_path_to/libgcc_eh.a \ -Wl,-blibpath:rpath If I manually add libsupc++.a to the linker line my program links and runs correctly, BUT if I strip both libgcc_eh.a and libsupc++.a from the linker command it also links and runs correctly. Since supc++ is a subset of stdc++ I thought I wouldn't need that anyway. Is this expected behavior? Is libgcc_eh.a really needed here or is there a way to avoid it? Or should CMake also add libsupc++? Best Regards, Ådne Hovda -- 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] CMake adds libgcc_eh.a to the linker line on AIX
On 02/07/2014 09:03 AM, Ådne Hovda wrote: I notice that under certain conditions CMake adds libgcc_eh.a to the linker line. CMake has no builtin knowledge of this library so it must be coming the detection of libraries implicitly added by the compiler front-end. Take a look at CMakeFiles/cmake-version/CMake(C|CXX)Compiler.cmake files in the build tree. There should be lines that set variables like CMAKE_C_IMPLICIT_LINK_LIBRARIES. Does libgcc_eh.a appear in any of them? Also look at CMakeFiles/CMakeOutput.log for content following lines like Parsed C implicit link information from above output and Parsed CXX implicit link information from above output That has verbose information about how CMake detects these libraries. This is related to the mixed-language support, usually used for linking C++/Fortran together. When computing a link line CMake looks at all the languages that it knows have been compiled into object files involved in the link. It wants to ensure that the libraries normally added by the compiler for each language will appear. Whatever lang's compiler is used to drive the link has a known set of libraries. All other libraries implicitly used by the other languages will be added to the link line explicitly. -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] CMake adds libgcc_eh.a to the linker line on AIX
On 2/7/2014 3:33 PM, Brad King wrote: like CMAKE_C_IMPLICIT_LINK_LIBRARIES. Does libgcc_eh.a appear in any of them? You are right, it's there. If I run powerpc-ibm-aix5.3.0.0-gcc /opt/cmake/share/cmake-2.8/Modules/CMakeCCompilerABI.c -v I see libgcc_eh.as among collect2's args. For powerpc-ibm-aix5.3.0.0-g++ /opt/cmake/share/cmake-2.8/Modules/CMakeCXXCompilerABI.cpp -v it is indeed not present. Whatever lang's compiler is used to drive the link has a known set of libraries. All other libraries implicitly used by the other languages will be added to the link line explicitly. Turns out gcc would try to link libgcc statically by default, and brought in libgcc_eh.a, but that's not working well when linked with C++ code using exceptions. Had I only read the docs... http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-shared-libgcc-1093 . I'll try to set the -shared-libgcc flag in my toolchain file and hopefully have it work. Thanks! Ådne -- 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 02/07/2014 06:05 AM, Nils Gladitz wrote: CMAKE_LANG_COMPILE_OPTIONS_VISIBILITY is being set up for the Intel compiler in general but the -fvisibility option is not supported on Windows and will result in compiler warnings. I set up the intel-visibility topic which moves the option into the Windows and Darwin specific Platform files. This looks correct to me and is a good bug fix. Please merge to 'next' for testing. BTW, the Darwin-icc.cmake file needs to be refactored into modern Darwin-Intel-lang.cmake modules with a Darwin-Intel.cmake helper. Do you have access to Intel C/C++ on OS X that you could use to try this task? Thanks, -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] Request for review of topic intel-visibility
Nils Gladitz wrote: On 02/07/2014 04:24 PM, Brad King wrote: This looks correct to me and is a good bug fix. Please merge to 'next' for testing. Thanks, will do! Do you have access to Intel C/C++ on OS X that you could use to try this task? I currently only have access to Intel on Windows which is why I thought it safer to put the topic up for review first too. Does intel on windows have separate gcc-like and msvc-like modes? Alex also adjusted the intel handling of -isystem today. Does that work if the direct preprocessor flag -Wp,-isystem, is used, if there's some equivalent with the intel compiler? See e00db59d which uses that for the QCC driver. 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] Request for review of topic intel-visibility
On Friday, February 07, 2014 05:33:47 PM Stephen Kelly wrote: Nils Gladitz wrote: On 02/07/2014 04:24 PM, Brad King wrote: This looks correct to me and is a good bug fix. Please merge to 'next' for testing. Thanks, will do! Do you have access to Intel C/C++ on OS X that you could use to try this task? I currently only have access to Intel on Windows which is why I thought it safer to put the topic up for review first too. Does intel on windows have separate gcc-like and msvc-like modes? Alex also adjusted the intel handling of -isystem today. Does that work if the direct preprocessor flag -Wp,-isystem, is used, if there's some Would there be an advantage compared to using -isystem ? AFAIK -isystem is not supported by icpc under Windows, and from looking at other files in cmake -isystem seems in general not to be supported under OSX. But I have access only to icpc under Linux, so I can't check. Alex -- 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] Adding Release Notes
On 02/04/2014 12:06 PM, Brad King wrote: I'm working on the notes for 3.0.0 by hand I've added release notes for 3.0: Help: Add CMake 3.0 Release Notes http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9860f90 Please proofread and check for your changes. (I'm excluding most minor/internal bug fixes.) Thanks, -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] push of LinkOptionsCommand topic branch
On Feb 7, 2014, at 1:45 AM, Stephen Kelly steve...@gmail.com wrote: You still have extra dashes in the titles in the target property documentation. Fixed. Please also rebase to master. The documentation has been updated to add more relevant links, markup etc. Please follow the same patterns in all the new docs on your branch. Updated Note also that your add_link_options doc copied some content from add_compile_commands without modifying it (re include directories). Fixed Here's some guidance Brad gave me a while ago regarding writing commit messages with an imperative mood: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6904 Thanks, these tips are quite helpful. The new tests look good to me. Please use spaces not tabs in foo.cpp in the add_link_options test. You also add a foo.cpp in the target_link_options test, but it has no content. Is that deliberate, or should it be the same as the other? In theory it doesn’t matter if foo.cpp is empty for the target_link_options test. I went ahead and added some content though to match the add_link_options test, just to be consistent. In the 'cmLocalGenerator: Add AddLinkOptions method for LINK_FLAGS.' commit message, you mention that the differences regarding static and object libraries from the xcode generator are included. You don't say what impact that has on other generators though. Were the other generators buggy by not doing the same thing before? Or was the xcode generator special for needing this? If the xcode generator has a special need, then that snippet should stay in the xcode generator, right? Good questions. The other generators did not specifically (that I noticed) have checks for static/object libraries. It seems to me though that they maybe should have which is why I put the checks in AddLinkOptions. If this decision should be changed though, I have no problem changing it. I’m no expert on the generators. I pushed the other changes back to stage. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
On 01/27/2014 02:01 PM, Brad King wrote: We're past the 2014-01-15 target date for CMake 3.0 on the issue tracker roadmap so it is time to prepare the first release candidate. I will now feature-freeze master in preparation for the release. Well it took a bit more work than I expected to update all the release infrastructure for the new documentation system, etc. Now we're pretty close to ready. 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. The current three-component feature level arose for various historical reasons, but a two-component feature level is more consistent with the names of the components (since patch does not sound like a feature change). Through the 2.8.x release series we've used major.minor.patch[.tweak][-rcn] = Release major.minor.patch.date[-id] = Development As part of the bump to version 3.0 I propose we change to major.minor[.patch][-rcn] = Release major.minor.date[-id] = Development Post-3.0 development versions will be numbered 3.0.CCYYMMDD, e.g. 3.0.20140501 and post-3.0 bug (regression) fix releases will be numbered 3.0.N, e.g. 3.0.1 Future feature releases will then be numbered 3.1, 3.2, ..., 3.9, 3.10, 3.11, ... until an eventual 4.0. This is now possible because the CMAKE_VERSION variable and the if() VERSION_LESS/VERSION_EQUAL/VERSION_GREATER operators have been around for a long time and no one should use floating-point comparison against 3.x versions like they did long ago for 2.x. Comments? -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] Request for review of topic intel-visibility
On 02/07/2014 04:24 PM, Brad King wrote: This looks correct to me and is a good bug fix. Please merge to 'next' for testing. Thanks, will do! Do you have access to Intel C/C++ on OS X that you could use to try this task? I currently only have access to Intel on Windows which is why I thought it safer to put the topic up for review first too. 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] Adding Release Notes
Very nice. On Fri, Feb 7, 2014 at 1:42 PM, Brad King brad.k...@kitware.com wrote: On 02/04/2014 12:06 PM, Brad King wrote: I'm working on the notes for 3.0.0 by hand I've added release notes for 3.0: Help: Add CMake 3.0 Release Notes http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9860f90 Please proofread and check for your changes. (I'm excluding most minor/internal bug fixes.) Thanks, -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 -- +1 919 869 8849 -- 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
On 2014-02-07 13:57, 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. I guess this will mean that minor release are much more frequent than historically? (About as frequent as patch release in the 2.x series, I guess?) Future feature releases will then be numbered 3.1, 3.2, ..., 3.9, 3.10, 3.11, ... Out of curiosity, does this mean that 3.x will drop the convention of odd-numbered minor versions being developmental? (Actually, I can't recall ever actually seeing an odd-numbered minor version...) -- Matthew -- 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
On Fri, Feb 07, 2014 at 13:57:28 -0500, Brad King wrote: Comments? So…what the Linux kernel did? :) I like it. --Ben -- 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] add_custom_command differences in tests
On Feb 7, 2014, at 10:14 AM, Steve Wilson ste...@wolfram.com wrote: On Feb 6, 2014, at 10:12 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Thu, Feb 06, 2014 at 17:30:11 -0700, Steve Wilson wrote: I have my topic branch with the add_custom_command changes to include the CONFIG keyword working.The CMake binary produced from the build will correctly generated build systems that have custom commands with the CONFIG keyword. I’m having trouble writing tests for the changes though. When I run add_custom_command with the CONFIG keyword in the test suite the CONFIG keyword does not work. I need a little guidance with the test suite. I’m not super familiar with CTest so I’m not sure where to look next to find the problem. So my question: Why would add_custom_command behave differently in the tests than in regular build system generation? I have been able to determine that the code isn’t working because it seems that when running from ctest, cmake seems to be running in a configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are not set regardless of the -C option passed to ctest.I would have thought that the build configuration of the test would match the configuration set with ‘ctest -C .' signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
On 02/07/2014 02:34 PM, Matthew Woehlke wrote: I guess this will mean that minor release are much more frequent than historically? (About as frequent as patch release in the 2.x series, I guess?) Yes. Future feature releases will then be numbered 3.1, 3.2, ..., 3.9, 3.10, 3.11, ... Out of curiosity, does this mean that 3.x will drop the convention of odd-numbered minor versions being developmental? (Actually, I can't recall ever actually seeing an odd-numbered minor version...) The odd/even convention was dropped back when we converted to a Git branchy workflow by commit v2.8.2~105^2~4 (New version scheme to support branchy workflow, 2010-04-23): http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5bfffd6f It's just that 2.8 essentially became the major version so 2.8.x have been the minor releases, including odd 'x' values. -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] add_custom_command differences in tests
Agreed. Is there an issue in the tracker to document that problem ? On Fri, Feb 7, 2014 at 3:05 PM, Steve Wilson ste...@wolfram.com wrote: On Feb 7, 2014, at 10:14 AM, Steve Wilson ste...@wolfram.com wrote: On Feb 6, 2014, at 10:12 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Thu, Feb 06, 2014 at 17:30:11 -0700, Steve Wilson wrote: I have my topic branch with the add_custom_command changes to include the CONFIG keyword working.The CMake binary produced from the build will correctly generated build systems that have custom commands with the CONFIG keyword. I'm having trouble writing tests for the changes though. When I run add_custom_command with the CONFIG keyword in the test suite the CONFIG keyword does not work. I need a little guidance with the test suite. I'm not super familiar with CTest so I'm not sure where to look next to find the problem. So my question: Why would add_custom_command behave differently in the tests than in regular build system generation? I have been able to determine that the code isn't working because it seems that when running from ctest, cmake seems to be running in a configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are not set regardless of the -C option passed to ctest.I would have thought that the build configuration of the test would match the configuration set with 'ctest -C .' -- 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 -- +1 919 869 8849 -- 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] add_custom_command differences in tests
On 02/07/2014 04:46 PM, Jean-Christophe Fillion-Robin wrote:
I have been able to determine that the code isn’t working because it
seems that when running from ctest, cmake seems to be running in a
configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are
not set regardless of the -C option passed to ctest.I would have thought
that the
build configuration of the test would match the configuration set with
‘ctest -C .'
Agreed. Is there an issue in the tracker to document that problem ?
No, because it is not a bug, at least in so far as it is not intended
to work. Also it only influences CMake's own testing and not other
projects so it is not public-facing behavior.
A few calls in Tests/CMakeLists.txt add
-DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
to force building with the tested configuration but most tests do not
need this. Most tests work in any configuration and do not depend on
being built as the same configuration that the running CMake was.
Steve W, can you post your tests as a patch or point us to a repo
where they are published so we can see how you're trying to test the
new CONFIG option?
Thanks,
-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] add_custom_command differences in tests
On Feb 7, 2014, at 3:01 PM, Brad King brad.k...@kitware.com wrote:
On 02/07/2014 04:46 PM, Jean-Christophe Fillion-Robin wrote:
I have been able to determine that the code isn’t working because it
seems that when running from ctest, cmake seems to be running in a
configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are
not set regardless of the -C option passed to ctest.I would have
thought that the
build configuration of the test would match the configuration set with
‘ctest -C .'
Agreed. Is there an issue in the tracker to document that problem ?
No, because it is not a bug, at least in so far as it is not intended
to work. Also it only influences CMake's own testing and not other
projects so it is not public-facing behavior.
A few calls in Tests/CMakeLists.txt add
-DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
I have tried adding that to my test call (—build-options) but it doesn’t seem
to make any difference.
to force building with the tested configuration but most tests do not
need this. Most tests work in any configuration and do not depend on
being built as the same configuration that the running CMake was.
This particular feature I am testing tests add_custom_command in different
configurations, so configurations do matter in this scenario.
Steve W, can you post your tests as a patch or point us to a repo
where they are published so we can see how you're trying to test the
new CONFIG option?
I pushed the add-custom-command-config-tmp branch to stage. This branch does
not represent the final topic branch I intend to submit. It is only my local
working branch. It contains a sample test in Tests/CustomCommand/ConfigTest.
I will remove it as soon as you have seen what you need.
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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 0014742]: The target property SUFFIX and/or BUNDLE_EXTENSION doesn't rename the extension of an framework
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14742
==
Reported By:Roman80
Assigned To:
==
Project:CMake
Issue ID: 14742
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-02-07 17:20 EST
Last Modified: 2014-02-07 17:20 EST
==
Summary:The target property SUFFIX and/or BUNDLE_EXTENSION
doesn't rename the extension of an framework
Description:
The target property SUFFIX and/or BUNDLE_EXTENSION doesn't rename the extension
of a framework.
For e.g. an Adobe InDesign plugin is a framework but with the extension
.InDesignPlugin
Maybe this could also be for other tools/programs too.
Steps to Reproduce:
Use the following commands to create a framework
project(MyPlugin)
add_library(${PROJECT_NAME} SHARED ${HEADERS} ${SOURCES})
set_target_properties(${PROJECT_NAME} PROPERTIES
FRAMEWORK TRUE
SUFFIX .InDesignPlugin)
Expected result: MyPlugin.InDesignPlugin
--
set_target_properties(${PROJECT_NAME} PROPERTIES
FRAMEWORK TRUE
BUNDLE_EXTENSION .InDesignPlugin)
Expected result: MyPlugin.InDesignPlugin
==
Issue History
Date ModifiedUsername FieldChange
==
2014-02-07 17:20 Roman80New Issue
==
--
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 0014743]: Target property RESOURCE does not recognize directories
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14743 == Reported By:Roman80 Assigned To: == Project:CMake Issue ID: 14743 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-07 17:22 EST Last Modified: 2014-02-07 17:22 EST == Summary:Target property RESOURCE does not recognize directories Description: The target property RESOURCE does not copy directories into the frameworks Resources directory == Issue History Date ModifiedUsername FieldChange == 2014-02-07 17:22 Roman80New Issue == -- 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] Using a toplevel CMakeList.txt to build all sub projects at once.
On 2014-02-06 01:14, PCMan wrote: We're migrating from gtk+ to Qt and autotools to CMake and encountered some issues. There are many small modules or components in our project. Each of them has their own CMakeLists.txt and can be built separately. However, it's hard to build so many projects manually. So we'd like to create a toplevel CMakeLists.txt to build them all at once. However, the small projects depend on each other. For example, our project layout look like this: libqtxdg - a base lib required by others liblxqt - a library depends on libqtxdg lxqt-config - a tool depends on liblxqt and libqtxdg. To build lxqt-config, liblxqt and libqtxdg need to be installed first. So simply adding them using add_subdirectoyy() won't work. This sounds like a classic superbuild problem. As an alternative, you could make sure that all of your sub-projects build CMake package configuration files with modern exported targets¹, and then conditionally do a find_package for your dependencies if not being built from the root build. Then each sub-project uses its dependencies by target name, which in theory should make transparent whether they're being built all from the same root build or independently. (And you won't need to install each sub-project before building the next.) (¹ Even if you don't go with this overall solution, using exported/imported targets is good practice that I would strongly encourage you to pursue anyway, if you aren't already doing that.) Even worse, two of our components are still automake-based. The cmake ExternalProject_Add() command did not solve the problem that some of them needs to be installed first before others can be compiled. For this you will need to use a superbuild, i.e. your dependee projects must also be built via ExternalProject_Add(). If the dependency projects aren't huge, it might be better to just port them to CMake. -- Matthew -- 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-7508-g2f58f2b
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 2f58f2bfd862f464029a38b8c2b74ce5a8722c8a (commit) via f02b5fb5a0720f52ddd3cb32a1d704c76c8d3b5b (commit) via 53cffda228e50948e52ae3b5bc46d4fa3f59a0ba (commit) from 1ba947ef5870526ad00a76928306e0106989c631 (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=2f58f2bfd862f464029a38b8c2b74ce5a8722c8a commit 2f58f2bfd862f464029a38b8c2b74ce5a8722c8a Merge: 1ba947e f02b5fb Author: Stephen Kelly steve...@gmail.com AuthorDate: Fri Feb 7 08:26:16 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Feb 7 08:26:16 2014 -0500 Merge topic 'doc-polcy-CMP0024-typo' into next f02b5fb5 Help: Fix typo. 53cffda2 CMake Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f02b5fb5a0720f52ddd3cb32a1d704c76c8d3b5b commit f02b5fb5a0720f52ddd3cb32a1d704c76c8d3b5b Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Feb 6 11:54:34 2014 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Fri Feb 7 14:25:19 2014 +0100 Help: Fix typo. 'to not to' - 'not to' diff --git a/Help/policy/CMP0024.rst b/Help/policy/CMP0024.rst index abfcc75..42b7b9f 100644 --- a/Help/policy/CMP0024.rst +++ b/Help/policy/CMP0024.rst @@ -14,7 +14,7 @@ targets instead in cases where the goal is to refer to targets by another name. The OLD behavior for this policy is to allow including the result of -an export() command. The NEW behavior for this policy is to not to +an export() command. The NEW behavior for this policy is not to allow including the result of an export() command. This policy was introduced in CMake version 3.0.0. CMake version --- Summary of changes: Help/policy/CMP0024.rst |2 +- Source/CMakeVersion.cmake |2 +- 2 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.12.2-7511-g02cc73a
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 02cc73a83cf97bfc8068eba063b16f3dc5f6872e (commit)
via 74c3875b3357a428c5a94c250b8008a3135a444b (commit)
via cafc60efcdb75ed1900f02a2970435c322844e4e (commit)
from 2f58f2bfd862f464029a38b8c2b74ce5a8722c8a (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=02cc73a83cf97bfc8068eba063b16f3dc5f6872e
commit 02cc73a83cf97bfc8068eba063b16f3dc5f6872e
Merge: 2f58f2b 74c3875
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 7 09:46:42 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 7 09:46:42 2014 -0500
Merge topic 'gcc-ipo' into next
74c3875b IPO: output IPO specific variables to determine if IPO is in use
cafc60ef IPO: involve gcc-ar and gcc-ranlib in LTO test as well
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74c3875b3357a428c5a94c250b8008a3135a444b
commit 74c3875b3357a428c5a94c250b8008a3135a444b
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 7 15:43:45 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Fri Feb 7 15:43:45 2014 +0100
IPO: output IPO specific variables to determine if IPO is in use
diff --git a/Tests/IPO/CMakeLists.txt b/Tests/IPO/CMakeLists.txt
index 6dabf86..b45ec89 100644
--- a/Tests/IPO/CMakeLists.txt
+++ b/Tests/IPO/CMakeLists.txt
@@ -1,5 +1,13 @@
cmake_minimum_required (VERSION 2.8)
-project(IPO NONE)
+project(IPO C)
+
+message( IPO specific variables ==)
+get_cmake_property(variables VARIABLES)
+foreach(variable ${variables})
+ if(${variable}xxx MATCHES _IPOxxx)
+message(${variable}: [${${variable}}])
+ endif()
+endforeach()
set_property(DIRECTORY PROPERTY INTERPROCEDURAL_OPTIMIZATION 1)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cafc60efcdb75ed1900f02a2970435c322844e4e
commit cafc60efcdb75ed1900f02a2970435c322844e4e
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 7 15:43:05 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Fri Feb 7 15:43:05 2014 +0100
IPO: involve gcc-ar and gcc-ranlib in LTO test as well
diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
index c135ec3..e40fa9f 100644
--- a/Modules/Compiler/GNU.cmake
+++ b/Modules/Compiler/GNU.cmake
@@ -83,16 +83,40 @@ macro(__compiler_gnu lang)
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 int main() {}
-COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -xc -
- -o ${CMAKE_PLATFORM_INFO_DIR}/lto-test-${lang}
+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
)
- set(__lto_found FALSE)
+ 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()
---
Summary of changes:
Modules/Compiler/GNU.cmake | 32
Tests/IPO/CMakeLists.txt | 10 +-
2 files changed, 37 insertions(+), 5 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.12.2-7514-g1ef4916
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 1ef49162117af4f0e40c0445994ae1c72b75daa7 (commit)
via 6d85a6a64c6919c07d983b584bb74f6a29cddac5 (commit)
via 770245e9287de01c990605b54d28302c9cac3340 (commit)
from 02cc73a83cf97bfc8068eba063b16f3dc5f6872e (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=1ef49162117af4f0e40c0445994ae1c72b75daa7
commit 1ef49162117af4f0e40c0445994ae1c72b75daa7
Merge: 02cc73a 6d85a6a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Feb 7 09:50:05 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 7 09:50:05 2014 -0500
Merge topic 'interface-library-signatures' into next
6d85a6a6 add_library: Issue better diagnostic for INTERFACE GLOBAL
signature.
770245e9 add_library: Test invalid GLOBAL INTERFACE signature.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d85a6a64c6919c07d983b584bb74f6a29cddac5
commit 6d85a6a64c6919c07d983b584bb74f6a29cddac5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Feb 7 15:31:57 2014 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Feb 7 15:49:15 2014 +0100
add_library: Issue better diagnostic for INTERFACE GLOBAL signature.
diff --git a/Source/cmAddLibraryCommand.cxx b/Source/cmAddLibraryCommand.cxx
index a29f784..009b1ca 100644
--- a/Source/cmAddLibraryCommand.cxx
+++ b/Source/cmAddLibraryCommand.cxx
@@ -173,6 +173,13 @@ bool cmAddLibraryCommand
++s;
importGlobal = true;
}
+else if(type == cmTarget::INTERFACE_LIBRARY *s == GLOBAL)
+ {
+ cmOStringStream e;
+ e GLOBAL option may only be used with IMPORTED libraries.;
+ this-SetError(e.str().c_str());
+ return false;
+ }
else
{
break;
diff --git a/Tests/RunCMake/interface_library/invalid_signature-stderr.txt
b/Tests/RunCMake/interface_library/invalid_signature-stderr.txt
index 701586a..6374b33 100644
--- a/Tests/RunCMake/interface_library/invalid_signature-stderr.txt
+++ b/Tests/RunCMake/interface_library/invalid_signature-stderr.txt
@@ -84,6 +84,6 @@ Call Stack \(most recent call first\):
CMakeLists.txt:3 \(include\)
+
CMake Error at invalid_signature.cmake:20 \(add_library\):
- add_library INTERFACE library requires no source arguments.
+ add_library GLOBAL option may only be used with IMPORTED libraries.
Call Stack \(most recent call first\):
CMakeLists.txt:3 \(include\)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=770245e9287de01c990605b54d28302c9cac3340
commit 770245e9287de01c990605b54d28302c9cac3340
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Feb 7 15:38:49 2014 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Feb 7 15:49:15 2014 +0100
add_library: Test invalid GLOBAL INTERFACE signature.
This has to be tested separately from the invalid_signature test because
target sources are evaluate at a later time, and earlier errors in the
invalid_signature test cause early exit.
diff --git a/Tests/RunCMake/interface_library/RunCMakeTest.cmake
b/Tests/RunCMake/interface_library/RunCMakeTest.cmake
index 9ca9a77..3c457c5 100644
--- a/Tests/RunCMake/interface_library/RunCMakeTest.cmake
+++ b/Tests/RunCMake/interface_library/RunCMakeTest.cmake
@@ -5,5 +5,6 @@ run_cmake(target_commands)
run_cmake(no_shared_libs)
run_cmake(whitelist)
run_cmake(invalid_signature)
+run_cmake(global-interface)
run_cmake(genex_link)
run_cmake(add_dependencies)
diff --git a/Tests/RunCMake/interface_library/global-interface-result.txt
b/Tests/RunCMake/interface_library/global-interface-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/interface_library/global-interface-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/interface_library/global-interface-stderr.txt
b/Tests/RunCMake/interface_library/global-interface-stderr.txt
new file mode 100644
index 000..24edd0f
--- /dev/null
+++ b/Tests/RunCMake/interface_library/global-interface-stderr.txt
@@ -0,0 +1,9 @@
+CMake Error at global-interface.cmake:2 \(add_library\):
+ Cannot find source file:
+
+GLOBAL
+
+ Tried extensions \.c \.C \.c\+\+ \.cc \.cpp \.cxx \.m \.M \.mm \.h \.hh
\.h\+\+ \.hm \.hpp
+ \.hxx \.in \.txx
+Call Stack \(most recent call first\):
+ CMakeLists.txt:3 \(include\)
diff --git a/Tests/RunCMake/interface_library/global-interface.cmake
b/Tests/RunCMake/interface_library/global-interface.cmake
new file mode 100644
index 000..d2bfc64
--- /dev/null
+++ b/Tests/RunCMake/interface_library/global-interface.cmake
@@ -0,0 +1,2 @@
+
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7516-g9401f64
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 9401f64c3fa06d3c0eab7dee61ef989c441c6a33 (commit)
via b7f58511cf050b8976445694446c695c9d230b8b (commit)
from 1ef49162117af4f0e40c0445994ae1c72b75daa7 (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=9401f64c3fa06d3c0eab7dee61ef989c441c6a33
commit 9401f64c3fa06d3c0eab7dee61ef989c441c6a33
Merge: 1ef4916 b7f5851
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 7 10:51:31 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 7 10:51:31 2014 -0500
Merge topic 'intel-visibility' into next
b7f58511 Visibility: the Intel compiler does not support -fvisibility on
windows
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b7f58511cf050b8976445694446c695c9d230b8b
commit b7f58511cf050b8976445694446c695c9d230b8b
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 7 11:50:08 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Fri Feb 7 11:50:08 2014 +0100
Visibility: the Intel compiler does not support -fvisibility on windows
diff --git a/Modules/Compiler/Intel-C.cmake b/Modules/Compiler/Intel-C.cmake
index 7d98f03..1d651e3 100644
--- a/Modules/Compiler/Intel-C.cmake
+++ b/Modules/Compiler/Intel-C.cmake
@@ -8,9 +8,5 @@ set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT -O2 -g -DNDEBUG)
set(CMAKE_DEPFILE_FLAGS_C -MMD -MT OBJECT -MF DEPFILE)
-if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.0)
- set(CMAKE_C_COMPILE_OPTIONS_VISIBILITY -fvisibility=)
-endif()
-
set(CMAKE_C_CREATE_PREPROCESSED_SOURCE CMAKE_C_COMPILER DEFINES FLAGS
-E SOURCE PREPROCESSED_SOURCE)
set(CMAKE_C_CREATE_ASSEMBLY_SOURCE CMAKE_C_COMPILER DEFINES FLAGS -S
SOURCE -o ASSEMBLY_SOURCE)
diff --git a/Modules/Compiler/Intel-CXX.cmake b/Modules/Compiler/Intel-CXX.cmake
index 36a838d..020e862 100644
--- a/Modules/Compiler/Intel-CXX.cmake
+++ b/Modules/Compiler/Intel-CXX.cmake
@@ -8,9 +8,5 @@ set(CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT -O2 -g -DNDEBUG)
set(CMAKE_DEPFILE_FLAGS_CXX -MMD -MT OBJECT -MF DEPFILE)
-if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 12.0)
- set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY -fvisibility=)
-endif()
-
set(CMAKE_CXX_CREATE_PREPROCESSED_SOURCE CMAKE_CXX_COMPILER DEFINES
FLAGS -E SOURCE PREPROCESSED_SOURCE)
set(CMAKE_CXX_CREATE_ASSEMBLY_SOURCE CMAKE_CXX_COMPILER DEFINES FLAGS
-S SOURCE -o ASSEMBLY_SOURCE)
diff --git a/Modules/Platform/Darwin-icc.cmake
b/Modules/Platform/Darwin-icc.cmake
index 0fab9a1..c7e31c0 100644
--- a/Modules/Platform/Darwin-icc.cmake
+++ b/Modules/Platform/Darwin-icc.cmake
@@ -75,6 +75,12 @@ if(XCODE)
set(CMAKE_INCLUDE_SYSTEM_FLAG_CXX)
endif()
+if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 12.0)
+ set(CMAKE_C_COMPILE_OPTIONS_VISIBILITY -fvisibility=)
+ set(CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY -fvisibility=)
+endif()
+
+
set(CMAKE_MacOSX_Content_COMPILE_OBJECT \${CMAKE_COMMAND}\ -E
copy_if_different SOURCE OBJECT)
set(CMAKE_C_CREATE_SHARED_LIBRARY
diff --git a/Modules/Platform/Linux-Intel.cmake
b/Modules/Platform/Linux-Intel.cmake
index 2394f10..20fddb4 100644
--- a/Modules/Platform/Linux-Intel.cmake
+++ b/Modules/Platform/Linux-Intel.cmake
@@ -47,4 +47,8 @@ macro(__linux_compiler_intel lang)
${XIAR} cr TARGET LINK_FLAGS OBJECTS
${XIAR} -s TARGET )
endif()
+
+ if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 12.0)
+set(CMAKE_${lang}_COMPILE_OPTIONS_VISIBILITY -fvisibility=)
+ endif()
endmacro()
---
Summary of changes:
Modules/Compiler/Intel-C.cmake |4
Modules/Compiler/Intel-CXX.cmake |4
Modules/Platform/Darwin-icc.cmake |6 ++
Modules/Platform/Linux-Intel.cmake |4
4 files changed, 10 insertions(+), 8 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.12.2-7524-g3283439
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 3283439d6da10b1e37df7ab41cf2314df02d7ee9 (commit) via afebd7406430229bc8af4b9bfd24a25e3e16525d (commit) from ba21cd5e0049353dc945fa66d3b56cf6104f5633 (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=3283439d6da10b1e37df7ab41cf2314df02d7ee9 commit 3283439d6da10b1e37df7ab41cf2314df02d7ee9 Merge: ba21cd5 afebd74 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Feb 7 17:03:19 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Feb 7 17:03:19 2014 -0500 Merge topic 'release-notes-3.0' into next afebd740 Help: Update 3.0 release notes for export() enhancement http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afebd7406430229bc8af4b9bfd24a25e3e16525d commit afebd7406430229bc8af4b9bfd24a25e3e16525d Author: Brad King brad.k...@kitware.com AuthorDate: Fri Feb 7 17:03:13 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Feb 7 17:03:13 2014 -0500 Help: Update 3.0 release notes for export() enhancement The command now supports multiple export sets. diff --git a/Help/release/3.0.rst b/Help/release/3.0.rst index 4c0f3a5..89801f9 100644 --- a/Help/release/3.0.rst +++ b/Help/release/3.0.rst @@ -98,6 +98,14 @@ Commands makes it easy to export from the build tree the same targets that are exported from the install tree. +* The :command:`export` command learned to work with multiple dependent + export sets, thus allowing multiple packages to be built and exported + from a single tree. The feature requires CMake to wait until the + generation step to write the output file. This means one should not + :command:`include` the generated targets file later during project + configuration because it will not be available. + Use :ref:`Alias Targets` instead. See policy :policy:`CMP0024`. + * The :command:`project` command learned to set some version variables to values specified by the new ``VERSION`` option or to empty strings. See policy :policy:`CMP0048`. @@ -355,12 +363,6 @@ Other Changes is now ``QCC``. It must be distinct from ``GNU`` because the command-line options differ. See policy :policy:`CMP0047`. -* The :command:`export` command was changed to wait until the - generation step to write the output file. This means one should not - :command:`include` the generated targets file later during project - configuration. Use :ref:`Alias Targets` instead. - See policy :policy:`CMP0024`. - * On 64-bit OS X the :variable:`CMAKE_HOST_SYSTEM_PROCESSOR` value is now correctly detected as ``x86_64`` instead of ``i386``. --- Summary of changes: Help/release/3.0.rst | 14 -- 1 file changed, 8 insertions(+), 6 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.12.2-1373-gd582809
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 d58280949745660508aa203335dca9b1368817fe (commit) from 53cffda228e50948e52ae3b5bc46d4fa3f59a0ba (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=d58280949745660508aa203335dca9b1368817fe commit d58280949745660508aa203335dca9b1368817fe Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat Feb 8 00:01:06 2014 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat Feb 8 00:01:06 2014 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7945bb5..6e8329a 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 20140207) +set(CMake_VERSION_TWEAK 20140208) #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
