Re: [cmake-developers] Introduction and volunteering for the Matlab package

2015-02-26 Thread Raffi Enficiaud
Quick question:
Is it possible to redirect the input stream of execute_process from /dev/null 
on OSX and Linux ?
Right now on these platforms, I need to reset my shell. If I run the ctest 
command with  /dev/null, everything is fine. So my guess is that Matlab is 
manipulating the console somehow.

Thanks,
Raffi

 On 26 Feb 2015, at 18:02, Raffi Enficiaud raffi.enfici...@free.fr wrote:
 
 Hi Brad,
 
 Please find the patch addressing the issues you raised. My local tests are 
 clear on the 3 platforms.
 I removed the RunCMake test on Linux as now the Matlab_MAIN_PROGRAM is 
 required if MATLAB_USER_ROOT is not specified. In the previous 
 implementation, I used temporary variables to avoid bringing this program to 
 the user.
 
 Any feedback welcome,
 
 Best,
 Raffi
 
 0001-Simplified-workflow.patch
 On 25 Feb 2015, at 14:32, Brad King brad.k...@kitware.com wrote:
 
 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

-- 

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] Introduction and volunteering for the Matlab package

2015-02-26 Thread Raffi Enficiaud
Hi Brad,

Please find the patch addressing the issues you raised. My local tests are 
clear on the 3 platforms.
I removed the RunCMake test on Linux as now the Matlab_MAIN_PROGRAM is required 
if MATLAB_USER_ROOT is not specified. In the previous implementation, I used 
temporary variables to avoid bringing this program to the user.

Any feedback welcome,

Best,
Raffi



0001-Simplified-workflow.patch
Description: Binary data

 On 25 Feb 2015, at 14:32, Brad King brad.k...@kitware.com wrote:
 
 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] [PATCH] Pass CMAKE_VERBOSE_MAKEFILE value to Ninja Generator

2015-02-26 Thread Brad King
On 02/26/2015 05:32 AM, 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.

Applied and test case added:

 cmake: Teach --build to honor CMAKE_VERBOSE_MAKEFILE for Ninja
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ce935ebe

 Tests: Extend RunCMake.CommandLine to cover 'cmake --build' for 'ninja -v'
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1082448

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] [PATCH v6 0/2] Add XCTest Bundle Support

2015-02-26 Thread Brad King
On 02/25/2015 03:07 PM, Gregor Jasny wrote:
 Changes since v5:
 * Rebased against master (could drop two applied patches)
 * kept help modules list sorted
 * indirected xctest wiring

Great.  The tests pass on my machine with no special configuration.

The basic functionality is in good shape.  My remaining comments
are on the XCTestUtilities module that I hadn't fully reviewed
before:

* Please split addition of XCTestUtilities into its own commit
  between the current two with its own commit message.

* Please use the .. command:: ... explicit markup to document
  the module API.  That will make the functions indexed and
  linkable from other documentation.  See the ExternalData
  module documentation for an example.

* Please rename the APIs to start in xctest_, e.g.
  add_xctest = xctest_add.  We like to keep module-provided
  APIs prefixed with something related to the module name.

   if(NOT CMAKE_OSX_SYSROOT)
 message(STATUS Adding XCTest bundles requires CMAKE_OSX_SYSROOT to be 
 set.)
   endif()

Should this be a FATAL_ERROR?

   get_target_property(TESTEE_TYPE ${testee} TYPE)
   get_target_property(TESTEE_FRAMEWORK ${testee} FRAMEWORK)
   get_target_property(TESTEE_MACOSX_BUNDLE ${testee} MACOSX_BUNDLE)

Please use get_property(... TARGET ${testee} ...) instead.  We
may one day deprecate the get_*_property commands because they
are so inconsistent in how they report undefined properties.

   find_library(FOUNDATION_LIBRARY Foundation)
   if(NOT FOUNDATION_LIBRARY)
 message(STATUS Could not find Foundation Framework.)
   endif()
 
   find_library(XCTEST_LIBRARY XCTest)
   if(NOT XCTEST_LIBRARY)
 message(STATUS Could not find XCTest Framework.)
   endif()

