[Cmake-commits] CMake branch, master, updated. v3.6.0-rc2-129-g83ae794

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  83ae79442c8bc16cca72977e0671845efe191696 (commit)
  from  909d51bece7d343f32a8f59351aad5c396101a2c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83ae79442c8bc16cca72977e0671845efe191696
commit 83ae79442c8bc16cca72977e0671845efe191696
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Jun 16 00:01:06 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Jun 16 00:01:06 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index da12fe0..3c49d03 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 6)
-set(CMake_VERSION_PATCH 20160615)
+set(CMake_VERSION_PATCH 20160616)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] cmake install target doesn't run ldconfig after installing library

[Young Yang]

Hi,
I've encountered some problem when writing install target with cmake.

I use `install (TARGETS  DESTINATION lib)` to install my
shared_library.
However, when I run `make install`. It just install the .so to
/usr/local/lib and didn't run the ldconfig.

I think it is strange and inconvenient to tell the user he should run
ldconfig by himself or herself.

What is the best way to make the ldconfig run automatically?


Thanks in advance :)

-- 
Best wishes,
Young Yang
-- 

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-commits] CMake branch, next, updated. v3.6.0-rc2-315-g5ce786e

[Daniel Pfeifer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  5ce786e3d810391c2ed259e2ac0bad2d8ac5a9eb (commit)
   via  d645b03e9c97856436b9fcd517b2c33b8aa3302c (commit)
   via  909d51bece7d343f32a8f59351aad5c396101a2c (commit)
  from  ff2a74b6fa5c9d13647e61cee90d0699661416c4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ce786e3d810391c2ed259e2ac0bad2d8ac5a9eb
commit 5ce786e3d810391c2ed259e2ac0bad2d8ac5a9eb
Merge: ff2a74b d645b03
Author: Daniel Pfeifer 
AuthorDate: Wed Jun 15 17:55:47 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed Jun 15 17:55:47 2016 -0400

Merge topic 'cmOutputConverter-stringstream' into next

d645b03e cmOutputConverter: implement Shell__GetArgument using ostringstream
909d51be CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d645b03e9c97856436b9fcd517b2c33b8aa3302c
commit d645b03e9c97856436b9fcd517b2c33b8aa3302c
Author: Daniel Pfeifer 
AuthorDate: Wed Jun 15 23:41:46 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Wed Jun 15 23:44:37 2016 +0200

cmOutputConverter: implement Shell__GetArgument using ostringstream

This removes the need to calculate the resulting string length
beforehand.

diff --git a/Source/cmOutputConverter.cxx b/Source/cmOutputConverter.cxx
index 8e80bd0..da43a11 100644
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -15,6 +15,7 @@
 #include "cmake.h"
 
 #include 
+#include 
 
 #include   /* isalpha */
 #include  /* strlen */
@@ -328,19 +329,9 @@ std::string cmOutputConverter::EscapeForShell(const 
std::string& str,
 flags |= Shell_Flag_NMake;
   }
 
-  // Compute the buffer size needed.
-  int size = (this->GetState()->UseWindowsShell()
-? Shell_GetArgumentSizeForWindows(str.c_str(), flags)
-: Shell_GetArgumentSizeForUnix(str.c_str(), flags));
-
-  // Compute the shell argument itself.
-  std::vector arg(size);
-  if (this->GetState()->UseWindowsShell()) {
-Shell_GetArgumentForWindows(str.c_str(), [0], flags);
-  } else {
-Shell_GetArgumentForUnix(str.c_str(), [0], flags);
-  }
-  return std::string([0]);
+  return this->GetState()->UseWindowsShell()
+? Shell_GetArgumentForWindows(str.c_str(), flags)
+: Shell_GetArgumentForUnix(str.c_str(), flags);
 }
 
 std::string cmOutputConverter::EscapeForCMake(const std::string& str)
