Re: [cmake-developers] Please comment on ios-universal topic

2015-12-09 Thread Ruslan Baratov via cmake-developers

On 09-Dec-15 04:51, Gregor Jasny wrote:


Hello,

On 02/12/15 13:44, Bartosz Kosiorek wrote:

I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.

My thoughts about the property name:

I added the necessary functionality to also combine Frameworks and App
Bundles. So the _LIBS suffix now got misleading. And I think that
providing a different property for libraries, frameworks and app bundles
is not really helpful. To combine all targets one could set the CMAKE_
prefixed variable, to combine only some, one could set the property on
the target itself.

Deploying applications which support both armv7 (32bit) and armv8
(64bit) is already working by setting both architectures in the
OSX_ARCHITECTURES property because both are covered by the device SDK.

So technically we already support UNIVERSAL libraries. What we don't
support is combining device and simulator builds. So how about replacing
UNIVERSAL with COMBINED?

IOS_INSTALL_COMBINED_BINARY


Just to clarify you want to leave only one variable IOS_INSTALL_COMBINED_BINARY 
for the device + simulator on iOS platforms. Other platforms (in future) will 
be controlled by using *_ARCHITECTURES variables, right?

Ruslo

--

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] Keil Armcc support

2015-12-09 Thread yann suisini
Hi,

Is theresomme support planned in a near future for the Keil / Armcc
toolchain ?

Regards,

Yann Suisini
-- 

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][PATCH] AIX RPATH handling

2015-12-09 Thread Brad King
On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:
> You are right. I missed this capability.
> My first idea was to apply to exec the same approach as for shared lib but I 
> didn’t found appropriate variable: something like 
> CMAKE_EXE_CREATE__FLAGS
> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
> usage of the *_INIT variables.

Actually the old code has it in two places:

> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # -shared
> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall") 
> # +s, flag for exe link to use shared lib

The CREATE_ value is used when linking a shared library itself.
The LINK_ value is used to link executables.  Both should already
be getting the flag with no changes.

-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] Proposal to teach cmDepends to only take dependencies from the source tree

2015-12-09 Thread Ben Boeckel
On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote:
> I myself am on the side of simplicity. Using regular expressions would
> allow us to do what I want. But if >95% of the people using this new
> possibility would use it exactly like I plan to, then implementing it
> in a more complicated way than necessary would just be a bad design
> choice.

Do you have performance numbers for the change in your build between
using include_directories (or target_include_directories), with and
without SYSTEM, each with and without this change?

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

2015-12-09 Thread Brad King
On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote:
> Attached is a patch for AIX enabling correct generation of executables
> regarding runtime path handling (currently, build paths could be stored
> as part of installed executables): option -bnoipath is required for
> executables link command (currently, only shared libs link command
> get -bnoipath option).

Thanks.  I agree that -bnoipath should be used for all linking because
we never want the path to a library file to be encoded in its dependents.
However, the proposed patch moves the flag over to the flags used to
specify the RPATH.  These may not be used if CMAKE_SKIP_RPATH or similar
options are enabled.  We should find another place for the flag that
is always used for both shared libraries and executables.

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] Add command line options for deprecation message control

2015-12-09 Thread Brad King
On 12/07/2015 01:51 PM, Michael Scott wrote:
>> I noticed one glitch.  I built against Qt 5.5.1 on Linux and the
>> option dialog seems to truncate the labels.
> I think I've fixed it, by using vertical layouts rather than form 
> layouts and setting the size policy to expanding for the widgets, if 
> that doesn't fix I'll need to look into QT in more depth as I've not got 
> much experience with it. Which Linux distro did you notice it in, looks 
> like gnome3?

It is Debian 'testing' with KDE 5.  Your changes fixed it for me.

> Patches for the fix are attached.

Thanks.  Applied with slightly modified commit messages and
merged to 'next' for testing:

 cmake-gui: Add options to control warning messages
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c1850455

 cmake: Deduplicate warning message control code
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f4a91ef

-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] Keil Armcc support

2015-12-09 Thread Brad King
On 12/09/2015 06:25 AM, yann suisini wrote:
> Is theresomme support planned in a near future for the
> Keil / Armcc toolchain ? 

This was contributed recently:

 Add support for the ARM Compiler (arm.com)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=035a658f

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14786

Please try it out from the development version to see how it goes.

-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][PATCH] AIX RPATH handling

2015-12-09 Thread CHEVRIER, Marc

Oops !
You are right, on a simple example, all is OK. So the problem seems on my side.
I will investigate this curious behaviour…

Sorry for the noise.

Marc




On 09/12/15 15:15, "Brad King"  wrote:

>On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:
>> You are right. I missed this capability.
>> My first idea was to apply to exec the same approach as for shared lib but I 
>> didn’t found appropriate variable: something like 
>> CMAKE_EXE_CREATE__FLAGS
>> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
>> usage of the *_INIT variables.
>
>Actually the old code has it in two places:
>
>> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # -shared
>> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS 
>> "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib
>
>The CREATE_ value is used when linking a shared library itself.
>The LINK_ value is used to link executables.  Both should already
>be getting the flag with no changes.
>
>-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][PATCH] AIX RPATH handling

2015-12-09 Thread CHEVRIER, Marc
You are right. I missed this capability.
My first idea was to apply to exec the same approach as for shared lib but I 
didn’t found appropriate variable: something like CMAKE_EXE_CREATE__FLAGS
Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
usage of the *_INIT variables.

Marc




On 09/12/15 15:00, "Brad King"  wrote:

>On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote:
>> Attached is a patch for AIX enabling correct generation of executables
>> regarding runtime path handling (currently, build paths could be stored
>> as part of installed executables): option -bnoipath is required for
>> executables link command (currently, only shared libs link command
>> get -bnoipath option).
>
>Thanks.  I agree that -bnoipath should be used for all linking because
>we never want the path to a library file to be encoded in its dependents.
>However, the proposed patch moves the flag over to the flags used to
>specify the RPATH.  These may not be used if CMAKE_SKIP_RPATH or similar
>options are enabled.  We should find another place for the flag that
>is always used for both shared libraries and executables.
>
>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] set(CACHE) and the local scope

2015-12-09 Thread Ben Boeckel
Hi,

So some behavior I was unaware of until today came up:

set(var ON)
option(var "description" OFF)
message("var: ${var}")

outputs "OFF" for the first configure and "ON" for subsequent
configures. This is because set(var CACHE) does unset(var) *if* the
cache was touched. This is not done on the second time around since it
is already in the cache.

I think a policy to remove the unset(var) behavior should be added since
the current behavior means that clean builds can be wildly different
than incremental builds.

Related, I have a branch on the stage (update-variable-docs) which
attempts to clarify some darker corners of the set() command and the
*VARIABLES directory properties.

Thoughts on the documentation updates and the policy?

Thanks,

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0015876]: "Cannot restore timestamp"

2015-12-09 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15876 
== 
Reported By:A. Jesse Jiryu Davis
Assigned To:
== 
Project:CMake
Issue ID:   15876
Category:   CMake
Reproducibility:random
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-09 15:38 EST
Last Modified:  2015-12-09 15:38 EST
== 
Summary:"Cannot restore timestamp"
Description: 
Appears that bug http://public.kitware.com/Bug/view.php?id=13639 wasn't
completely fixed, or has experienced a regression. With CMake 3.2.2 I very
occasionally see this error at the end of an otherwise successful build on
Windows:

CUSTOMBUILD : CMake error : Cannot restore timestamp CMakeFiles\generate.stamp

Steps to Reproduce: 
CMakeLists.txt with multiple add_library commands.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-09 15:38 A. Jesse Jiryu DavisNew 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] Please comment on ios-universal topic

2015-12-09 Thread Gregor Jasny via cmake-developers

Hello,

On 09/12/15 10:21, Ruslan Baratov wrote:

IOS_INSTALL_COMBINED_BINARY


Just to clarify you want to leave only one variable
IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms.
Other platforms (in future) will be controlled by using *_ARCHITECTURES
variables, right?


Right. Any objections to that property name?

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] Support multiple directories by "cmake -E make_directory" command

2015-12-09 Thread Bartosz Kosiorek

Hello.


With following patch, I have added support for multiple directories for 
make_directory command.


?Best Regards

Bartosz
From e189db26e60254712e3e73a11296c58d8f61fe68 Mon Sep 17 00:00:00 2001
From: Bartosz Kosiorek 
Date: Wed, 9 Dec 2015 15:59:43 +0100
Subject: [PATCH] Extend make_directory command to support multiple directories

---
 Help/manual/cmake.1.rst   |  9 +
 Source/cmcmd.cxx  | 19 ---
 .../E_make_directory-directory-with-parent-result.txt |  1 +
 .../E_make_directory-directory-with-parent-stderr.txt |  0
 ...ke_directory-three-directories-and-file-result.txt |  1 +
 ...ke_directory-three-directories-and-file-stderr.txt |  1 +
 .../E_make_directory-three-directories-result.txt |  1 +
 .../E_make_directory-three-directories-stderr.txt |  0
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 14 ++
 9 files changed, 35 insertions(+), 11 deletions(-)
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-stderr.txt

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 4cbe976..3cd7888 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -167,7 +167,8 @@ Available commands are:
   Change the current working directory and run a command.
 
 ``compare_files  ``
-  Check if file1 is same as file2.
+  Check if  is same as . If files are the same,
+  then returns 0, if not itreturns 1.
 
 ``copy ... ``
   Copy files to  (either file or directory).
@@ -194,10 +195,10 @@ Available commands are:
   Run command in a modified environment.
 
 ``environment``
-  Display the current environment.
+  Display the current environment variables.
 
-``make_directory ``
-  Create a directory.
+``make_directory ...``
+  Create parent and  directories.
 
 ``md5sum ...``
   Compute md5sum of files.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 6a4234f..fb7b1f5 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -68,7 +68,7 @@ void CMakeCommandUsage(const char* program)
 << "  env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...\n"
 << "- run command in a modified environment\n"
 << "  environment   - display the current environment\n"
-<< "  make_directory dir- create a directory\n"
+<< "  make_directory ...   - create parent and  directories\n"
 << "  md5sum ...  - compute md5sum of files\n"
 << "  remove [-f] ... - remove the file(s), use -f to force "
"it\n"
@@ -447,15 +447,20 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args)
   }
 #endif
 
-else if (args[1] == "make_directory" && args.size() == 3)
+else if (args[1] == "make_directory" && args.size() > 2)
   {
-  if(!cmSystemTools::MakeDirectory(args[2].c_str()))
+  // If error occurs we want to continue copying next files.
+  bool return_value = 0;
+  for (std::string::size_type cc = 2; cc < args.size(); cc ++)
 {
-std::cerr << "Error making directory \"" << args[2]
-  << "\".\n";
-return 1;
+if(!cmSystemTools::MakeDirectory(args[cc].c_str()))
+  {
+  std::cerr << "Error creating directory \""
+<< args[cc] << "\".\n";
+  return_value = 1;
+  }
 }
-  return 0;
+  return return_value;
   }
 
 else if (args[1] == "remove_directory" && args.size() == 3)
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
@@ -0,0 +1 @@
+0
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt
new file mode 100644
index 000..e69de29
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt b/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-stderr.txt