Rather than polluting the cache with these, we could just trust
that they exist.  Is there any reason not to do:

  target_link_libraries(${target} PRIVATE
-framework Foundation -framework XCTest)

instead?  Let Xcode find its own frameworks.

Alternatively these should be something that the XCTestUtilities
module finds as part of include()ing it instead of calling
find_library again on every invocation of the API.

   execute_process(
 COMMAND xcrun --find xctest
 OUTPUT_VARIABLE XCTEST_EXECUTABLE
 OUTPUT_STRIP_TRAILING_WHITESPACE)

Use ERROR_VARIABLE here with a bogus local variable name just
to hide any stderr output from the user running CMake.  As
above one could pre-find this outside of any API call.

   if(NOT XCTEST_EXECUTABLE)
 message(STATUS Unable to finc xctest binary.)
   endif()

If you go with the pre-find approach then this can still be
in the function because we only need the value there.  However,
shouldn't this be an error too?

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


[cmake-developers] [CMake 0015421]: FindOpenMP always re-run

2015-02-26 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15421 
== 
Reported By:Mathieu Malaterre
Assigned To:
== 
Project:CMake
Issue ID:   15421
Category:   (No Category)
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-02-26 09:07 EST
Last Modified:  2015-02-26 09:07 EST
== 
Summary:FindOpenMP always re-run
Description: 
On MacOSX mavericks, the default clang compiler does not support OpenMP.

It would be nice in this case to not re-run the openmp system inspection
everytime.

Ref:
[...]
Michaels-MacBook-Pro-2:bin-macosx dev$ make
-- Try OpenMP C flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Could NOT find OpenMP (missing:  OpenMP_C_FLAGS OpenMP_CXX_FLAGS) 
[...]
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-02-26 09:07 Mathieu MalaterreNew 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 0015422]: cmake --help should be explicit about how to specify architecture.

2015-02-26 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15422 
== 
Reported By:Stephen Kelly
Assigned To:
== 
Project:CMake
Issue ID:   15422
Category:   CMake
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-02-26 20:29 CET
Last Modified:  2015-02-26 20:29 CET
== 
Summary:cmake --help should be explicit about how to specify
architecture.
Description: 

In previous releases, it was necessary to specify Win64 in the generator name to
do a 64 bit build. This is not mentioned in the output of cmake --help. 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51673

Now there is also a -A option. The help output should be explicit about whatever
the user should use.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-02-26 20:29 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] cmake install command expected performance?

2015-02-26 Thread Brad King
On 02/26/2015 02:18 PM, Robert Goulet wrote:
 turns out to be 5000+ file open/close

Good catch!  It looks like it's been that way since manifest generation
was first added here:

 ENH: When installing project, write manifest
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99feab35

I've applied your patch with a few tweaks to avoid a leading
newline and improve code formatting:

 install: Write the entire installation manifest at once
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4814174

 Please consider it for CMake 3.2!

Normally we don't take non-regression, non-new-feature-bugfix changes
during a release candidate cycle.  Given your antivirus config one
could consider this an environmental regression.  I'll consider it
if it tests cleanly.

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] Introduction and volunteering for the Matlab package

2015-02-26 Thread Raffi Enficiaud
Thanks! here is the patch then, replacing the previous one, rebased on 
1416d214b3.

Best,
Raffi



0001-Simplified-workflow.patch
Description: Binary data

 On 26 Feb 2015, at 18:52, Brad King brad.k...@kitware.com wrote:
 
 On 02/26/2015 12:06 PM, Raffi Enficiaud wrote:
 Is it possible to redirect the input stream of execute_process
 from /dev/null on OSX and Linux ?
 
 Yes:
 
  INPUT_FILE /dev/null
 
 and on Windows:
 
  INPUT_FILE NUL
 
 -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] cmake install command expected performance?

2015-02-26 Thread Robert Goulet
Great, let us know if the test is clean! Cheers!

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Thursday, February 26, 2015 3:13 PM
To: Robert Goulet; Joshua Clayton
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] cmake install command expected performance?

On 02/26/2015 02:18 PM, Robert Goulet wrote:
 turns out to be 5000+ file open/close

Good catch!  It looks like it's been that way since manifest generation was 
first added here:

 ENH: When installing project, write manifest
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99feab35