@@ -369,18 +360,7 @@ std::string cmOutputConverter::EscapeForCMake(const 
std::string& str)
 std::string cmOutputConverter::EscapeWindowsShellArgument(const char* arg,
   int shell_flags)
 {
-  char local_buffer[1024];
-  char* buffer = local_buffer;
-  int size = Shell_GetArgumentSizeForWindows(arg, shell_flags);
-  if (size > 1024) {
-buffer = new char[size];
-  }
-  Shell_GetArgumentForWindows(arg, buffer, shell_flags);
-  std::string result(buffer);
-  if (buffer != local_buffer) {
-delete[] buffer;
-  }
-  return result;
+  return Shell_GetArgumentForWindows(arg, shell_flags);
 }
 
 cmOutputConverter::FortranFormat cmOutputConverter::GetFortranFormat(
@@ -586,12 +566,10 @@ int cmOutputConverter::Shell__ArgumentNeedsQuotes(const 
char* in, int isUnix,
   return 0;
 }
 
-int cmOutputConverter::Shell__GetArgumentSize(const char* in, int isUnix,
-  int flags)
+std::string cmOutputConverter::Shell__GetArgument(const char* in, int isUnix,
+  int flags)
 {
-  /* Start with the length of the original argument, plus one for
- either a terminating null or a separating space.  */
-  int size = (int)strlen(in) + 1;
+  std::ostringstream out;
 
   /* String iterator.  */
   const char* c;
@@ -599,116 +577,17 @@ int cmOutputConverter::Shell__GetArgumentSize(const 
char* in, int isUnix,
   /* Keep track of how many backslashes have been encountered in a row.  */
   int windows_backslashes = 0;
 
-  /* Scan the string for characters that require escaping or quoting.  */
-  for (c = in; *c; ++c) {
-/* Look for $(MAKEVAR) syntax if requested.  */
-if (flags & Shell_Flag_AllowMakeVariables) {
-  /* Skip over the make variable references if any are present.  */
-  c = Shell__SkipMakeVariables(c);
-
-  /* Stop if we have reached the end of the string.  */
-  if (!*c) {
-break;
-  }
-}
-
-/* Check whether this character needs escaping for the shell.  */
-if (isUnix) {
-  /* On Unix a few special characters 

Re: [cmake-developers] [patch] iOS combined, some fixes

[Ruslan Baratov via cmake-developers]

On 15-Jun-16 22:59, Gregor Jasny wrote:

Hello,

Thanks for the patch!

On 15/06/16 16:41, Ruslan Baratov wrote:

Sending some fixes found by testing with Xcode 7.3

We were chasing some errors regarding the unified build some time ago.
But it appeared some for of heisenbug: the more I looked the less likely
it happened.

Is the error 100% reproducible for you?

Yes - for the Travis VM with xcode7.3 image. Not - for my local machine.


  And do you know what goes wrong?
Yes, I've leaved a note in the comments section. There are some messages 
in error stream, they are not related to lipo location. Here is example 
of the log with error:


   CMake Error at
   
/Users/travis/build/ingenue/hunter/_ci/cmake/share/cmake-3.5/Modules/CMakeIOSInstallCombined.cmake:102
   (message):
   Command failed (File name too long): 2016-05-31 18:37:15.058
   xcodebuild[6590:18239] Build settings from command line:
   2016-05-31 18:37:15.059 xcodebuild[6590:18239] TOOLCHAINS =
   com.apple.dt.toolchain.XcodeDefault
   2016-05-31 18:37:15.059 xcodebuild[6590:18239]
   XCODE_DEFAULT_TOOLCHAIN_OVERRIDE =
   
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
   
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo;-info;/Users/travis/build/ingenue/hunter/_testing/Hunter/_Base/7f9eaa4/f53c868/1c14a4b/Build/GTest/Build/GTest-Release-prefix/src/GTest-Release-build/googlemock/Release-iphonesimulator/libgmock.a




Does the

list(LENGTH _lipo_path len)
if(NOT len EQUAL 1)

take paths with spaces into account?
Nope as far as I know. In fact it doesn't catch the error I've seen, I 
decide to add some sanity checks just to be sure.


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

Re: [CMake] cmake targeting vs2015 error

[Kristian]

Could you give us either the CMakeLists.txt or the whole cl command, which
was called?

Without of some more information, I could not give you a hint, where the
problem is.

2016-06-15 14:43 GMT-04:00 Welson Sun :

> cmake 3.4.3 on windows 7 targeting vs2015 error out:
>
> cl : Command line error D8021: invalid numeric argument
> '/Wno-variadic-macros'
>
>
> Thanks,
> Welson
>
> --
>
> 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] [patch] iOS combined, some fixes

[Gregor Jasny via cmake-developers]

Hello,

Thanks for the patch!

On 15/06/16 16:41, Ruslan Baratov wrote:
> Sending some fixes found by testing with Xcode 7.3

We were chasing some errors regarding the unified build some time ago.
But it appeared some for of heisenbug: the more I looked the less likely
it happened.

Is the error 100% reproducible for you? And do you know what goes wrong?

Does the

   list(LENGTH _lipo_path len)
   if(NOT len EQUAL 1)

take paths with spaces into account?

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

Re: [cmake-developers] Possibly an obscure bug

[Chuck Atkins]

This isn't a bug but more of a weird side effect of having your executable
named the same as an include file and adding the destination directory for
the executable in the include path.  The same thing would happen if your
executable was named foo and you had "#include ".  By setting
CMAKE_INCLUDE_CURRENT_DIR to on then CMake is adding
-I/path/to/source/blink and -I/path/to/build/blink to the compile line.
The default destination for the list executable also happens to be
/path/to/build/blink.  The second time around, the list executable from the
first run is in the include path, thus #include  picks up the
executable instead of the C++ header.
-- 

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] Possibly an obscure bug

[Ben Boeckel]

On Wed, Jun 15, 2016 at 21:34:27 +0300, Binkie Pinkie wrote:
> build$ make
> Scanning dependencies of target list
> make[2]: Circular blink/CMakeFiles/list.dir/main.cpp.o <- blink/list
> dependency dropped.
> [ 50%] Building CXX object blink/CMakeFiles/list.dir/main.cpp.o
> In file included from /media/data/docs/dev/Blink/blink/main.cpp:2:0:
> /media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ‘\177’ in 
> program
>  ELF  > � @ @   �   @ 8   @@
>  ^

Looks like the built binary gets found by the compiler and it tries to
#include it. Try setting:

set(EXECUTABLE_OUTPUT_PATH "${CMAKE_BINARY_DIR}/bin")

to put the executable outside of the -I paths.

--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] cmake targeting vs2015 error

[Welson Sun]

cmake 3.4.3 on windows 7 targeting vs2015 error out:

cl : Command line error D8021: invalid numeric argument
'/Wno-variadic-macros'


Thanks,
Welson
-- 

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] Possibly an obscure bug

[Binkie Pinkie]

Hi,
TL;DR: The project compiles fine first time, but after touching a source
file to trigger a recompile, the recompilation fails with a large list of
errors.

To reproduce this must be done:

1) Have set(CMAKE_INCLUDE_CURRENT_DIR ON)
2) call your executable "list"
3) #include  anywhere in your project or include a system/library
header that #includes 

My own example, folder names have nothing to do with the bug:
[-] Blink
CMakeLists.txt
[-]blink
main.cpp
CMakeLists.txt

Top CMakeLists.txt content:

cmake_minimum_required(VERSION 2.8.12)

Project(Blink)

add_subdirectory(blink)


The other CMakeLists.txt file:

set(CMAKE_INCLUDE_CURRENT_DIR ON)
add_executable(list main.cpp)


main.cpp:

#include 

#include 


int main(int argc, char *argv[])

{

printf("Hello, world\n");

return 0;

}


The project will compile, but if main.cpp gets touched the
recompilation will fail.


Using Ubuntu 16.04, cmake version 3.5.1, any compiler (gcc/clang)


And here's the sample output of a failed compilation (the first umpteen lines):


build$ make
Scanning dependencies of target list
make[2]: Circular blink/CMakeFiles/list.dir/main.cpp.o <- blink/list
dependency dropped.
[ 50%] Building CXX object blink/CMakeFiles/list.dir/main.cpp.o
In file included from /media/data/docs/dev/Blink/blink/main.cpp:2:0:
/media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ‘\177’ in program
 ELF  > � @ @   �   @ 8   @@
 ^
/media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ‘\2’ in program
/media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ‘\1’ in program
/media/data/docs/dev/Blink/build/blink/list:1:1: error: stray ‘\1’ in program
/media/data/docs/dev/Blink/build/blink/list:1:8: warning: null
character(s) ignored
 ELF  > � @ @   �   @ 8   @@
^


Plus lots and lots of lines, and ends with:



/media/data/docs/dev/Blink/build/blink/list:1:2: error: ‘ELF’ does not
name a type

 ELF  > � @ @   �   @ 8   @@
  ^
/media/data/docs/dev/Blink/build/blink/list:1:651: error: ‘N’ does not
name a type
 x-x86-64.so.2 GNU GNU  �נ.;N�)��S�  cQ
 ^
blink/CMakeFiles/list.dir/build.make:62: recipe for target
'blink/CMakeFiles/list.dir/main.cpp.o' failed
make[2]: *** [blink/CMakeFiles/list.dir/main.cpp.o] Error 1
CMakeFiles/Makefile2:85: recipe for target
'blink/CMakeFiles/list.dir/all' failed
make[1]: *** [blink/CMakeFiles/list.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
-- 

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] GCC: -std=g++14 vs -std=c++14

[Elizabeth A. Fischer]

That seems wrong to me.  Regardless of how proud the  compiler makers are
of their extensions, the language you're using should depend as little as
possible (by default) on the compiler you choose.
-- Elizabeth

On Wed, Jun 15, 2016 at 11:48 AM, Robert Maynard  wrote:

> This is correct. The default for GCC has always been to enable gcc
> extensions, with GCC < 6 having a default of gnu++98, and GCC 6 having
> a default of gnu++14
>
> On Wed, Jun 15, 2016 at 11:00 AM, Patrick Boettcher
>  wrote:
> > On Wed, 15 Jun 2016 10:50:13 -0400
> > "Elizabeth A. Fischer"  wrote:
> >
> >> Why are these extensions not turned off by default?  Normally, things
> >> should conform to the standards out-of-the-box; and you should have to
> >> explicitly enable extensions.  Following that principle would have
> >> avoided this entire thread.
> >
> > Well, I'd not be surprised if the expected standard for gcc users is
> > --std=gnu++14 instead of --std=c++14 . That could be a good explanation.
> >
> > regards,
> > --
> > Patrick.
> > --
> >
> > 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] GCC: -std=g++14 vs -std=c++14

[Robert Maynard]

This is correct. The default for GCC has always been to enable gcc
extensions, with GCC < 6 having a default of gnu++98, and GCC 6 having
a default of gnu++14

On Wed, Jun 15, 2016 at 11:00 AM, Patrick Boettcher
 wrote:
> On Wed, 15 Jun 2016 10:50:13 -0400
> "Elizabeth A. Fischer"  wrote:
>
>> Why are these extensions not turned off by default?  Normally, things
>> should conform to the standards out-of-the-box; and you should have to
>> explicitly enable extensions.  Following that principle would have
>> avoided this entire thread.
>
> Well, I'd not be surprised if the expected standard for gcc users is
> --std=gnu++14 instead of --std=c++14 . That could be a good explanation.
>
> regards,
> --
> Patrick.
> --
>
> 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] GCC: -std=g++14 vs -std=c++14

[Patrick Boettcher]

On Wed, 15 Jun 2016 10:50:13 -0400
"Elizabeth A. Fischer"  wrote:

> Why are these extensions not turned off by default?  Normally, things
> should conform to the standards out-of-the-box; and you should have to
> explicitly enable extensions.  Following that principle would have
> avoided this entire thread.

Well, I'd not be surprised if the expected standard for gcc users is
--std=gnu++14 instead of --std=c++14 . That could be a good explanation.

regards,
--
Patrick.
-- 

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] GCC: -std=g++14 vs -std=c++14

[Elizabeth A. Fischer]

Why are these extensions not turned off by default?  Normally, things
should conform to the standards out-of-the-box; and you should have to
explicitly enable extensions.  Following that principle would have avoided
this entire thread.

-- Elizabeth

On Wed, Jun 15, 2016 at 1:50 AM, Patrick Boettcher <
patrick.boettc...@posteo.de> wrote:

> On Mon, 13 Jun 2016 20:05:23 +0200
> Patrick Boettcher  wrote:
> > > You also need to correctly set the CXX_EXTENSIONS properties to get
> > > a standard standard.
> >
> > Yep,
> >
> >   set(CXX_EXTENSIONS OFF)
> >
> > seems to do the trick - thanks.
>
> Well, it is
>
>   set(CMAKE_CXX_EXTENSIONS OFF)
>
> actually. Before the target-definition (add_library or add_executable).
>
>
> --
> Patrick.
> --
>
> 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] iOS combined, some fixes

[Ruslan Baratov via cmake-developers]

Hi,

Sending some fixes found by testing with Xcode 7.3

Ruslo
>From 2026570b6f3c7c950ffbb83effa5a176d9133c89 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Tue, 14 Jun 2016 23:44:41 +0300
Subject: [PATCH 1/2] CMakeIOSInstallCombined: add some sanity checks

---
 Modules/CMakeIOSInstallCombined.cmake | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Modules/CMakeIOSInstallCombined.cmake b/Modules/CMakeIOSInstallCombined.cmake
index 1256f56..e2a0fee 100644
--- a/Modules/CMakeIOSInstallCombined.cmake
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -251,6 +251,13 @@ function(ios_install_combined target destination)
 )
   endif()
   set(_lipo_path ${output})
+  list(LENGTH _lipo_path len)
+  if(NOT len EQUAL 1)
+message(FATAL_ERROR "Unexpected xcrun output: ${_lipo_path}")
+  endif()
+  if(NOT EXISTS "${_lipo_path}")
+message(FATAL_ERROR "File not found: ${_lipo_path}")
+  endif()
 
   set(CURRENT_CONFIG "${CMAKE_INSTALL_CONFIG_NAME}")
   set(CURRENT_TARGET "${target}")
-- 
2.7.4 (Apple Git-66)

>From ea14e3f5c019fda1cba449f66df879d651b43cef Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Wed, 15 Jun 2016 00:16:03 +0300
Subject: [PATCH 2/2] CMakeIOSInstallCombined: do not merge content of OUTPUT
 and ERROR variables

---
 Modules/CMakeIOSInstallCombined.cmake | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Modules/CMakeIOSInstallCombined.cmake b/Modules/CMakeIOSInstallCombined.cmake
index e2a0fee..57a1fe0 100644
--- a/Modules/CMakeIOSInstallCombined.cmake
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -237,17 +237,21 @@ function(ios_install_combined target destination)
   endif()
 
   set(cmd xcrun -f lipo)
+
+  # Do not merge OUTPUT_VARIABLE and ERROR_VARIABLE since latter may contain
+  # some diagnostic information even for the successful run.
   execute_process(
   COMMAND ${cmd}
   RESULT_VARIABLE result
   OUTPUT_VARIABLE output
-  ERROR_VARIABLE output
+  ERROR_VARIABLE error_output
   OUTPUT_STRIP_TRAILING_WHITESPACE
   ERROR_STRIP_TRAILING_WHITESPACE
   )
   if(NOT result EQUAL 0)
 message(
-FATAL_ERROR "Command failed (${result}): ${cmd}\n\nOutput:\n${output}"
+FATAL_ERROR "Command failed (${result}): ${cmd}\n\nOutput:\n${output}\nOutput(error):\n${error_output}"
 )
   endif()
   set(_lipo_path ${output})
-- 
2.7.4 (Apple Git-66)

-- 

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] Finding libxml2 when building llvm/clang

[Edward Diener]

On 6/15/2016 9:15 AM, Chuck Atkins wrote:

You could try to force libxml to be ignored by CMake so it will think it
wasn't found and use the fallback configuration:

cmake ... -DLIBXML2_LIBRARIES=IGNORE ...


I will try that, thanks !

But shouldn't CMake be able to distinguish between a 32-bit and a 64-bit 
version of a library when 'find_package(some_library)' is specified ?




- Chuck

On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener
> wrote:

Building llvm/clang from source involves using CMake. I am building
llvm/clang from source on Windows using CMake 3.5.2. I am not a
clang developer, just a clang user. Similarly I just use CMake
rather than understand or write CMakeLists.txt files.

I reported a problem to clang where building a 32-bit version of
clang succeeds but building a 64-bit version of clang fails with xml
link errors. I have A 32-bit libxml2 binary in my path from
gnuwin32, but not a 64-bit binary of libxml2 in my path.

I was told by clang developers that one of the tools which clang
builds uses xml and libxml2 if it is available, otherwise uses some
other technology for the tool. The suggestion was that the problem I
am encountering is that of CMake; that CMake does not recognize that
the libxml2 which I have is the 32-bit version and instead thinks
that it is the 64-bit version and therefore attempts erroneously to
use it in the 64-bit build of clang.

Does anybody know what might be happening here ? I do not create the
CMakeLists.txt files used by llvm/clang so I do not know how the use
of libxml2 can be optionally specified in them.



--

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] daemon-mode: Project structure

[Tobias Hunger]

Hi Brad,

The project structure now lists an array of artifacts per target.

Best Regards,
Tobias

On Fri, Jun 10, 2016 at 5:48 PM, Brad King  wrote:
> On 06/10/2016 11:24 AM, Tobias Hunger wrote:
>>> The cmGeneratorTarget::GetFullName method will give you the name of the
>>> "main" file for a target.  Passing `implib = true` will give the DLL
>>> import library path on platforms where IsDLLPlatform returns true.
>>
>> I would have never found that!
>>
>> I'll change the code to list both the main artefact and the implib (if
>> applicable).
>
> Oops, I meant to point you at cmGeneratorTarget::GetFullPath to get the
> absolute paths with file names.
>
> -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] Finding libxml2 when building llvm/clang

[Chuck Atkins]

You could try to force libxml to be ignored by CMake so it will think it
wasn't found and use the fallback configuration:

cmake ... -DLIBXML2_LIBRARIES=IGNORE ...

- Chuck

On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:

> Building llvm/clang from source involves using CMake. I am building
> llvm/clang from source on Windows using CMake 3.5.2. I am not a clang
> developer, just a clang user. Similarly I just use CMake rather than
> understand or write CMakeLists.txt files.
>
> I reported a problem to clang where building a 32-bit version of clang
> succeeds but building a 64-bit version of clang fails with xml link errors.
> I have A 32-bit libxml2 binary in my path from gnuwin32, but not a 64-bit
> binary of libxml2 in my path.
>
> I was told by clang developers that one of the tools which clang builds
> uses xml and libxml2 if it is available, otherwise uses some other
> technology for the tool. The suggestion was that the problem I am
> encountering is that of CMake; that CMake does not recognize that the
> libxml2 which I have is the 32-bit version and instead thinks that it is
> the 64-bit version and therefore attempts erroneously to use it in the
> 64-bit build of clang.
>
> Does anybody know what might be happening here ? I do not create the
> CMakeLists.txt files used by llvm/clang so I do not know how the use of
> libxml2 can be optionally specified in them.
>
> --
>
> 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] Toward a more deterministic ninja generator

[Florent Castelli]

To this, I would add that you could also remove duplicates. They’re rare but 
can happen in some conditions and trigger warnings in Ninja.

/Florent

> On 14 Jun 2016, at 17:18, Nicolas Desprès  wrote:
> 
> Hi,
> 
> While working on something else I wrote this patch:
> https://github.com/nicolasdespres/CMake/commit/59e4e62ba014c6fcd4519b57b621d9434f99ff19
>  
> 
> 
> It makes the ninja generator more deterministic by sorting the build edge's 
> inputs/outputs. It does not introduce any regression on my macbookpro.
> 
> This could help to fix issue #15968.
> 
> Regards,
> 
> -- 
> Nicolas Desprès
> -- 
> 
> 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