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