I've applied your patch with a few tweaks to avoid a leading newline and 
improve code formatting:

 install: Write the entire installation manifest at once
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4814174

 Please consider it for CMake 3.2!

Normally we don't take non-regression, non-new-feature-bugfix changes during a 
release candidate cycle.  Given your antivirus config one could consider this 
an environmental regression.  I'll consider it if it tests cleanly.

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] cmake install command expected performance?

2015-02-26 Thread Robert Goulet
Here is what we discovered. It looks like that when cmake write the install 
manifest file, it does it in a for_loop for each file, which in the end turns 
out to be 5000+ file open/close, and then our administrator controlled 
anti-virus checks the file each time, considerably slowing everything down.

We just changed the logic to write the install manifest file in a single file 
open/close rather than for each file, and it completely fixes our issue; it's 
now back to normal install times, now takes less than a second compared to 50+ 
seconds previously.

Patch file attached.
Please consider it for CMake 3.2!
Thanks!


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Tuesday, February 24, 2015 10:07 AM
To: Robert Goulet; Joshua Clayton
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] cmake install command expected performance?

On 02/24/2015 10:03 AM, Robert Goulet wrote:
 Yes comparing timestamp is the way to go, but why is it so slow in cmake?

I've never observed that being slow in practice.

You'll have to profile CMake while running in this case, or add some print 
statements with high-precision timestamps to see where the time is going.

-Brad



patch_install_manifest_optimize.patch
Description: patch_install_manifest_optimize.patch
-- 

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 v7 2/4] Add XCTest Utilities

2015-02-26 Thread Gregor Jasny
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
 Help/manual/cmake-modules.7.rst |   1 +
 Help/module/XCTestUtilities.rst |   1 +
 Modules/XCTestUtilities.cmake   | 139 
 3 files changed, 141 insertions(+)
 create mode 100644 Help/module/XCTestUtilities.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/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/Modules/XCTestUtilities.cmake b/Modules/XCTestUtilities.cmake
new file mode 100644
index 000..fe38629
--- /dev/null
+++ b/Modules/XCTestUtilities.cmake
@@ -0,0 +1,139 @@
+#[===[.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/
+
+Module Functions
+
+
+.. command:: xctest_add_bundle
+
+  The ``xctest_add_bundle`` function creates a XCTest bundle named
+  target which will test the target testee. Supported target types
+  for testee are Frameworks and App Bundles::
+
+xctest_add_bundle(
+  target  # Name of the XCTest bundle
+  testee  # Target name of the testee
+  )
+
+.. command:: xctest_add_test
+
+  The ``xctest_add_test`` function adds an XCTest bundle to the
+  project to be run by :manual:`ctest(1)`. The test will be named
+  name and tests bundle::
+
+xctest_add_test(
+  name# Test name
+  bundle  # Target name of XCTest bundle
+  )
+
+Module Variables
+
+
+The following variables are set by including this module:
+
+.. variable:: XCTEST_EXECUTABLE
+
+  The ``XCTEST_EXECUTABLE`` variable contains the path to the xctest
+  command line tool used to execute XCTest bundles.
+
+.. variable:: XCTEST_LIBRARY
+
+  The ``XCTEST_LIBRARY`` variable contains the location of the XCTest
+  Framework.
+
+#]===]
+
+#=
+# 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.)
+
+find_library(XCTEST_LIBRARY XCTest)
+mark_as_advanced(XCTEST_LIBRARY)
+
+execute_process(
+  COMMAND xcrun --find xctest
+  OUTPUT_VARIABLE _xcrun_out OUTPUT_STRIP_TRAILING_WHITESPACE
+  ERROR_VARIABLE _xcrun_err)
+if(_xcrun_out)
+  set(XCTEST_EXECUTABLE ${_xcrun_out} CACHE FILEPATH xctest executable)
+  mark_as_advanced(XCTEST_EXECUTABLE)
+endif()
+
+function(xctest_add_bundle target testee)
+  if(NOT CMAKE_OSX_SYSROOT)
+message(FATAL_ERROR Adding XCTest bundles requires CMAKE_OSX_SYSROOT to 
be set.)
+  endif()
+
+  # check that testee is a valid target type
+  get_property(TESTEE_TYPE TARGET ${testee} PROPERTY TYPE)
+  get_property(TESTEE_FRAMEWORK TARGET ${testee} PROPERTY FRAMEWORK)
+  get_property(TESTEE_MACOSX_BUNDLE TARGET ${testee} PROPERTY MACOSX_BUNDLE)
+
+  if(TESTEE_TYPE STREQUAL SHARED_LIBRARY AND TESTEE_FRAMEWORK)
+# found a framework
+  elseif(TESTEE_TYPE STREQUAL EXECUTABLE AND TESTEE_MACOSX_BUNDLE)
+# found an app bundle
+  else()
+   message(FATAL_ERROR Testee ${testee} is of unsupported type: 
${TESTEE_TYPE})
+  endif()
+
+  add_library(${target} MODULE ${ARGN})
+
+  set_target_properties(${target} PROPERTIES
+BUNDLE TRUE
+XCTEST TRUE)
+
+  target_link_libraries(${target} PRIVATE -framework Foundation)
+  target_link_libraries(${target} PRIVATE ${XCTEST_LIBRARY})
+
+  if(TESTEE_TYPE STREQUAL SHARED_LIBRARY AND TESTEE_FRAMEWORK)
+set_target_properties(${testee} PROPERTIES
+  BUILD_WITH_INSTALL_RPATH TRUE
+  INSTALL_NAME_DIR @rpath)
+
+target_link_libraries(${target} PRIVATE ${testee})
+  elseif(TESTEE_TYPE STREQUAL EXECUTABLE AND TESTEE_MACOSX_BUNDLE)
+add_dependencies(${target} ${testee})

