Re: [cmake-developers] Testing Config generator expression
Brad King wrote: On 11/01/2012 11:45 AM, Stephen Kelly wrote: Ok, I've added a test for that, but as that test uses CMAKE_COMMAND too, with makefile generators, the result will be each time. Okay, now I see what you meant before. Sorry. I think just this will be sufficient (untested): I wasn't able to make that work. Also any solution based on using script mode didn't work because I can't use add_custom_command there. I've added a solution based on creating top-level tests. Please let me know if I should merge that to next. 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] [CMake 0013643]: GenerateExportHeader should work for module libraries too
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13643
==
Reported By:Gregoire
Assigned To:
==
Project:CMake
Issue ID: 13643
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-02 06:13 EDT
Last Modified: 2012-11-02 06:13 EDT
==
Summary:GenerateExportHeader should work for module
libraries too
Description:
I am doing my tests with visual 2008 and mingw.
As far as I understand a module is like a shared library that cannot
be linked. Instead it is dynamically loaded and then we find and use
symbols in it. It is like doing the linker's job manually at runtime.
If nothing is exported from my module then I do cannot find any
symbol in it. Or at least I do not know how to do so.
I modified the GenerateExportHeader module to be able to export
symbols from my MODULE:
# if(${type} STREQUAL MODULE)
# message(WARNING This macro should not be used with libraries of
# type MODULE) return()
# endif()
if(NOT ${type} STREQUAL STATIC_LIBRARY AND NOT ${type} STREQUAL
SHARED_LIBRARY AND NOT ${type} STREQUAL MODULE_LIBRARY)
message(WARNING This macro can only be used with libraries)
return()
endif()
Steps to Reproduce:
Build a module with visual without exported symbols.
Use depends.exe (from http://www.dependencywalker.com/) to open the generated
dll.
It will not find any symbols which means that your application won't be able to
find it either, the module is useless.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-02 06:13 Gregoire New 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-developers] Testing Config generator expression
On 11/02/2012 05:26 AM, Stephen Kelly wrote:
Brad King wrote:
I think just this will be sufficient (untested):
I wasn't able to make that work. Also any solution based on using script
mode didn't work because I can't use add_custom_command there.
It isn't script mode. The patch below works for me.
-Brad
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 077bbc4..c937906 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -556,6 +556,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
--build-generator ${CMAKE_TEST_GENERATOR}
--build-project GeneratorExpression
--build-makeprogram ${CMAKE_TEST_MAKEPROGRAM}
+--build-options -DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
)
list(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/GeneratorExpression)
diff --git a/Tests/GeneratorExpression/CMakeLists.txt
b/Tests/GeneratorExpression/CMakeLists.txt
index 581d483..3a92d81 100644
--- a/Tests/GeneratorExpression/CMakeLists.txt
+++ b/Tests/GeneratorExpression/CMakeLists.txt
@@ -19,6 +19,10 @@ add_custom_target(check ALL
-Dtest_and_0_invalidcontent=$AND:0,invalidcontent
-Dtest_config_0=$CONFIG:$CONFIGURATIONx
-Dtest_config_1=$CONFIG:$CONFIGURATION
+-Dtest_config_debug=$CONFIG:Debug$CONFIG:DEBUG$CONFIG:DeBuG
+-Dtest_config_release=$CONFIG:Release$CONFIG:RELEASE$CONFIG:ReLeAsE
+
-Dtest_config_relwithdebinfo=$CONFIG:RelWithDebInfo$CONFIG:RELWITHDEBINFO$CONFIG:relwithdebinfo
+
-Dtest_config_minsizerel=$CONFIG:MinSizeRel$CONFIG:MINSIZEREL$CONFIG:minsizerel
-Dtest_not_0=$NOT:0
-Dtest_not_1=$NOT:1
-Dtest_or_0=$OR:0
diff --git a/Tests/GeneratorExpression/check.cmake
b/Tests/GeneratorExpression/check.cmake
index 88a60ce..af436de 100644
--- a/Tests/GeneratorExpression/check.cmake
+++ b/Tests/GeneratorExpression/check.cmake
@@ -18,6 +18,11 @@ check(test_and_1_1 1)
check(test_and_0_invalidcontent 0)
check(test_config_0 0)
check(test_config_1 1)
+foreach(c debug release relwithdebinfo minsizerel)
+ if(NOT ${test_config_${c}} MATCHES ^(0+|1+)$)
+message(SEND_ERROR test_config_${c} is \${test_config_${c}}\, not all 0
or all 1)
+ endif()
+endforeach()
check(test_not_0 1)
check(test_not_1 0)
check(test_or_0 0)
--
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] patch for cmake that adds a new timestamp command
Thanks! Let me know if there is anything else I can do. Nils On 10/31/2012 09:52 PM, David Cole wrote: Has anybody tried this anywhere else? I'm going to merge it to 'next' tomorrow, so that it will get tested on the dashboards after that. Just curious if there are any other known problems with it that I should squash in before doing that... Thanks, David On Tue, Oct 16, 2012 at 1:57 PM, David Cole david.c...@kitware.com mailto:david.c...@kitware.com wrote: I have amended the commit and pushed this branch to the stage. If anybody else would like to try it out they can grab the add-timestamp-subcommands branch from the CMake stage repo. I did not merge it to 'next' yet, but I will do that when we're ready to get it tested on the dashboards. Thanks for your work on this Nils. David On Tue, Oct 16, 2012 at 11:48 AM, Nils Gladitz glad...@sci-vis.de mailto:glad...@sci-vis.de wrote: Ah that might explain it ... I may have been using nmake on Windows and ninja on linux. Thanks! Nils On 10/16/2012 05:27 PM, David Cole wrote: On Tue, Oct 16, 2012 at 10:12 AM, Nils Gladitz glad...@sci-vis.de mailto:glad...@sci-vis.de wrote: I certainly wouldn't mind though I'm not sure what that means. Do the changes in next still potentially make it into 2.8.10? Going into 'next' is how stuff gets tested on the dashboards, and then later Brad and I merge things to 'master' when they're ready. After something is merged to 'master' it will be in the CMake release that follows that. Brad mentioned this would be on the TODO list for after 2.8.10. We can put it in 'next' to vet it and correct any dashboard issues that show up (errors/warnings on other platforms, other platform test failures) at any time. But it will probably not go into 'master' until after 2.8.10. We don't typically add significant features or take risky changes after we start doing release candidates. I've tried to run all tests successfully before submitting but I can't tell if any of those were called BootstrapTest. Is there anything special required to run it? The BootstrapTest test only runs on Unix Makefiles based builds, so if you're using a different generator, it does not get added as a test. Nils On 10/16/2012 02:49 PM, David Cole wrote: I had to do this to get the bootstrap version of CMake to work (and the BootstrapTest to pass): $ git diff diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index 9d46355..8bf6c40 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt @@ -264,8 +264,6 @@ set(SRCS cmTarget.cxx cmTarget.h cmTargetExport.h - cmTimestamp.h - cmTimestamp.cxx cmTest.cxx cmTest.h cmTestGenerator.cxx diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx index 9097a74..e3a2ad4 100644 --- a/Source/cmBootstrapCommands.cxx +++ b/Source/cmBootstrapCommands.cxx @@ -89,6 +89,7 @@ #include cmStringCommand.cxx #include cmSubdirCommand.cxx #include cmTargetLinkLibrariesCommand.cxx +#include cmTimestamp.cxx #include cmTryCompileCommand.cxx #include cmTryRunCommand.cxx #include cmUnsetCommand.cxx After amending this, I'll push to next later today unless somebody objects to this?? Thanks, David On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz glad...@sci-vis.de mailto:glad...@sci-vis.de wrote: I've updated the patch (attached) to return empty string on failure. I also tried to use the time definitions from global namespace rather than std::. Nils On 10/05/2012 09:17 PM, Brad King wrote: On 10/05/2012 02:53 PM, Nils Gladitz wrote: My initial thought was that NOTFOUND would be a good idea since it evaluates to false and the get_*_property commands also seem to use it. I wrote the more general get_property command to replace those and the newer command uses empty string rather than NOTFOUND. It is more useful when computing pieces of a string to put together, perhaps when appending to a property value. Looking at the documentation for if() again only -NOTFOUND as a suffix should evaluate to false though (I assume the documentation is incomplete here?). Yes, thanks for pointing it out. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f63304d9 On second though relying on timestamps to evaluate to false on failure is probably a bad idea
Re: [cmake-developers] patch for cmake that adds a new timestamp command
You're welcome. I decided to wait till the dashboard cleans up again before merging this topic, but it should be in the next few days. On Fri, Nov 2, 2012 at 10:19 AM, Nils Gladitz glad...@sci-vis.de wrote: Thanks! Let me know if there is anything else I can do. Nils On 10/31/2012 09:52 PM, David Cole wrote: Has anybody tried this anywhere else? I'm going to merge it to 'next' tomorrow, so that it will get tested on the dashboards after that. Just curious if there are any other known problems with it that I should squash in before doing that... Thanks, David On Tue, Oct 16, 2012 at 1:57 PM, David Cole david.c...@kitware.com wrote: I have amended the commit and pushed this branch to the stage. If anybody else would like to try it out they can grab the add-timestamp-subcommands branch from the CMake stage repo. I did not merge it to 'next' yet, but I will do that when we're ready to get it tested on the dashboards. Thanks for your work on this Nils. David On Tue, Oct 16, 2012 at 11:48 AM, Nils Gladitz glad...@sci-vis.de wrote: Ah that might explain it ... I may have been using nmake on Windows and ninja on linux. Thanks! Nils On 10/16/2012 05:27 PM, David Cole wrote: On Tue, Oct 16, 2012 at 10:12 AM, Nils Gladitz glad...@sci-vis.de wrote: I certainly wouldn't mind though I'm not sure what that means. Do the changes in next still potentially make it into 2.8.10? Going into 'next' is how stuff gets tested on the dashboards, and then later Brad and I merge things to 'master' when they're ready. After something is merged to 'master' it will be in the CMake release that follows that. Brad mentioned this would be on the TODO list for after 2.8.10. We can put it in 'next' to vet it and correct any dashboard issues that show up (errors/warnings on other platforms, other platform test failures) at any time. But it will probably not go into 'master' until after 2.8.10. We don't typically add significant features or take risky changes after we start doing release candidates. I've tried to run all tests successfully before submitting but I can't tell if any of those were called BootstrapTest. Is there anything special required to run it? The BootstrapTest test only runs on Unix Makefiles based builds, so if you're using a different generator, it does not get added as a test. Nils On 10/16/2012 02:49 PM, David Cole wrote: I had to do this to get the bootstrap version of CMake to work (and the BootstrapTest to pass): $ git diff diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index 9d46355..8bf6c40 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt @@ -264,8 +264,6 @@ set(SRCS cmTarget.cxx cmTarget.h cmTargetExport.h - cmTimestamp.h - cmTimestamp.cxx cmTest.cxx cmTest.h cmTestGenerator.cxx diff --git a/Source/cmBootstrapCommands.cxx b/Source/cmBootstrapCommands.cxx index 9097a74..e3a2ad4 100644 --- a/Source/cmBootstrapCommands.cxx +++ b/Source/cmBootstrapCommands.cxx @@ -89,6 +89,7 @@ #include cmStringCommand.cxx #include cmSubdirCommand.cxx #include cmTargetLinkLibrariesCommand.cxx +#include cmTimestamp.cxx #include cmTryCompileCommand.cxx #include cmTryRunCommand.cxx #include cmUnsetCommand.cxx After amending this, I'll push to next later today unless somebody objects to this?? Thanks, David On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz glad...@sci-vis.de wrote: I've updated the patch (attached) to return empty string on failure. I also tried to use the time definitions from global namespace rather than std::. Nils On 10/05/2012 09:17 PM, Brad King wrote: On 10/05/2012 02:53 PM, Nils Gladitz wrote: My initial thought was that NOTFOUND would be a good idea since it evaluates to false and the get_*_property commands also seem to use it. I wrote the more general get_property command to replace those and the newer command uses empty string rather than NOTFOUND. It is more useful when computing pieces of a string to put together, perhaps when appending to a property value. Looking at the documentation for if() again only -NOTFOUND as a suffix should evaluate to false though (I assume the documentation is incomplete here?). Yes, thanks for pointing it out. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f63304d9 On second though relying on timestamps to evaluate to false on failure is probably a bad idea since I could have a format string of e.g. %w (day of the week) which might produce a valid timestamp 0 which would also evaluate to false. Yes, so a comparison against would be more reliable. Thanks, -Brad -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung
[cmake-developers] [CMake 0013644]: Default pdb output location changed in cmake 2.8.10
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13644
==
Reported By:Reid Kleckner
Assigned To:
==
Project:CMake
Issue ID: 13644
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-11-02 10:49 EDT
Last Modified: 2012-11-02 10:49 EDT
==
Summary:Default pdb output location changed in cmake 2.8.10
Description:
In the course of adding PDB_OUTPUT_DIRECTORY and related properties and
variables, the default location for pdb files changed.
In our project (DynamoRIO) we have a bunch of targets where we set
RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, etc. The .pdb file would
get created in ${RUNTIME_OUTPUT_DIRECTORY} next to the .dll, which is what we
want. After this change, it would get created in the default output directory,
which is different. Furthermore, this would mean the pdbs never got installed.
Our CMake code:
set_target_properties(dynamorio PROPERTIES
LIBRARY_OUTPUT_DIRECTORY${location_suffix} ${DR_LIBRARY_OUTPUT_DIRECTORY}
RUNTIME_OUTPUT_DIRECTORY${location_suffix} ${DR_LIBRARY_OUTPUT_DIRECTORY}
ARCHIVE_OUTPUT_DIRECTORY${location_suffix} ${DR_LIBRARY_OUTPUT_DIRECTORY}
# The next line is the one I added to work around the problem.
#PDB_OUTPUT_DIRECTORY${location_suffix} ${DR_LIBRARY_OUTPUT_DIRECTORY}
)
From the linker command line:
/out:lib32\debug\dynamorio.dll
/implib:lib32\debug\dynamorio.lib
/pdb:core\dynamorio.pdb
We can easily work around the problem by setting PDB_OUTPUT_DIRECTORY as well as
RUNTIME, ARCHIVE, and LIBRARY, but it'd be nice for other users that aren't
using cmake from version control if the default didn't change.
Upstream issue where we figured this out:
http://code.google.com/p/chromium/issues/detail?id=159092
Original issue:
http://www.cmake.org/Bug/view.php?id=10830
CMake commit that made the change:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f60dbf1
Steps to Reproduce:
1. Create a library target
2. Set the runtime and archive output directory to somewhere non-default
3. Build it
4. Observe that the pdb does not reside next to the dll
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-02 10:49 Reid Kleckner New 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 0013645]: Regression: FindOpenSSL doesn't find anything for MSVC
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13645 == Reported By:Thomas Sondergaard Assigned To: == Project:CMake Issue ID: 13645 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-02 14:23 EDT Last Modified: 2012-11-02 14:23 EDT == Summary:Regression: FindOpenSSL doesn't find anything for MSVC Description: The use of select_library_configurations from SelectLibraryConfigurations.cmake is broken. The variables defined with find_library have the wrong names e.g. LIB_EAY_DEBUG should be LIB_EAY_LIBRARY_DEBUG. Also, with MSVC libeay32d.lib and ssleay32d.lib are no longer recognized - only libeay32MDd.lib and ssleay32MDd == Issue History Date ModifiedUsername FieldChange == 2012-11-02 14:23 Thomas SondergaardNew 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 0013646]: Automoc doesn't recognise #if QT_VERSION = x anymore
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13646 == Reported By:Dominik Schmidt Assigned To: == Project:CMake Issue ID: 13646 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-11-02 17:37 EDT Last Modified: 2012-11-02 17:37 EDT == Summary:Automoc doesn't recognise #if QT_VERSION = x anymore Description: With the latest release of CMake compilation of Tomahawk Player stopped working for us because automoc stopped producing output for a certain file. Obviously code ifdef'ed by #if QT_VERSION = 0x040400 isn't scanned anymore. The commit that fixed building for us: https://github.com/tomahawk-player/tomahawk/commit/c910e1b58f01a42b9f99222e501172576d8cad06 Steps to Reproduce: Put code in #if QT_VERSION = 0x040400 and run automoc on it. Additional Information: Of course I'm talking about CMake built in automoc, not automoc4 from KDE. == Issue History Date ModifiedUsername FieldChange == 2012-11-02 17:37 Dominik SchmidtNew 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
