Re: [CMake] Check whether C++ headers are self-sufficient
I also have this implemented - in my case, the headers are fine to include
in a .cpp with just a do-nothing main function and build into an
executable, testing linking too.
https://github.com/rpavlik/util-headers/blob/master/tests/cleanbuild/CMakeLists.txt
Ryan
On Sat, Mar 14, 2015 at 8:56 AM Robert Maynard robert.mayn...@kitware.com
wrote:
I have worked on projects where we do something fairly similar. The
significant difference is that we create only a single executable per
directory. All told is it a fairly simple and looks something like:
# Builds a source file and an executable that does nothing other than
# compile the given header files.
function(add_header_test name)
set(hfiles ${ARGN})
set(suffix .cpp)
set(cxxfiles)
foreach (header ${ARGN})
string(REPLACE ${CMAKE_CURRENT_BINARY_DIR} header ${header})
get_filename_component(headername ${header} NAME_WE)
set(src
${CMAKE_CURRENT_BINARY_DIR}/TestBuild_${name}_${headername}${suffix})
configure_file(${SMTK_SOURCE_DIR}/CMake/TestBuild.cxx.in ${src} @ONLY)
set(cxxfiles ${cxxfiles} ${src})
endforeach (header)
add_library(TestBuild_${name} ${cxxfiles} ${hfiles})
target_include_directories(TestBuild_${name} ${CMAKE_CURRENT_BINARY_DIR})
set_source_files_properties(${hfiles} PROPERTIES HEADER_FILE_ONLY TRUE)
endfunction(add_header_test)
On Sat, Mar 14, 2015 at 8:19 AM, Christoph Grüninger f...@grueninger.de
wrote:
Dear CMakers,
I want to have all my C++ headers self-sufficient (self-contained),
i.e., a header can be included without additional includes. This is not
only handy but also part of Google's C++ styleguide [2].
It would be great to have a make target (let's call it headercheck),
that can check for this, by compiling a simple test.cc file for each
current_header.h:
#include config.h
#include current_header.h
#include current_header.h
Additionally it would be great to have such a target for every folder
(checking all headers recursively) and every header that is explicitly
passed as an argument.
We tried this with CMake: We generate a test.cc file per header and
create a library for every cc file. The problem is, that we get hundreds
of additional targets, we generate a lot of folders and files which can
increase our build directory size by an order of magnitude and it does
not work properly on a per file or per directory basis.
What do you think, is there a good way to have such a target headercheck
with CMake? Or would it be better to include it as a CTest? Or better as
an external (bash) script as proposed in [1]?
If it can be done in a good way with CMake, would it be of interest to
include it as a feature in CMake? Or as an external project similar to
UseLATEX.cmake?
Bye
Christoph
[1]
http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c
[2]
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers
--
When you die, that does not mean that you lose to cancer,
you beat cancer by how you live, why you live, and in the
manner in which you live. -- Stuart Scott, 1965-2015
--
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
--
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
--
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:
[cmake-developers] [PATCH v8 4/5] Tests: Add XCTest example to test Frameworks and Cocoa App Bundles
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
Tests/CMakeLists.txt | 4 +
Tests/XCTest/CMakeLists.txt| 57 ++
Tests/XCTest/CocoaExample/AppDelegate.h| 6 +
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, 888 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 bcb1590..e7cf220 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1499,6 +1499,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P
${CMake_SOURCE_DIR}/Utilities/Release
)
endif()
+ if(CMake_TEST_XCODE_VERSION AND NOT CMake_TEST_XCODE_VERSION VERSION_LESS 5)
+ADD_TEST_MACRO(XCTest ${CMAKE_CTEST_COMMAND} -C $CONFIGURATION -V)
+ endif()
+
add_test(linkorder1 ${CMAKE_CTEST_COMMAND}
--build-and-test
${CMake_SOURCE_DIR}/Tests/LinkLineOrder
diff --git a/Tests/XCTest/CMakeLists.txt b/Tests/XCTest/CMakeLists.txt
new file mode 100644
index 000..e866623
--- /dev/null
+++ b/Tests/XCTest/CMakeLists.txt
@@ -0,0 +1,57 @@
+cmake_minimum_required(VERSION 3.1)
+project(XCTest)
+enable_testing()
+
+find_package(XCTest REQUIRED)
+
+# 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
+
+xctest_add_bundle(FrameworkExampleTests FrameworkExample
+ FrameworkExampleTests/FrameworkExampleTests.m
+ FrameworkExampleTests/Info.plist)
+
+set_target_properties(FrameworkExampleTests PROPERTIES
+ MACOSX_BUNDLE_INFO_PLIST
${CMAKE_CURRENT_SOURCE_DIR}/FrameworkExampleTests/Info.plist
+ )
+
+xctest_add_test(XCTest.FrameworkExample FrameworkExampleTests)
+
+# Cocoa App Bundle
+
+add_executable(CocoaExample MACOSX_BUNDLE
+ CocoaExample/main.m
+ CocoaExample/AppDelegate.m
+ CocoaExample/AppDelegate.h
+ CocoaExample/MainMenu.xib
+)
+
+target_link_libraries(CocoaExample PRIVATE -framework Foundation)
+target_link_libraries(CocoaExample PRIVATE -framework AppKit)
+
+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
+
+xctest_add_bundle(CocoaExampleTests CocoaExample
+ CocoaExampleTests/CocoaExampleTests.m)
+
+xctest_add_test(XCTest.CocoaExample CocoaExampleTests)
diff --git a/Tests/XCTest/CocoaExample/AppDelegate.h
b/Tests/XCTest/CocoaExample/AppDelegate.h
new file mode 100644
index 000..4bf4101
--- /dev/null
+++ b/Tests/XCTest/CocoaExample/AppDelegate.h
@@ -0,0 +1,6 @@
+#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 (assign) IBOutlet NSWindow *window;
+@end
+
+@implementation AppDelegate
+
+- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
+// Insert code here to initialize your application
+}
+
+- (void)applicationWillTerminate:(NSNotification *)aNotification {
+// Insert code here to tear down your application
+}
+
+@end
diff --git
[cmake-developers] [PATCH v8 2/5] OS X: 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-properties.7.rst | 1 +
Help/prop_tgt/XCTEST.rst | 13 +
Source/cmGlobalXCodeGenerator.cxx | 12 ++--
Source/cmTarget.cxx| 16 +++-
Source/cmTarget.h | 3 +++
5 files changed, 42 insertions(+), 3 deletions(-)
create mode 100644 Help/prop_tgt/XCTEST.rst
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/prop_tgt/XCTEST.rst b/Help/prop_tgt/XCTEST.rst
new file mode 100644
index 000..f3ff474
--- /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:`FindXCTest` 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/Source/cmGlobalXCodeGenerator.cxx
b/Source/cmGlobalXCodeGenerator.cxx
index bd8a1f5..d340e72 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -804,6 +804,10 @@ GetSourcecodeValueFromFileExtension(const std::string
_ext,
{
sourcecode = compiled.mach-o.objfile;
}
+ else if(ext == xctest)
+{
+sourcecode = wrapper.cfbundle;
+}
else if(ext == xib)
{
keepLastKnownFileType = true;
@@ -2598,7 +2602,9 @@ const char*
cmGlobalXCodeGenerator::GetTargetFileType(cmTarget cmtarget)
case cmTarget::STATIC_LIBRARY:
return archive.ar;
case cmTarget::MODULE_LIBRARY:
- if (cmtarget.IsCFBundleOnApple())
+ if (cmtarget.IsXCTestOnApple())
+return wrapper.cfbundle;
+ else if (cmtarget.IsCFBundleOnApple())
return wrapper.plug-in;
else
return ((this-XcodeVersion = 22)?
@@ -2622,7 +2628,9 @@ const char*
cmGlobalXCodeGenerator::GetTargetProductType(cmTarget cmtarget)
case cmTarget::STATIC_LIBRARY:
return com.apple.product-type.library.static;
case cmTarget::MODULE_LIBRARY:
- if (cmtarget.IsCFBundleOnApple())
+ if (cmtarget.IsXCTestOnApple())
+return com.apple.product-type.bundle.unit-test;
+ else if (cmtarget.IsCFBundleOnApple())
return com.apple.product-type.bundle;
else
return ((this-XcodeVersion = 22)?
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index b70f60d..b3d1155 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -616,6 +616,13 @@ bool cmTarget::IsCFBundleOnApple() const
}
//
+bool cmTarget::IsXCTestOnApple() const
+{
+ return (this-IsCFBundleOnApple()
+ this-GetPropertyAsBool(XCTEST));
+}
+
+//
bool cmTarget::IsBundleOnApple() const
{
return this-IsFrameworkOnApple() || this-IsAppBundleOnApple() ||
@@ -6791,7 +6798,14 @@ std::string cmTarget::GetCFBundleDirectory(const
std::string config,
const char *ext = this-GetProperty(BUNDLE_EXTENSION);
if (!ext)
{
-ext = bundle;
+if (this-IsXCTestOnApple())
+ {
+ ext = xctest;
+ }
+else
+ {
+ ext = bundle;
+ }
}
fpath += ext;
fpath += /Contents;
diff --git a/Source/cmTarget.h b/Source/cmTarget.h
index 5170b31..a4ef977 100644
--- a/Source/cmTarget.h
+++ b/Source/cmTarget.h
@@ -527,6 +527,9 @@ public:
/** Return whether this target is a CFBundle (plugin) on Apple. */
bool IsCFBundleOnApple() const;
+ /** Return whether this target is a XCTest on Apple. */
+ bool IsXCTestOnApple() const;
+
/** Return whether this target is an executable Bundle on Apple. */
bool IsAppBundleOnApple() const;
--
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
[cmake-developers] [PATCH v8 5/5] Help: Add notes for topic 'xcode-xctest'
From: Brad King brad.k...@kitware.com --- Help/release/dev/xcode-xctest.rst | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 Help/release/dev/xcode-xctest.rst diff --git a/Help/release/dev/xcode-xctest.rst b/Help/release/dev/xcode-xctest.rst new file mode 100644 index 000..7a2f07b --- /dev/null +++ b/Help/release/dev/xcode-xctest.rst @@ -0,0 +1,6 @@ +xcode-xctest + + +* On OS X, CMake learned to create XCTest bundles to test Frameworks + and App Bundles within Xcode. The :module:`FindXCTest` module + provides convenience functions to handle :prop_tgt:`XCTEST` bundles. -- 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] [PATCH v8 1/5] Tests: Compute Xcode version for any generator on OS X
From: Brad King brad.k...@kitware.com
Store the version in CMake_TEST_XCODE_VERSION for use by tests that work
with any generator on OS X but may depend on the Xcode version providing
the tools.
---
Tests/CMakeLists.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 703c548..bcb1590 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -172,6 +172,7 @@ if(BUILD_TESTING)
ON)
mark_as_advanced(CTEST_TEST_CPACK)
set(CTEST_TEST_OSX_ARCH 0)
+ set(CMake_TEST_XCODE_VERSION 0)
if(APPLE)
execute_process(
COMMAND sw_vers -productVersion
@@ -185,6 +186,17 @@ if(BUILD_TESTING)
else()
set(CTEST_TEST_OSX_ARCH 1)
endif()
+if(XCODE_VERSION)
+ set(CMake_TEST_XCODE_VERSION ${XCODE_VERSION})
+else()
+ execute_process(
+COMMAND xcodebuild -version
+OUTPUT_VARIABLE _version ERROR_VARIABLE _version
+)
+ if(_version MATCHES ^Xcode ([0-9]+(\\.[0-9]+)*))
+set(CMake_TEST_XCODE_VERSION ${CMAKE_MATCH_1})
+ endif()
+endif()
endif()
# Use 1500 or CTEST_TEST_TIMEOUT for long test timeout value,
--
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] Extracting target metadata, IDE integration
On Saturday, March 14, 2015 09:40:41 Peter Kümmel wrote: On 12.03.2015 16:24, Tobias Hunger wrote: A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not possibly know when a cpp file needs rebuilding. It would not be as successful a build system when it did not know that:-) Even cmake does not know all headers need for compilation, this is done by the compiler providing the dependency files. the cmake dependency scanning does find all (and potentially some more) used headers, see depend.internal in the CMakeFiles/ tree. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] List all binaries associated with a target.
Here's an example function which addresses 1.
It creates a string of generator expressions for direct and indirect
dependencies of a target recursively.
When all recursive invocations are done, it spits target-name-deps
file in the CURRENT_BINARY_DIR which contains full paths of the
dependencies:
function(store_dependencies LIB)
if(NOT TARGET ${LIB})
message(FATAL_ERROR You have to pass valid target)
endif()
# Do not add location for the top-most invocation
if (ARGV1)
set(ORIGINAL_LIB ${ARGV1})
set_property(TARGET ${ORIGINAL_LIB} APPEND_STRING PROPERTY
DEPENDENCY_LIST $TARGET_FILE:${LIB} )
else()
set(ORIGINAL_LIB ${LIB})
endif()
# init dependency list with direct dependencies
get_property(DEPENDENCIES TARGET ${LIB} PROPERTY LINK_LIBRARIES)
# We're not intersted in interface link libraries of the top-most target
if (ARGV1)
get_property(INTERFACE_LINK_LIBRARIES TARGET ${LIB} PROPERTY
INTERFACE_LINK_LIBRARIES)
list(APPEND DEPENDENCIES ${INTERFACE_LINK_LIBRARIES})
endif()
if (DEPENDENCIES)
list(REMOVE_DUPLICATES DEPENDENCIES)
# message (STATUS ${LIB} dependens on ${DEPENDENCIES})
endif()
foreach(DEPENDENCY ${DEPENDENCIES})
store_dependencies(${DEPENDENCY} ${ORIGINAL_LIB})
endforeach()
# Store list of gathered dependencies for the top-most call only
if (NOT ARGV1)
get_property(DEPENDENCY_LIST TARGET d PROPERTY DEPENDENCY_LIST)
file(GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${LIB}-deps
CONTENT ${DEPENDENCY_LIST})
endif()
endfunction()
I'm not sure how to achieve 2. during CMake configuration phase though
as all generator expression are expanded later during build generation
phase. But you might copy the files during build phase. You can create
custom commands which use content of the generated file.
I don't get what exactly you're trying to achieve in 3. In general I
wouldn't encourage to copy binaries during build phase unless you have
a very solid reason. FWIW there's install(TARGET) command for
installation and packaging.
Roman
2015-03-14 4:24 GMT+03:00 Klaim - Joël Lamotte mjkl...@gmail.com:
I am looking for a (hopefully simple) way to do the following:
1. gather a list of paths of all the binaries associated with a target,
that is all the linked dll/so and executable the target link or depend
on.
2. copy these somewhere else.
3. take into account the build modes so that the right binaries are copied
for
each of the target build mode.
I can't find a way to do 1 so far without manually specifying the
dependencies.
It looks like the generators expressions can't gather these info.
So is there a way to retrieve this list in current CMake features?
Did I miss something?
Thanks for your time.
--
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
--
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
[cmake-developers] [PATCH v8 0/5] Add XCTest Bundle Support
Hello, this is the eighth version of the XCTest patch. Besides the changes mentioned below I added some more input validation for the two xctest functions. On 27/02/15 16:26, Brad King wrote: The XCTestUtilities module is feeling more like a find module now that it finds XCTest components. Perhaps we should rename it to FindXCTest and use find_package(XCTest) to use it. I changed it into a Find module and it looks much more polished now. Is this kind of modification of the testee safe? Will projects actually want their targets modified by adding tests for them? Currently the settings will affect how the tested targets are installed. I fully agree that modifying the testee is not something one would expect when adding a test for it. Therefore I reverted the rpath setting for Frameworks and replaced it with a DYLD environment variable when calling xctest. For the App Bundle I reverted your ENABLE_EXPORTS call and replaced it with Xcode specific settings for the XCODE generator and a linker flag for the Makefile generator. Once you ACK the series I will create a topic branch and follow the developer instructions. Thanks, Gregor Brad King (2): Tests: Compute Xcode version for any generator on OS X Help: Add notes for topic 'xcode-xctest' Gregor Jasny (3): OS X: Add handling for XCTest bundles OS X: Add FindXCTest module Tests: 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/FindXCTest.rst | 1 + Help/prop_tgt/XCTEST.rst | 13 + Help/release/dev/xcode-xctest.rst | 6 + Modules/FindXCTest.cmake | 196 ++ Source/cmGlobalXCodeGenerator.cxx | 12 +- Source/cmTarget.cxx| 16 +- Source/cmTarget.h | 3 + Tests/CMakeLists.txt | 16 + Tests/XCTest/CMakeLists.txt| 57 ++ Tests/XCTest/CocoaExample/AppDelegate.h| 6 + 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, 1146 insertions(+), 3 deletions(-) create mode 100644 Help/module/FindXCTest.rst create mode 100644 Help/prop_tgt/XCTEST.rst create mode 100644 Help/release/dev/xcode-xctest.rst create mode 100644 Modules/FindXCTest.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
[cmake-developers] [PATCH] Fix documentation for FindPackageHandleStandardArgs
For mode 2 the first argument is not the literal NAME but the package name. Signed-off-by: Gregor Jasny gja...@googlemail.com --- Modules/FindPackageHandleStandardArgs.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/FindPackageHandleStandardArgs.cmake b/Modules/FindPackageHandleStandardArgs.cmake index 2de1fb3..bcbd17d 100644 --- a/Modules/FindPackageHandleStandardArgs.cmake +++ b/Modules/FindPackageHandleStandardArgs.cmake @@ -33,7 +33,7 @@ # # :: # -# FIND_PACKAGE_HANDLE_STANDARD_ARGS(NAME +# FIND_PACKAGE_HANDLE_STANDARD_ARGS(NAME # [FOUND_VAR resultVar] # [REQUIRED_VARS var1...varN] # [VERSION_VAR versionvar] -- 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] Generating buildsystem metadata from CMake
On Saturday, March 14, 2015, Aleix Pol aleix...@kde.org wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com
wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.
The aim is to generate a structured file containing metadata relating the
buildsystem.
To help with completing the design of this feature, I've written
documentation (documentation driven design), and a unit test
containing a CMakeLists.txt file which exercises many modern CMake
features in the generate-metadata branch in my clone.
Mostly the design I propose can be read in the documentation I wrote. I'm
interested in any feedback.
https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt
http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html
I expect to require a few iterations to figure out what the metadata
files
should contain in the end. Note that there are already some differences
between my design and Aleix's implementation, such as that my design
proposes one metadata file per config. There are also some things
missing like location, because it is not yet clear to me whether build
or install locations are needed etc.
The content of the metadata file is determined by the build properties,
and
is necessarily similar to the compile-related content created when
generating the actual buildsystem. It additionally contains information
about the output locations of build artifacts and information relating to
the cmake description itself.
Goals include:
* Make it possible for IDEs to access the compile-related information for
autocompletion and code navigation etc purposes.
* Remove the need for IDEs to parse generated Makefiles or Ninja files to
access compile-related information. The structure of those files is
not
'stable', while the content of the metadata file is stable.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081
* Remove the need for users to create a new build directory and new build
in order to use or switch IDEs. QtCreator requires that
the C::B 'extra generator is used as it parses compile information from
that. Other 'extra generators' such as for eclipse, sublime, kate etc
also require fresh/new build directories, although the actual
buildsystem
they create is identical (assuming using all Makefile based or
all Ninja based 'extra generators')
* Make it possible to write a plugin for the editors/IDEs such as sublime
which consumes the metadata file and invokes the build using whatever
buildsystem the user already has a build directory for, instead of
writing an 'extra generator' and maintaining it in the cmake repo.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004
* Make it possible for editors/IDEs to allow specifying the configuration
at build-time, where the IDE has that feature, and where a multi-config
generator is available. That is, QtCreator provides user-interface for
choosing debug/release config to build. Currently it can't offer that
when using cmake, because it only allows the use of Makefile or Ninja
generators, in order to make use of the C::B file. QtCreator should be
able to use the Xcode or Visual Studio generators, generate the
metadata
file(s), and invoke `cmake --build . --config ${CONFIG}` as
appropriate. Eclipse, Sublime and other editors have similar abilities
to invoke config-specific builds after generation.
* Provide a list of 'build targets', which can be listed and invoked in
IDE/editor user interface. Build targets for all linked binaries
and utilties are provided. The tooling is expected to perform
filtering
on the target types to show only executables and utilities for
execution, for example.
* Provide a list of source files per target per type of source file, eg
object sources, header files, generated files, files excluded from the
active configuration/platform/compiler, non-compiled files.
* Make it more easy for an IDE to support actions such as 'remove file
from the project', which requires removing it from the CMakeLists.txt
at the appropriate place, and 'add new file/class to target', which
involves adding code to the CMakeLists.txt file at the appropriate
place. Most likely the easiest way to do the latter is using the
target_sources() command, and to support the former, the location of
the declaration of the target, and all target_sources() calls would
need to be recorded. Even that is
Re: [cmake-developers] Extracting target metadata, IDE integration
On 12.03.2015 16:24, Tobias Hunger wrote: A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not possibly know when a cpp file needs rebuilding. It would not be as successful a build system when it did not know that:-) Even cmake does not know all headers need for compilation, this is done by the compiler providing the dependency files. Overall, wouldn't it be better cmake could parse something like a QBS syntax? Or is also QBS's description not complete enough for an IDE? Is it good enough for QtCreator? I don't think extending CMake's language until eternity is a good idea, the way should go away from it to a common scripting language, so that generating meta-files becomes superfluous. Also we don't really have information about where to put them. You can use the minimum common denominator among the sources I guess. I don't understand that part, sorry. } ], installed : true, I guess this means make install will install it. Where will this file end up? Yes. I tried to figure it out but didn't manage to find the correct way to query it. I can try harder. :D name : LLVMPowerPCInfo, output_directory : /home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo, For what is the output directory relevant? The output above does implicitly list that already, doesn't it? It's important in case the output path is overriden, see last e-mail by Alexander Neundorf. type : STATIC_LIBRARY Which types are possible here? It's an enum internal to cmake. At the moment: EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY, UNKNOWN_LIBRARY. }, There is a lot of useful information here! Thanks for pushing into this direction. I am sure this will help a lot. Ideally this file would be enough to provide all information we need as an IDE to: * Present the project structure as seen by the build system. * Generate the code model * Build the project * Deploy the project * Run and debug parts of the project * Adding and removing files to a project For the project structure this does help: It provides us with a list of all the build targets, which is already nice. CMake does support more structure with Projects and subprojects IIRC and that information is lost. Would it be much work to get that information back? as discussed above, I'll look into that next thing. I am a cmake noob, but maybe I can help? For the code model this is not much help at all: There is no information on compiler used, include directories nor Defines or compiler flags. Where am I supposed to get that information from? Do I need to generate and parse the list of commands run and extract that information from there? Having that information available right in the sources array of each target would be so much more convenient and would also make IDE integration so much easier: You would need to know about one file only and won't need to figure out several. We can do that, I mentioned earlier in this thread that currently we're using compile_commands.json for that ( CMAKE_EXPORT_COMPILE_COMMANDS). I agree it could be interesting to add it. In other words, if nobody disagrees, I'll add it although I see how this will make the output grow a lot. I found parsing of compiler commands non-trivial: It gets messy when some file gets built twice, especially when different defines, etc. are set at the different times. E.g. once it is built with -DENABLE_TEST by some unit test and once it is built without any flags by the normal application. Best Regards, Tobias -- 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] Check whether C++ headers are self-sufficient
Why do you want to use one library per header? I think, it would be sufficient to have one cc-file per header and one library per folder. The library would simply contain all files. Why do you worry about large build directories? Regards, Andreas Am 14.03.2015 um 13:19 schrieb Christoph Grüninger: Dear CMakers, I want to have all my C++ headers self-sufficient (self-contained), i.e., a header can be included without additional includes. This is not only handy but also part of Google's C++ styleguide [2]. It would be great to have a make target (let's call it headercheck), that can check for this, by compiling a simple test.cc file for each current_header.h: #include config.h #include current_header.h #include current_header.h Additionally it would be great to have such a target for every folder (checking all headers recursively) and every header that is explicitly passed as an argument. We tried this with CMake: We generate a test.cc file per header and create a library for every cc file. The problem is, that we get hundreds of additional targets, we generate a lot of folders and files which can increase our build directory size by an order of magnitude and it does not work properly on a per file or per directory basis. What do you think, is there a good way to have such a target headercheck with CMake? Or would it be better to include it as a CTest? Or better as an external (bash) script as proposed in [1]? If it can be done in a good way with CMake, would it be of interest to include it as a feature in CMake? Or as an external project similar to UseLATEX.cmake? Bye Christoph [1] http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers -- 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
[CMake] Check whether C++ headers are self-sufficient
Dear CMakers, I want to have all my C++ headers self-sufficient (self-contained), i.e., a header can be included without additional includes. This is not only handy but also part of Google's C++ styleguide [2]. It would be great to have a make target (let's call it headercheck), that can check for this, by compiling a simple test.cc file for each current_header.h: #include config.h #include current_header.h #include current_header.h Additionally it would be great to have such a target for every folder (checking all headers recursively) and every header that is explicitly passed as an argument. We tried this with CMake: We generate a test.cc file per header and create a library for every cc file. The problem is, that we get hundreds of additional targets, we generate a lot of folders and files which can increase our build directory size by an order of magnitude and it does not work properly on a per file or per directory basis. What do you think, is there a good way to have such a target headercheck with CMake? Or would it be better to include it as a CTest? Or better as an external (bash) script as proposed in [1]? If it can be done in a good way with CMake, would it be of interest to include it as a feature in CMake? Or as an external project similar to UseLATEX.cmake? Bye Christoph [1] http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers -- When you die, that does not mean that you lose to cancer, you beat cancer by how you live, why you live, and in the manner in which you live. -- Stuart Scott, 1965-2015 -- 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
Re: [CMake] Check whether C++ headers are self-sufficient
I have worked on projects where we do something fairly similar. The
significant difference is that we create only a single executable per
directory. All told is it a fairly simple and looks something like:
# Builds a source file and an executable that does nothing other than
# compile the given header files.
function(add_header_test name)
set(hfiles ${ARGN})
set(suffix .cpp)
set(cxxfiles)
foreach (header ${ARGN})
string(REPLACE ${CMAKE_CURRENT_BINARY_DIR} header ${header})
get_filename_component(headername ${header} NAME_WE)
set(src
${CMAKE_CURRENT_BINARY_DIR}/TestBuild_${name}_${headername}${suffix})
configure_file(${SMTK_SOURCE_DIR}/CMake/TestBuild.cxx.in ${src} @ONLY)
set(cxxfiles ${cxxfiles} ${src})
endforeach (header)
add_library(TestBuild_${name} ${cxxfiles} ${hfiles})
target_include_directories(TestBuild_${name} ${CMAKE_CURRENT_BINARY_DIR})
set_source_files_properties(${hfiles} PROPERTIES HEADER_FILE_ONLY TRUE)
endfunction(add_header_test)
On Sat, Mar 14, 2015 at 8:19 AM, Christoph Grüninger f...@grueninger.de
wrote:
Dear CMakers,
I want to have all my C++ headers self-sufficient (self-contained),
i.e., a header can be included without additional includes. This is not
only handy but also part of Google's C++ styleguide [2].
It would be great to have a make target (let's call it headercheck),
that can check for this, by compiling a simple test.cc file for each
current_header.h:
#include config.h
#include current_header.h
#include current_header.h
Additionally it would be great to have such a target for every folder
(checking all headers recursively) and every header that is explicitly
passed as an argument.
We tried this with CMake: We generate a test.cc file per header and
create a library for every cc file. The problem is, that we get hundreds
of additional targets, we generate a lot of folders and files which can
increase our build directory size by an order of magnitude and it does
not work properly on a per file or per directory basis.
What do you think, is there a good way to have such a target headercheck
with CMake? Or would it be better to include it as a CTest? Or better as
an external (bash) script as proposed in [1]?
If it can be done in a good way with CMake, would it be of interest to
include it as a feature in CMake? Or as an external project similar to
UseLATEX.cmake?
Bye
Christoph
[1]
http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c
[2]
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers
--
When you die, that does not mean that you lose to cancer,
you beat cancer by how you live, why you live, and in the
manner in which you live. -- Stuart Scott, 1965-2015
--
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
--
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
Re: [cmake-developers] Generating buildsystem metadata from CMake
On Sat, Mar 14, 2015 at 10:02 AM, Stephen Kelly steve...@gmail.com wrote:
On Saturday, March 14, 2015, Aleix Pol aleix...@kde.org wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com
wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.
The aim is to generate a structured file containing metadata relating the
buildsystem.
To help with completing the design of this feature, I've written
documentation (documentation driven design), and a unit test
containing a CMakeLists.txt file which exercises many modern CMake
features in the generate-metadata branch in my clone.
Mostly the design I propose can be read in the documentation I wrote. I'm
interested in any feedback.
https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt
http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html
I expect to require a few iterations to figure out what the metadata
files
should contain in the end. Note that there are already some differences
between my design and Aleix's implementation, such as that my design
proposes one metadata file per config. There are also some things
missing like location, because it is not yet clear to me whether build
or install locations are needed etc.
The content of the metadata file is determined by the build properties,
and
is necessarily similar to the compile-related content created when
generating the actual buildsystem. It additionally contains information
about the output locations of build artifacts and information relating to
the cmake description itself.
Goals include:
* Make it possible for IDEs to access the compile-related information for
autocompletion and code navigation etc purposes.
* Remove the need for IDEs to parse generated Makefiles or Ninja files to
access compile-related information. The structure of those files is
not
'stable', while the content of the metadata file is stable.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081
* Remove the need for users to create a new build directory and new build
in order to use or switch IDEs. QtCreator requires that
the C::B 'extra generator is used as it parses compile information from
that. Other 'extra generators' such as for eclipse, sublime, kate etc
also require fresh/new build directories, although the actual
buildsystem
they create is identical (assuming using all Makefile based or
all Ninja based 'extra generators')
* Make it possible to write a plugin for the editors/IDEs such as sublime
which consumes the metadata file and invokes the build using whatever
buildsystem the user already has a build directory for, instead of
writing an 'extra generator' and maintaining it in the cmake repo.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004
* Make it possible for editors/IDEs to allow specifying the configuration
at build-time, where the IDE has that feature, and where a multi-config
generator is available. That is, QtCreator provides user-interface for
choosing debug/release config to build. Currently it can't offer that
when using cmake, because it only allows the use of Makefile or Ninja
generators, in order to make use of the C::B file. QtCreator should be
able to use the Xcode or Visual Studio generators, generate the
metadata
file(s), and invoke `cmake --build . --config ${CONFIG}` as
appropriate. Eclipse, Sublime and other editors have similar abilities
to invoke config-specific builds after generation.
* Provide a list of 'build targets', which can be listed and invoked in
IDE/editor user interface. Build targets for all linked binaries
and utilties are provided. The tooling is expected to perform
filtering
on the target types to show only executables and utilities for
execution, for example.
* Provide a list of source files per target per type of source file, eg
object sources, header files, generated files, files excluded from the
active configuration/platform/compiler, non-compiled files.
* Make it more easy for an IDE to support actions such as 'remove file
from the project', which requires removing it from the CMakeLists.txt
at the appropriate place, and 'add new file/class to target', which
involves adding code to the CMakeLists.txt file at the appropriate
place. Most likely the easiest way to do the latter is using the
target_sources() command, and to support the former, the location of
the declaration
Re: [CMake] ARGV processing in cmake -P
Works for me with CMake 3.2.1 on Windows. What version of CMake are you using?
C:\dev\dcole type args.cmake
foreach(n RANGE ${ARGC})
message(STATUS ${n} ${CMAKE_ARGV${n}})
endforeach()
message(STATUS ${CMAKE_ARGV0})
message(STATUS ${CMAKE_ARGV1})
message(STATUS ${CMAKE_ARGV2})
C:\dev\dcole cmake -P args.cmake
-- 0 cmake
-- cmake
-- -P
-- args.cmake
C:\dev\dcole cmake --version
cmake version 3.2.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
On Fri, Mar 13, 2015 at 7:50 PM, Bill Newcomb bnewc...@nvidia.com wrote:
Any idea what I'm doing wrong here?
$ cat foo.cmake
foreach(n RANGE ${ARGC})
message(STATUS ${n} ${CMAKE_ARGV${n}})
endforeach()
message(STATUS ${CMAKE_ARGV0})
message(STATUS ${CMAKE_ARGV1})
message(STATUS ${CMAKE_ARGV2})
$ cmake -P foo.cmake a b c
-- 0
--
--
--
$ cmake a b c -P foo.cmake
-- 0
--
--
--
Thanks,
B.
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
--
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
--
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