[cmake-developers] [PATCH v7 3/4] Add XCTest example to test Frameworks and Cocoa App Bundles

2015-02-26 Thread Gregor Jasny
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
 Tests/CMakeLists.txt   |  13 +
 Tests/XCTest/CMakeLists.txt|  59 ++
 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, 900 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..f21ff59
--- /dev/null
+++ b/Tests/XCTest/CMakeLists.txt
@@ -0,0 +1,59 @@
+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
+
+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..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 (assign) IBOutlet NSWindow *window;
+@end
+
+@implementation AppDelegate
+
+- 

[cmake-developers] [PATCH v7 4/4] Also test XCTest on command line

2015-02-26 Thread Gregor Jasny
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
 Tests/CMakeLists.txt | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 6afedf2..a2e2e24 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -3066,15 +3066,26 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   endif()
 
   if(XCODE_VERSION AND NOT ${XCODE_VERSION} VERSION_LESS 5)
-add_test(XCTest ${CMAKE_CTEST_COMMAND}
+add_test(XCTest.Xcode ${CMAKE_CTEST_COMMAND}
   --build-and-test
   ${CMake_SOURCE_DIR}/Tests/XCTest
-  ${CMake_BINARY_DIR}/Tests/XCTest
+  ${CMake_BINARY_DIR}/Tests/XCTest.Xcode
   ${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)
+list(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/XCTest.Xcode)
+
+add_test(XCTest.Make ${CMAKE_CTEST_COMMAND}
+  --build-and-test
+  ${CMake_SOURCE_DIR}/Tests/XCTest
+  ${CMake_BINARY_DIR}/Tests/XCTest.Make
+  --build-generator Unix Makefiles
+  --build-project XCTest
+  --build-options ${build_options} -DCMAKE_OSX_SYSROOT=macosx
+  --test-command ${CMAKE_CTEST_COMMAND} -C \${CTEST_CONFIGURATION_TYPE} -V
+  )
+list(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/XCTest.Make)
   endif()
 endif()
-- 
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] [PATCH v6 0/2] Add XCTest Bundle Support

2015-02-26 Thread Gregor Jasny
Hello Brad,

thank you for the review. In addition to the last series I added a test
case also for the Makefile generator.

On 26/02/15 15:50, Brad King wrote:
 The basic functionality is in good shape.  My remaining comments
 are on the XCTestUtilities module that I hadn't fully reviewed
 before:
 
 * Please split addition of XCTestUtilities into its own commit
   between the current two with its own commit message.
 
 * Please use the .. command:: ... explicit markup to document
   the module API.  That will make the functions indexed and
   linkable from other documentation.  See the ExternalData
   module documentation for an example.
 
 * Please rename the APIs to start in xctest_, e.g.
   add_xctest = xctest_add.  We like to keep module-provided
   APIs prefixed with something related to the module name.
 
   if(NOT CMAKE_OSX_SYSROOT)
 message(STATUS Adding XCTest bundles requires CMAKE_OSX_SYSROOT to be 
 set.)
   endif()
 
 Should this be a FATAL_ERROR?
 
   get_target_property(TESTEE_TYPE ${testee} TYPE)
   get_target_property(TESTEE_FRAMEWORK ${testee} FRAMEWORK)
   get_target_property(TESTEE_MACOSX_BUNDLE ${testee} MACOSX_BUNDLE)
 
 Please use get_property(... TARGET ${testee} ...) instead.  We
 may one day deprecate the get_*_property commands because they
 are so inconsistent in how they report undefined properties.
 

Everything addressed.

   find_library(FOUNDATION_LIBRARY Foundation)
   if(NOT FOUNDATION_LIBRARY)
 message(STATUS Could not find Foundation Framework.)
   endif()

   find_library(XCTEST_LIBRARY XCTest)
   if(NOT XCTEST_LIBRARY)
 message(STATUS Could not find XCTest Framework.)
   endif()
 
 Rather than polluting the cache with these, we could just trust
 that they exist.  Is there any reason not to do:
 
   target_link_libraries(${target} PRIVATE
 -framework Foundation -framework XCTest)
 
 instead?  Let Xcode find its own frameworks.
 
 Alternatively these should be something that the XCTestUtilities
 module finds as part of include()ing it instead of calling
 find_library again on every invocation of the API.

This approach works properly for Xcode. But when building with the
Makefile Generator the XCTest framework is not in the default compiler
search path (but in CMAKE_SYSTEM_FRAMEWORK_PATH).

So I could use a if(XCODE) conditional to avoid looking up the XCTest
framework. But consistency across generators is also a nice thing.

   execute_process(
 COMMAND xcrun --find xctest
 OUTPUT_VARIABLE XCTEST_EXECUTABLE
 OUTPUT_STRIP_TRAILING_WHITESPACE)
 
 Use ERROR_VARIABLE here with a bogus local variable name just
 to hide any stderr output from the user running CMake.  As
 above one could pre-find this outside of any API call.
 
   if(NOT XCTEST_EXECUTABLE)
 message(STATUS Unable to finc xctest binary.)
   endif()
 
 If you go with the pre-find approach then this can still be
 in the function because we only need the value there.  However,
 shouldn't this be an error too?

Also everything addressed.

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] Pass CMAKE_VERBOSE_MAKEFILE value to Ninja Generator

