Re: [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing!
Hello Robert, is there a list which showing the changes between rc1 and rc2, to test such things explicitly? Regards Roman Am 24.02.2015 um 16:01 schrieb Robert Maynard robert.mayn...@kitware.com: I am proud to announce the CMake 3.2 second release candidate. Sources and binaries are available at: http://www.cmake.org/download/ http://www.cmake.org/files/v3.2/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The Compile Features functionality is now aware of features supported by more compilers, including: * Apple Clang (AppleClang) for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple (GNU). * Microsoft Visual Studio (MSVC) for versions 2010 through 2015. * Oracle SolarisStudio (SunPro) version 12.4. * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The file(GENERATE) command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their GENERATED property set to TRUE. Deprecated and Removed Features: * Files written in the cmake-language(7), such as CMakeLists.txt or *.cmake files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The FindOpenGL module no longer explicitly searches for any dependency on X11 libraries with the FindX11 module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *** Changes made since CMake 3.1 include the following. New Features Syntax -- * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The add_custom_command() and add_custom_target() commands learned a new USES_TERMINAL option to request that the command be given direct access to the terminal if possible. The Ninja generator will places such commands in the console pool. Build targets provided by CMake that are meant for individual interactive use, such as install, are now placed in this pool. * A new continue() command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The file(LOCK) subcommand was created to allow CMake processes to synchronize through file and directory locks. * The file(STRINGS) now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as ENCODING options. * The install(EXPORT) command now works with an absolute DESTINATION even if targets in the export set are installed with a destination or *usage requirements* specified relative to the install prefix. The value of the CMAKE_INSTALL_PREFIX variable is hard-coded into the installed export file as the base for relative references. * The try_compile() command source file signature now honors link flags (e.g. CMAKE_EXE_LINKER_FLAGS) in the generated test project. See policy CMP0056. * The try_run() command learned to honor the LINK_LIBRARIES option just as try_compile() already does. * The file(GENERATE) command now generates the output file with the same permissions as the input file if set. * The file(GENERATE) command can now generate files which are used as source files for buildsystem targets.
[cmake-developers] [CMake 0015418]: Wrong encoding for generated .sln
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15418 == Reported By:rhabarbersaft Assigned To: == Project:CMake Issue ID: 15418 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2015-02-25 09:38 EST Last Modified: 2015-02-25 09:38 EST == Summary:Wrong encoding for generated .sln Description: When generating Visual Studio 2008 projects using CMake 3.2.0-rc2, the generated solutions are UTF8-encoded. This leads to Visual Studio not opening them anymore when double-clicking on the .sln file. Changing the encoding of the .sln file to ANSI resolves the problem. The Visual Studio solutions should be generated using ANSI encoding to prevent this problem. == Issue History Date ModifiedUsername FieldChange == 2015-02-25 09:38 rhabarbersaft New Issue == -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing!
Hi Roman, We do attach the short-log of all changes made between each RC version to the bottom of the annoucement. But here are the changes plus the git SHA1's for each ( produced with git log --no-merges --oneline v3.2.0-rc1..v3.2.0-rc2) 99575c9 CMake 3.2.0-rc2 b4005a3 FindCurses: Drop unused check for cbreak in tinfo library a41d621 bootstrap: Add --(no-)system-jsoncpp options a576844 FindJsonCpp: Drop new module due to upstream jsoncpp providing package 1ade687 cmake-gui: Reset generator platform and toolset on configure (#15411) 7e6608f Utilities/Release: Build OS X and Win binaries without OpenSSL bce4e20 FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) 6d19ef9 Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section 029d38f Help: Revise configure_file documentation (#15403) On Wed, Feb 25, 2015 at 9:07 AM, Roman Wüger roman.wue...@gmx.at wrote: Hello Robert, is there a list which showing the changes between rc1 and rc2, to test such things explicitly? Regards Roman Am 24.02.2015 um 16:01 schrieb Robert Maynard robert.mayn...@kitware.com: I am proud to announce the CMake 3.2 second release candidate. Sources and binaries are available at: http://www.cmake.org/download/ http://www.cmake.org/files/v3.2/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The Compile Features functionality is now aware of features supported by more compilers, including: * Apple Clang (AppleClang) for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple (GNU). * Microsoft Visual Studio (MSVC) for versions 2010 through 2015. * Oracle SolarisStudio (SunPro) version 12.4. * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The file(GENERATE) command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their GENERATED property set to TRUE. Deprecated and Removed Features: * Files written in the cmake-language(7), such as CMakeLists.txt or *.cmake files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The FindOpenGL module no longer explicitly searches for any dependency on X11 libraries with the FindX11 module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *** Changes made since CMake 3.1 include the following. New Features Syntax -- * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The add_custom_command() and add_custom_target() commands learned a new USES_TERMINAL option to request that the command be given direct access to the terminal if possible. The Ninja generator will places such commands in the console pool. Build targets provided by CMake that are meant for individual interactive use, such as install, are now placed in this pool. * A new continue() command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The file(LOCK) subcommand was created to allow CMake processes to synchronize through file and directory locks. * The file(STRINGS) now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 02/25/2015 04:11 AM, Raffi Enficiaud wrote: Is it ok if I rebase on 1416d21? Yes, please. Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] KWSys patches
On 02/23/2015 12:55 PM, Brad King wrote: On 02/21/2015 04:33 PM, Domen Vrankar wrote: Attached are patches with fixed patch 3. Thanks. I'll start with the SystemTools change which I've split out into its own commit and pushed here: http://review.source.kitware.com/#/c/19304/ That one is now in KWSys 'master'. Next I've taken the two cleanup changes: http://review.source.kitware.com/19315 http://review.source.kitware.com/19316 For the other two changes, please refactor things to avoid use of function-local classes. They will likely not work on the older compilers KWSys supports. Also, please use the coding style of this-Member when referencing class members from method code. Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
On 02/24/2015 05:25 PM, Stephen Kelly wrote: Until that problem is solved we cannot make object libraries implicitly offer their objects just through tll(). Honestly, the problem is still not clear to me. Consider an object library with some usage requirements: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) Now try using that library and assume that tll() takes the objects without explicit $TARGET_OBJECTS:objlib in the sources: add_library(mylib SHARED ...) target_link_libraries(mylib PUBLIC objlib) We link publicly to forward the usage requirements of objlib through mylib. Now consumers of mylib will get objlib's objects too. That is not desired. It is the same problem as transitive interface sources. My solution to that when first designing object libraries was to disallow the tll() altogether and require the consumer that wants the object files to reference them as $TARGET_OBJECTS:objlib sources explicitly. Of course that pre-dated usage requirements. Now we want to allow add_library(mylib SHARED ... $TARGET_OBJECTS:objlib ...) target_link_libraries(mylib PUBLIC objlib) to put the objects in mylib and also forward usage requirements. So long as the objlib does not have any INTERFACE_SOURCES then it will work well. What I envision for the future is: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib) That will allow consumers of objlib to get the objects through tll() just like any other INTERFACE_SOURCES. What I said in my previous response was that until the transitive interface sources problem is solved I'd rather not allow this. OTOH, since this population of INTERFACE_SOURCES is not automatic perhaps it is simplest and most consistent to go ahead and allow projects to do this. The problem will be no worse than for other interface sources. -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc2 now ready for testing!
Thank you very much Am 25.02.2015 um 15:12 schrieb Robert Maynard robert.mayn...@kitware.com: Hi Roman, We do attach the short-log of all changes made between each RC version to the bottom of the annoucement. But here are the changes plus the git SHA1's for each ( produced with git log --no-merges --oneline v3.2.0-rc1..v3.2.0-rc2) 99575c9 CMake 3.2.0-rc2 b4005a3 FindCurses: Drop unused check for cbreak in tinfo library a41d621 bootstrap: Add --(no-)system-jsoncpp options a576844 FindJsonCpp: Drop new module due to upstream jsoncpp providing package 1ade687 cmake-gui: Reset generator platform and toolset on configure (#15411) 7e6608f Utilities/Release: Build OS X and Win binaries without OpenSSL bce4e20 FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) 6d19ef9 Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section 029d38f Help: Revise configure_file documentation (#15403) On Wed, Feb 25, 2015 at 9:07 AM, Roman Wüger roman.wue...@gmx.at wrote: Hello Robert, is there a list which showing the changes between rc1 and rc2, to test such things explicitly? Regards Roman Am 24.02.2015 um 16:01 schrieb Robert Maynard robert.mayn...@kitware.com: I am proud to announce the CMake 3.2 second release candidate. Sources and binaries are available at: http://www.cmake.org/download/ http://www.cmake.org/files/v3.2/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The Compile Features functionality is now aware of features supported by more compilers, including: * Apple Clang (AppleClang) for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple (GNU). * Microsoft Visual Studio (MSVC) for versions 2010 through 2015. * Oracle SolarisStudio (SunPro) version 12.4. * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The file(GENERATE) command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their GENERATED property set to TRUE. Deprecated and Removed Features: * Files written in the cmake-language(7), such as CMakeLists.txt or *.cmake files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The FindOpenGL module no longer explicitly searches for any dependency on X11 libraries with the FindX11 module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *** Changes made since CMake 3.1 include the following. New Features Syntax -- * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The add_custom_command() and add_custom_target() commands learned a new USES_TERMINAL option to request that the command be given direct access to the terminal if possible. The Ninja generator will places such commands in the console pool. Build targets provided by CMake that are meant for individual interactive use, such as install, are now placed in this pool. * A new continue() command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The file(LOCK) subcommand was created to allow CMake processes to synchronize through
[cmake-developers] Ninja Generator and CMAKE_VERBOSE_MAKEFILE
Hello, For our CI and production build we call cmake --build to execute the actual build. To be able to examine the build logs we added -DCMAKE_VERBOSE_MAKEFILE=ON to the configuration step. This worked as expected for the Makefile generator but is ignored for Ninja. As far as I understand the code, the Makefile generator adds a VERBOSE statement to the Makefile so that make automatically switches to verbose mode when being executed. Unfortunately Ninja has no equivalent option. As a work-around would it be possible that cmake --build examines the cache, detects CMAKE_VERBOSE_MAKEFILE=ON and adds a -v to the Ninja invocation? If you think that this is a reasonable approach could you please give me some pointers where to insert the necessary code? Thanks, Gregor -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH v6 2/2] Add XCTest example to test Frameworks and Cocoa App Bundles
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Tests/CMakeLists.txt | 13 +
Tests/XCTest/CMakeLists.txt| 62 ++
Tests/XCTest/CocoaExample/AppDelegate.h| 7 +
Tests/XCTest/CocoaExample/AppDelegate.m| 18 +
Tests/XCTest/CocoaExample/Info.plist | 30 +
Tests/XCTest/CocoaExample/MainMenu.xib | 680 +
Tests/XCTest/CocoaExample/main.m | 5 +
Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m | 13 +
Tests/XCTest/FrameworkExample/FrameworkExample.c | 6 +
Tests/XCTest/FrameworkExample/FrameworkExample.h | 1 +
Tests/XCTest/FrameworkExample/Info.plist | 28 +
.../FrameworkExampleTests/FrameworkExampleTests.m | 16 +
Tests/XCTest/FrameworkExampleTests/Info.plist | 24 +
13 files changed, 903 insertions(+)
create mode 100644 Tests/XCTest/CMakeLists.txt
create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.h
create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.m
create mode 100644 Tests/XCTest/CocoaExample/Info.plist
create mode 100644 Tests/XCTest/CocoaExample/MainMenu.xib
create mode 100644 Tests/XCTest/CocoaExample/main.m
create mode 100644 Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m
create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.c
create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.h
create mode 100644 Tests/XCTest/FrameworkExample/Info.plist
create mode 100644 Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m
create mode 100644 Tests/XCTest/FrameworkExampleTests/Info.plist
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 08765de..6afedf2 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -3064,4 +3064,17 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
if(NOT CMake_TEST_EXTERNAL_CMAKE)
add_subdirectory(CMakeTests)
endif()
+
+ if(XCODE_VERSION AND NOT ${XCODE_VERSION} VERSION_LESS 5)
+add_test(XCTest ${CMAKE_CTEST_COMMAND}
+ --build-and-test
+ ${CMake_SOURCE_DIR}/Tests/XCTest
+ ${CMake_BINARY_DIR}/Tests/XCTest
+ ${build_generator_args}
+ --build-project XCTest
+ --build-options ${build_options}
+ --test-command ${CMAKE_CTEST_COMMAND} -C \${CTEST_CONFIGURATION_TYPE} -V
+ )
+list(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/XCTest)
+ endif()
endif()
diff --git a/Tests/XCTest/CMakeLists.txt b/Tests/XCTest/CMakeLists.txt
new file mode 100644
index 000..e13d126
--- /dev/null
+++ b/Tests/XCTest/CMakeLists.txt
@@ -0,0 +1,62 @@
+cmake_minimum_required(VERSION 3.1)
+project(XCTest)
+enable_testing()
+
+set(CMAKE_SKIP_RPATH OFF)
+
+include(XCTestUtilities)
+
+# Framework
+
+add_library(FrameworkExample SHARED
+ FrameworkExample/FrameworkExample.c
+ FrameworkExample/FrameworkExample.h
+ FrameworkExample/Info.plist)
+
+target_include_directories(FrameworkExample PUBLIC .)
+
+set_target_properties(FrameworkExample PROPERTIES
+ FRAMEWORK TRUE
+ VERSION 1.0.0
+ SOVERSION 1.0.0
+ FRAMEWORK_VERSION A
+ MACOSX_FRAMEWORK_INFO_PLIST
${CMAKE_CURRENT_SOURCE_DIR}/FrameworkExample/Info.plist
+ PUBLIC_HEADER FrameworkExample/FrameworkExample.h)
+
+# XCTest for Framework
+
+add_xctest(FrameworkExampleTests FrameworkExample
+ FrameworkExampleTests/FrameworkExampleTests.m
+ FrameworkExampleTests/Info.plist)
+
+set_target_properties(FrameworkExampleTests PROPERTIES
+ MACOSX_BUNDLE_INFO_PLIST
${CMAKE_CURRENT_SOURCE_DIR}/FrameworkExampleTests/Info.plist
+ )
+
+add_test_xctest(XCTest.FrameworkExample FrameworkExampleTests)
+
+# Cocoa App Bundle
+
+add_executable(CocoaExample MACOSX_BUNDLE
+ CocoaExample/main.m
+ CocoaExample/AppDelegate.m
+ CocoaExample/AppDelegate.h
+ CocoaExample/MainMenu.xib
+)
+
+find_library(FOUNDATION_LIBRARY Foundation)
+find_library(APPKIT_LIBRARY AppKit)
+mark_as_advanced(FOUNDATION_LIBRARY APPKIT_LIBRARY)
+
+target_link_libraries(CocoaExample PRIVATE ${FOUNDATION_LIBRARY}
${APPKIT_LIBRARY})
+
+set_target_properties(CocoaExample PROPERTIES
+ MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/CocoaExample/Info.plist
+ RESOURCE CocoaExample/MainMenu.xib)
+
+# XCTest for Cocoa App Bundle
+
+add_xctest(CocoaExampleTests CocoaExample
+ CocoaExampleTests/CocoaExampleTests.m)
+
+add_test_xctest(XCTest.CocoaExample CocoaExampleTests)
diff --git a/Tests/XCTest/CocoaExample/AppDelegate.h
b/Tests/XCTest/CocoaExample/AppDelegate.h
new file mode 100644
index 000..69b6e0f
--- /dev/null
+++ b/Tests/XCTest/CocoaExample/AppDelegate.h
@@ -0,0 +1,7 @@
+#import Cocoa/Cocoa.h
+
+@interface AppDelegate : NSObject NSApplicationDelegate
+
+
+@end
+
diff --git a/Tests/XCTest/CocoaExample/AppDelegate.m
b/Tests/XCTest/CocoaExample/AppDelegate.m
new file mode 100644
index 000..07af62f
--- /dev/null
+++ b/Tests/XCTest/CocoaExample/AppDelegate.m
@@ -0,0 +1,18 @@
+#import AppDelegate.h
+
+@interface AppDelegate ()
+
+@property
[cmake-developers] [PATCH v6 1/2] Add handling for XCTest bundles
An XCTest bundle is a CFBundle with a special product-type and bundle
extension. For more information about XCTest visit the Mac
Developer library at:
http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Help/manual/cmake-modules.7.rst| 1 +
Help/manual/cmake-properties.7.rst | 1 +
Help/module/XCTestUtilities.rst| 1 +
Help/prop_tgt/XCTEST.rst | 13
Help/release/dev/xcode-xctest.rst | 6 ++
Modules/XCTestUtilities.cmake | 123 +
Source/cmGlobalXCodeGenerator.cxx | 12 +++-
Source/cmTarget.cxx| 16 -
Source/cmTarget.h | 3 +
9 files changed, 173 insertions(+), 3 deletions(-)
create mode 100644 Help/module/XCTestUtilities.rst
create mode 100644 Help/prop_tgt/XCTEST.rst
create mode 100644 Help/release/dev/xcode-xctest.rst
create mode 100644 Modules/XCTestUtilities.cmake
diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst
index 2b26cc9..a2a2d24 100644
--- a/Help/manual/cmake-modules.7.rst
+++ b/Help/manual/cmake-modules.7.rst
@@ -241,3 +241,4 @@ All Modules
/module/Use_wxWindows
/module/WriteBasicConfigVersionFile
/module/WriteCompilerDetectionHeader
+ /module/XCTestUtilities
diff --git a/Help/manual/cmake-properties.7.rst
b/Help/manual/cmake-properties.7.rst
index 19fdf23..1dff33e 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -243,6 +243,7 @@ Properties on Targets
/prop_tgt/VS_WINRT_REFERENCES
/prop_tgt/WIN32_EXECUTABLE
/prop_tgt/XCODE_ATTRIBUTE_an-attribute
+ /prop_tgt/XCTEST
Properties on Tests
===
diff --git a/Help/module/XCTestUtilities.rst b/Help/module/XCTestUtilities.rst
new file mode 100644
index 000..c96f515
--- /dev/null
+++ b/Help/module/XCTestUtilities.rst
@@ -0,0 +1 @@
+.. cmake-module:: ../../Modules/XCTestUtilities.cmake
diff --git a/Help/prop_tgt/XCTEST.rst b/Help/prop_tgt/XCTEST.rst
new file mode 100644
index 000..8a2ef8b
--- /dev/null
+++ b/Help/prop_tgt/XCTEST.rst
@@ -0,0 +1,13 @@
+XCTEST
+--
+
+This target is a XCTest CFBundle on the Mac.
+
+This property will usually get set via the ``add_xctest`` macro in
+:module:`XCTestUtilities` module.
+
+If a module library target has this property set to true it will be
+built as a CFBundle when built on the mac. It will have the directory
+structure required for a CFBundle.
+
+This property depends on :prop_tgt:`BUNDLE` to be effective.
diff --git a/Help/release/dev/xcode-xctest.rst
b/Help/release/dev/xcode-xctest.rst
new file mode 100644
index 000..af9f705
--- /dev/null
+++ b/Help/release/dev/xcode-xctest.rst
@@ -0,0 +1,6 @@
+Xcode XCTest Support
+
+
+* CMake gained the abiltity to create XCTest bundles to test
+ Frameworks and App Bundles within Xcode. The :module:`XCTestUtilities`
+ module provides convenience functions to handle :prop_tgt:`XCTEST` bundles.
diff --git a/Modules/XCTestUtilities.cmake b/Modules/XCTestUtilities.cmake
new file mode 100644
index 000..0ff648c
--- /dev/null
+++ b/Modules/XCTestUtilities.cmake
@@ -0,0 +1,123 @@
+#.rst:
+# XCTestUtilities
+# ---
+#
+# Functions to help creating and executing XCTest bundles.
+#
+# An XCTest bundle is a CFBundle with a special product-type
+# and bundle extension. For more information about XCTest visit
+# the Mac Developer library at:
+#
http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/
+#
+# The following functions are provided by this module:
+#
+# ::
+#
+#add_xctest
+#add_test_xctest
+#
+# ::
+#
+# add_xctest(target testee)
+#
+# Create a XCTest bundle named target which will test the target
+# testee. Supported target types for testee are Frameworks and
+# App Bundles.
+#
+# ::
+#
+# add_test_xctest(name target)
+#
+# Add an XCTest bundle to the project to be run by :manual:`ctest(1)`.
+# The test will be named name and tests target.
+
+#=
+# Copyright 2015 Gregor Jasny
+#
+# Distributed under the OSI-approved BSD License (the License);
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+# License text for the above reference.)
+
+function(add_xctest target testee)
+
+ if(NOT CMAKE_OSX_SYSROOT)
+message(STATUS Adding XCTest bundles requires CMAKE_OSX_SYSROOT to be
set.)
+ endif()
+
+ # check that testee is a valid target type
+ get_target_property(TESTEE_TYPE ${testee} TYPE)
+
Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
On Mon, Feb 23, 2015 at 13:44:13 -0500, Ben Boeckel wrote: snip After discussion with Brad here, the current, tentative, plan is as follows: - When creating $LINK_ONLY generator expressions, if the name is a target, add $TARGET_NAME as well. This will help the exporter find targets which need exporting from the build. - When exporting, if $LINK_ONLY:$TARGET_NAME:ifacelib is found and ifacelib has no link interface, remove the entire expression. This will address bug #15415 so that interface libraries linked with PRIVATE can stay unexported. This will at least allow the INTERFACE-for-OBJECT use case work for PRIVATE usage of them. For the OBJECT library half of this: - Add support for tll(objlib foo) and tll(foo objlib); tll(objlib1 objlib2) will be unsupported for now; implementation for it can come later as there are could be other issues with that case. - Use $LINK_ONLY for PRIVATE libraries in the INTERFACE of object libraries (will use the same code path as static libraries here). - When exporting, if an OBJECT library is found to be referenced such that it also needs to be exported, add it to the current export set as an INTERFACE library with all of the interface properties of the object library. * The above check for stripping LINK_ONLY will also do so for object libraries. * Targets exported this way will be placed in the same export set as the target which triggered it and will share a namespace, export set, etc. The name will be mangled as it is purely an implementation detail. * Manually exporting object libraries will still be disallowed. Things that crossed my mind since the discussion (or were mentioned before but not resolved completely): - Make it an error to use a non-empty INTERFACE_SOURCES for object libraries (a new policy). - When exporting the object library's interface, empty INTERFACE_SOURCES regardless of the above policy ($TARGET_OBJECTS will only cause errors on the now-INTERFACE library). Stripping it in the common case is possible, but it could be deep in genex conditions and not able to be found. Another, much lower priority, branch (only tangentially related to either of the above) would be to make the following work as one would expect: add_library(A OBJECT a.c) add_library(B OBJECT b.c $TARGET_OBJECTS:A) add_library(C SHARED c.c $TARGET_OBJECTS:B) Where $TARGET_OBJECTS:B would bring in $TARGET_OBJECTS:A as well (currently OBJECT libraries may not have TARGET_OBJECTS as sources). I have a patch for the implementation of this already if anyone else would like to add the tests and docs for it before I get around to it. Thoughts? --Ben -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH v6 0/2] Add XCTest Bundle Support
Hello, this series contains the latest XCTest patches. Changes since v5: * Rebased against master (could drop two applied patches) * kept help modules list sorted * indirected xctest wiring Thanks, Gregor Gregor Jasny (2): Add handling for XCTest bundles Add XCTest example to test Frameworks and Cocoa App Bundles Help/manual/cmake-modules.7.rst| 1 + Help/manual/cmake-properties.7.rst | 1 + Help/module/XCTestUtilities.rst| 1 + Help/prop_tgt/XCTEST.rst | 13 + Help/release/dev/xcode-xctest.rst | 6 + Modules/XCTestUtilities.cmake | 123 Source/cmGlobalXCodeGenerator.cxx | 12 +- Source/cmTarget.cxx| 16 +- Source/cmTarget.h | 3 + Tests/CMakeLists.txt | 13 + Tests/XCTest/CMakeLists.txt| 62 ++ Tests/XCTest/CocoaExample/AppDelegate.h| 7 + Tests/XCTest/CocoaExample/AppDelegate.m| 18 + Tests/XCTest/CocoaExample/Info.plist | 30 + Tests/XCTest/CocoaExample/MainMenu.xib | 680 + Tests/XCTest/CocoaExample/main.m | 5 + Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m | 13 + Tests/XCTest/FrameworkExample/FrameworkExample.c | 6 + Tests/XCTest/FrameworkExample/FrameworkExample.h | 1 + Tests/XCTest/FrameworkExample/Info.plist | 28 + .../FrameworkExampleTests/FrameworkExampleTests.m | 16 + Tests/XCTest/FrameworkExampleTests/Info.plist | 24 + 22 files changed, 1076 insertions(+), 3 deletions(-) create mode 100644 Help/module/XCTestUtilities.rst create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/release/dev/xcode-xctest.rst create mode 100644 Modules/XCTestUtilities.cmake create mode 100644 Tests/XCTest/CMakeLists.txt create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.h create mode 100644 Tests/XCTest/CocoaExample/AppDelegate.m create mode 100644 Tests/XCTest/CocoaExample/Info.plist create mode 100644 Tests/XCTest/CocoaExample/MainMenu.xib create mode 100644 Tests/XCTest/CocoaExample/main.m create mode 100644 Tests/XCTest/CocoaExampleTests/CocoaExampleTests.m create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.c create mode 100644 Tests/XCTest/FrameworkExample/FrameworkExample.h create mode 100644 Tests/XCTest/FrameworkExample/Info.plist create mode 100644 Tests/XCTest/FrameworkExampleTests/FrameworkExampleTests.m create mode 100644 Tests/XCTest/FrameworkExampleTests/Info.plist -- 2.3.0 -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja Generator and CMAKE_VERBOSE_MAKEFILE
On 02/25/2015 12:38 PM, Gregor Jasny wrote: Ninja has no equivalent option. As a work-around would it be possible that cmake --build examines the cache, detects CMAKE_VERBOSE_MAKEFILE=ON and adds a -v to the Ninja invocation? If you know that the build tree was generated with the Ninja generator then you can do cmake --build . -- -v to pass the flag to ninja. Of course if you knew that then you could always run ninja -v instead of using cmake --build ;) As a work-around would it be possible that cmake --build examines the cache, detects CMAKE_VERBOSE_MAKEFILE=ON and adds a -v to the Ninja invocation? If you think that this is a reasonable approach could you please give me some pointers where to insert the necessary code? Yes, I think that is reasonable if the above is not sufficient. The cmake::Build method in Source/cmake.cxx loads the cache already to get CMAKE_GENERATOR and create the generator, which is then used to compute the generator-specific build command. You could extract CMAKE_VERBOSE_MAKEFILE there too and extend the signatures of the methods as necessary to thread the value through. -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Pass CMAKE_VERBOSE_MAKEFILE value to Ninja Generator
Ninja build system does not support a in-Makefile verbositiy
switch. So we use cmake --build as a fall back to extract the
CMAKE_VERBOSE_MAKEFILE property and pass it as an optional
-v argument to Ninja.
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Source/cmGlobalGenerator.cxx | 2 ++
Source/cmGlobalGenerator.h| 5 +
Source/cmGlobalNinjaGenerator.cxx | 5 +
Source/cmake.cxx | 5 +
4 files changed, 17 insertions(+)
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 6147009..0a4e60a 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -69,6 +69,8 @@ cmGlobalGenerator::cmGlobalGenerator()
this-ExtraGenerator = 0;
this-CurrentLocalGenerator = 0;
this-TryCompileOuterMakefile = 0;
+
+ this-VerboseBuild = false;
}
cmGlobalGenerator::~cmGlobalGenerator()
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 08f061a..1e948f3 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -349,6 +349,9 @@ public:
std::setcmTarget const* const
GetFilenameTargetDepends(cmSourceFile* sf) const;
+ void SetVerboseBuild(bool verbose) { this-VerboseBuild = verbose; }
+ bool GetVerboseBuild() const { return this-VerboseBuild; }
+
#if defined(CMAKE_BUILD_WITH_CMAKE)
cmFileLockPool GetFileLockPool() { return FileLockPool; }
#endif
@@ -506,6 +509,8 @@ private:
mutable std::mapcmSourceFile*, std::setcmTarget const*
FilenameTargetDepends;
+ bool VerboseBuild;
+
#if defined(CMAKE_BUILD_WITH_CMAKE)
// Pool of file locks
cmFileLockPool FileLockPool;
diff --git a/Source/cmGlobalNinjaGenerator.cxx
b/Source/cmGlobalNinjaGenerator.cxx
index 3c07be1..850f891 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -580,6 +580,11 @@ void cmGlobalNinjaGenerator
this-SelectMakeProgram(makeProgram)
);
+ if(GetVerboseBuild())
+{
+makeCommand.push_back(-v);
+}
+
makeCommand.insert(makeCommand.end(),
makeOptions.begin(), makeOptions.end());
if(!targetName.empty())
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 47be481..19835c4 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -2789,6 +2789,11 @@ int cmake::Build(const std::string dir,
return 1;
}
projName = it.GetValue();
+ if(it.Find(CMAKE_VERBOSE_MAKEFILE))
+{
+bool verboseBuild = it.GetValueAsBool();
+gen-SetVerboseBuild(verboseBuild);
+}
return gen-Build(, dir,
projName, target,
output,
--
2.3.0
--
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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015419]: QtAutogen does not regenerate moc file when moc inputs change
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15419 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15419 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-02-25 22:26 CET Last Modified: 2015-02-25 22:26 CET == Summary:QtAutogen does not regenerate moc file when moc inputs change Description: There are two file-inputs to moc in Qt 5 - the C++ header file being moc'd, and the optional JSON metadata files referenced therein. CMake performs file timestamp comparison on the C++ header file during autogen, but does not do similar tracking for the JSON files. CMake should parse the C++ header file for the Q_PLUGIN_METADATA macro FILE argument, and add the list of referenced JSON files to the generated AutogenInfo.cmake file. The contents of this list should then be file-timestamp-checked. Similar logic for lists of input files affecting the tool input was added for qrc files in commit v3.2.0-rc1~480^2 (QtAutogen: Regenerate qrc files if their input changes (http://public.kitware.com/Bug/view.php?id=15074), 2014-09-17), and the solution to this issue with the moc tool will be similar. == Issue History Date ModifiedUsername FieldChange == 2015-02-25 22:26 Stephen Kelly New Issue == -- 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://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015420]: QtAutogen should track uic external inputs
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15420 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15420 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-02-25 22:44 CET Last Modified: 2015-02-25 22:44 CET == Summary:QtAutogen should track uic external inputs Description: Similar to the issue reported in http://public.kitware.com/Bug/view.php?id=15419, the uic tool may read external files specified in the .ui file. For example * An instance of a QLabel can specify a pixmap to load. If the pixmap changes, uic should be re-run. * Similarly, a QPushButton can have an icon specified on the filesystem. * A ui file can refer to a .qrc file. If the qrc file is known to cmake and rcc is run on it to generate the result into the target, uic should be re-run too (afterward). == Issue History Date ModifiedUsername FieldChange == 2015-02-25 22:44 Stephen Kelly New Issue == -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Pass CMAKE_VERBOSE_MAKEFILE value to Ninja Generator
On 02/25/2015 04:24 PM, Gregor Jasny wrote:
Ninja build system does not support a in-Makefile verbositiy
switch. So we use cmake --build as a fall back to extract the
CMAKE_VERBOSE_MAKEFILE property and pass it as an optional
-v argument to Ninja.
Thanks for working on this.
+ if(it.Find(CMAKE_VERBOSE_MAKEFILE))
+{
+bool verboseBuild = it.GetValueAsBool();
+gen-SetVerboseBuild(verboseBuild);
+}
return gen-Build(, dir,
projName, target,
output,
Instead of having a generator-wide state (member variable) that
affects only one method, please extend the Build() and
GenerateBuildCommand() signatures to thread the value through.
Thanks,
-Brad
--
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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
Brad King wrote: On 02/24/2015 05:25 PM, Stephen Kelly wrote: Until that problem is solved we cannot make object libraries implicitly offer their objects just through tll(). Honestly, the problem is still not clear to me. Consider an object library with some usage requirements: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) Now try using that library and assume that tll() takes the objects without explicit $TARGET_OBJECTS:objlib in the sources: add_library(mylib SHARED ...) target_link_libraries(mylib PUBLIC objlib) We link publicly to forward the usage requirements of objlib through mylib. Now consumers of mylib will get objlib's objects too. That is not desired. It is the same problem as transitive interface sources. Ok, I see. Now I also understand Bens commit message referenced at the beginning of the thread: The real fix is to make INTERFACE_SOURCES only applicable when directly linked and not transitive, but that is a bigger change. What I envision for the future is: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib) Do you envision that as the idiomatic way to declare object libraries? Would CMakeLists authors have to write the target_sources line explicitly, if this future becomes possible? Thanks, Steve. -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
Ben Boeckel wrote: On Wed, Feb 25, 2015 at 22:57:13 +0100, Stephen Kelly wrote: What I envision for the future is: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib) Do you envision that as the idiomatic way to declare object libraries? It would be nice if that's the pattern anyways. ... Would CMakeLists authors have to write the target_sources line explicitly, if this future becomes possible? No ... But then the idiomatic way would be add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) Right? Not the above which also includes a target_sources call, right? Thanks, Steve. -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
On Wed, Feb 25, 2015 at 22:57:13 +0100, Stephen Kelly wrote: What I envision for the future is: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib) Do you envision that as the idiomatic way to declare object libraries? It would be nice if that's the pattern anyways. There'd probably have to be a policy to ignore using TARGET_OBJECTS within target_sources (only for itself? except INTERFACE libs? So many edge cases :/ ). Would CMakeLists authors have to write the target_sources line explicitly, if this future becomes possible? No, I have a commit which initializes INTERFACE_SOURCES when object libraries are created. Currently floating on its own branch. --Ben -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)
Ben Boeckel wrote:
It is just as easy to get into this situation when linking static
libraries, right? Object libraries are not part of the problem, right? Or
could you post a sscce?
It is, so maybe it's less of an issue. I just think it is much easier to
stumble upon it when you start throwing objects directly into link lines
implicitly rather than with a staticWithGlobalStatic - {sharedA,
sharedB} - exeUsingAandB setup.
Right. Consider
add_library(upstream ...)
add_library(middle ...)
target_link_libraries(middle ${SCOPE} upstream}
add_executable(consumer1)
target_link_libraries(consumer1 middle)
add_library(consumer2 SHARED)
target_link_libraries(consumer2 middle)
We have these possible scenarios (omitting INTERFACE scope, and omitting
middle=OBJECT because I think it doesn't change anything):
upstreamSCOPE middle
-- -
STATIC PRIVATESTATIC
OBJECT PRIVATESTATIC
STATIC PUBLIC STATIC
OBJECT PUBLIC STATIC
STATIC PRIVATESHARED
SHARED PRIVATESHARED
OBJECT PRIVATESHARED
STATIC PUBLIC SHARED
SHARED PUBLIC SHARED
OBJECT PUBLIC SHARED
Omitting the upstream = SHARED or STATIC cases too, because I think they're
not relevant to this discussion.
upstreamSCOPE middle
-- -
OBJECT PRIVATESTATIC
OBJECT PUBLIC STATIC
OBJECT PRIVATESHARED
OBJECT PUBLIC SHARED
If middle is STATIC, and SCOPE is PRIVATE, then the upstream objects are
archived together with the rest of middle. Consumers use middle as if the
upstream objects were not declared separately.
If SCOPE is PUBLIC, perhaps it should be treated as PRIVATE or INTERFACE?
That is, either not archive the upstream objects with middle (letting
downstreams link the objects directly instead), or not link them in with
downstreams (which will get them anyway through linking with middle).
If middle is SHARED and scope is PRIVATE, then there is no problem (Except
perhaps the global object issue, but that is present also if upstream is
STATIC and it can be argued that no library should legitimately do that
anyway).
If middle is SHARED and scope is PUBLIC, then the situation is very similar
to upstream=STATIC, in that the objects get compiled into middle and into
each of the consumers. Is this an undesired effect?
Let's imagine upstream is statically compiled zlib and middle is the
FooCompress library which uses zlib in its implementation and uses zlib
headers in FooCompress.h, but doesn't dllexport the zlib symbols (Is that a
realistic scenario?), and expects consumers to also link the zlib.a instead.
I have trouble imagining any other reason a SHARED library would PUBLIC link
a STATIC or OBJECT library otherwise. But in the scenario I described,
consumers must link the zlib.a (or .o), right?
Or should it be prohibited to put OBJECT libraries in the INTERFACE of
SHARED libraries?
Again, even if the upstream is STATIC, this is a problem only in the
presence of global objects provided by upstream.
For the diamond-usage problem, is there some way of utilizing the
COMPATIBLE_INTERFACES to deny the mixing of two libraries where each
built with an object libraries' objects? Having a property to trigger
that would be nice...
Yes, that's possible by adding an ExclusiveList compatible type and
populating an appropriate property when linking to OBJECT libraries. I've
written a prototype and can clean it up and post it if that's part of the
solution.
As long as it is opt-in, I'm fine with this (it only really makes sense
in the presence of global statics with dtors).
That appears to be the only problem being discussed here. I'm sure
ExclusiveList could help, but in the case you describe, CMake wouldn't
populate anything automatically (thereby making it opt-in).
Until that problem is solved we cannot make object libraries
implicitly offer their objects just through tll().
Honestly, the problem is still not clear to me. Is it something you would
want to write and expect to be correct, but which would actually be
incorrect? Is the static global object instance a necessary part of the
problem-scenario?
So this problem came up in a project where the current code uses LIBADD
in autotools. These added libraries are conditionally built and have
varying usage requirements (headers, linking, defines, etc.). Oh, they
also have symbols which need exporting.
What is the type of these libraries? I'm guessing SHARED as you talk about
exporting.
Yes, I already tried using static libraries (I think $LINK_ONLY made
the duplicate symbols occur in dependent projects which use shared libs
through the transitive linking which then all went into an executable);
that's how I ended up trying object libraries.
Maybe something I wrote above is fuel for thought here?
Thanks,
Steve.
--
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi Brad, Thanks, I started addressing the issues, hopefully I will finish today. Is it ok if I rebase on 1416d21? Best, Raffi On 23 Feb 2015, at 18:54, Brad King brad.k...@kitware.com wrote: Hi Raffi, Your matlab-enabled nightly builds have been clean for a few days on all the platforms. I've moved them to the Nightly Expected section of the dashboard. Now I'm just waiting on your next updates to the module based on my comments elsewhere in this thread to proceed with the FindMatlab topic. Thanks, -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Questions about code reviews and static analysis tools for TU Delft research
Thanks for answering Brad, I appreciate it. - Radjino From: Brad King [brad.k...@kitware.com] Sent: Tuesday, February 24, 2015 4:27 PM To: Radjino Bholanath Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Questions about code reviews and static analysis tools for TU Delft research Every change is reviewed before it is merged to the 'master' branch for official inclusion. ... We also use dynamic analysis with valgrind and Clang AddressSanitizer. -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: CMake Error when configure nanomsg on Windows 8.1 and VS2013
I extracted .zip with WinRAR. Since you said extracting the .zip is expected to work,I uninstall CMake and extracting the .zip again. It's works well this time. No only that, I've done the same thing(extracting and run directly) on another clean machine,it also works well. It's strange,right? Maybe I did some stupid things when i extracted CMake the first time.Who knows. Thank you again for your help! 2015-02-25 0:10 GMT+08:00 Brad King brad.k...@kitware.com: On 02/24/2015 11:00 AM, 刘铁刚 wrote: what i did is only download and unzip the cmake-3.2.0-rc1-win32-x86.zip. Now it works well on this machine after I installed it again with the cmake-3.2.0-rc1-win32-x86.exe. I'm glad you have it working, but extracting the .zip is expected to work. What tool did you use to extract it? -Brad -- 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://public.kitware.com/mailman/listinfo/cmake-developers