2015-02-26 Thread Gregor Jasny
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/CPack/cmCPackGenerator.cxx   |  2 +-
 Source/CTest/cmCTestBuildAndTestHandler.cxx |  2 +-
 Source/cmGlobalGenerator.cxx| 11 ++-
 Source/cmGlobalGenerator.h  |  5 +++--
 Source/cmGlobalNinjaGenerator.cxx   |  6 ++
 Source/cmGlobalNinjaGenerator.h |  2 +-
 Source/cmGlobalUnixMakefileGenerator3.cxx   |  2 +-
 Source/cmGlobalUnixMakefileGenerator3.h |  2 +-
 Source/cmGlobalVisualStudio10Generator.cxx  |  4 ++--
 Source/cmGlobalVisualStudio10Generator.h|  2 +-
 Source/cmGlobalVisualStudio6Generator.cxx   |  2 +-
 Source/cmGlobalVisualStudio6Generator.h |  2 +-
 Source/cmGlobalVisualStudio7Generator.cxx   |  2 +-
 Source/cmGlobalVisualStudio7Generator.h |  2 +-
 Source/cmGlobalXCodeGenerator.cxx   |  2 +-
 Source/cmGlobalXCodeGenerator.h |  2 +-
 Source/cmake.cxx|  7 ++-
 17 files changed, 35 insertions(+), 22 deletions(-)

diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx
index 006239a..ee255af 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -664,7 +664,7 @@ int cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
 globalGenerator-GenerateBuildCommand(buildCommand, cmakeMakeProgram,
 installProjectName, installDirectory,
 globalGenerator-GetPreinstallTargetName(),
-buildConfig, false);
+buildConfig, false, false);
 std::string buildCommandStr =
   cmSystemTools::PrintSingleCommand(buildCommand);
 cmCPackLogger(cmCPackLog::LOG_DEBUG,
diff --git a/Source/CTest/cmCTestBuildAndTestHandler.cxx 
b/Source/CTest/cmCTestBuildAndTestHandler.cxx
index 4cdce71..0827037 100644
--- a/Source/CTest/cmCTestBuildAndTestHandler.cxx
+++ b/Source/CTest/cmCTestBuildAndTestHandler.cxx
@@ -310,7 +310,7 @@ int 
cmCTestBuildAndTestHandler::RunCMakeAndTest(std::string* outstring)
   output, this-BuildMakeProgram,
   config,
   !this-BuildNoClean,
-  false, remainingTime);
+  false, false, remainingTime);
 out  output;
 // if the build failed then return
 if (retVal)
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 6147009..36395aa 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1677,14 +1677,14 @@ int cmGlobalGenerator::TryCompile(const std::string 
srcdir,
 mf-GetSafeDefinition(CMAKE_TRY_COMPILE_CONFIGURATION);
   return this-Build(srcdir,bindir,projectName,
  newTarget,
- output,,config,false,fast,
+ output,,config,false,fast,false,
  this-TryCompileTimeout);
 }
 
 void cmGlobalGenerator::GenerateBuildCommand(
   std::vectorstd::string makeCommand, const std::string,
   const std::string, const std::string, const std::string,
-  const std::string, bool,
+  const std::string, bool, bool,
   std::vectorstd::string const)
 {
   makeCommand.push_back(
@@ -1697,7 +1697,7 @@ int cmGlobalGenerator::Build(
   std::string output,
   const std::string makeCommandCSTR,
   const std::string config,
-  bool clean, bool fast,
+  bool clean, bool fast, bool verbose,
   double timeout,
   cmSystemTools::OutputOption outputflag,
   std::vectorstd::string const nativeOptions)
@@ -1722,7 +1722,7 @@ int cmGlobalGenerator::Build(
 {
 std::vectorstd::string cleanCommand;
 this-GenerateBuildCommand(cleanCommand, makeCommandCSTR, projectName,
-   bindir, clean, config, fast);
+   bindir, clean, config, fast, verbose);
 output += \nRun Clean Command:;
 output += cmSystemTools::PrintSingleCommand(cleanCommand);
 output += \n;
@@ -1745,7 +1745,8 @@ int cmGlobalGenerator::Build(
   // now build
   std::vectorstd::string makeCommand;
   this-GenerateBuildCommand(makeCommand, makeCommandCSTR, projectName,
- bindir, target, config, fast, nativeOptions);
+ bindir, target, config, fast, verbose,
+ nativeOptions);
   std::string makeCommandStr = cmSystemTools::PrintSingleCommand(makeCommand);
   output += \nRun Build Command:;
   output += makeCommandStr;
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 08f061a..5b9ddee 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -134,7 +134,7 @@ public:
 const std::string projectName, const std::string targetName,
 std::string output,
 const std::string makeProgram, const std::string config,
-bool clean, bool fast,
+bool 

Re: [cmake-developers] [ANNOUNCE] CMake 3.2.0-rc1 now ready for testing!

2015-02-26 Thread Orion Poplawski

On 02/17/2015 12:41 AM, Stephen Kelly wrote:

Orion Poplawski wrote:


On 02/13/2015 01:12 PM, Robert Maynard wrote:

I am proud to announce that CMake 3.2 has entered the release candidate
stage.


We're getting a fair number of test failures on Fedora Rawhide (with gcc
5 c++11):


This is a bug in GCC. I filed a bug and committed a workaround:

  http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aaad0bf3
  Work around bug in pre-release GNU CXX 5.0.


Thank you very much for filing the upstream bug report.  This is now 
fixed and in Fedora's gcc, so I don't think it makes sense to check any 
workaround into cmake.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--

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