[Cmake-commits] CMake branch, master, updated. v3.9.1-477-g131af5d

[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  131af5d591ac45a6ab49ccb760dd08e15ef36d81 (commit)
  from  8ebd590b211c26ea9a35a33d6f019e1909e0283c (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=131af5d591ac45a6ab49ccb760dd08e15ef36d81
commit 131af5d591ac45a6ab49ccb760dd08e15ef36d81
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Aug 16 00:01:07 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Aug 16 00:01:07 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 1f4e1d4..5d85ef0 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 9)
-set(CMake_VERSION_PATCH 20170815)
+set(CMake_VERSION_PATCH 20170816)
 #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

Re: [cmake-developers] iOS: direction to official support and questions

[Craig Scott]

There's discussions related to problems with linking and multiple
architectures in the following recent thread too:

http://public.kitware.com/pipermail/cmake-developers/2017-August/030192.html

Eric highlights a number of similar issues to those you've mentioned. Have
a read through the whole thread to get a deeper understanding, but it
sounds like you're already familiar with at least some of the problems.



On Wed, Aug 16, 2017 at 10:45 AM, Raffi Enficiaud <
raffi.enfici...@mines-paris.org> wrote:

> Le 10.08.17 à 17:04, Brad King a écrit :
>
>> On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:
>>
>>> I have looked a bit to the Android toolchains, and I have to say I found
>>> those quite complicated as a first reading :)
>>>
>>
>> This note may help:
>>
>>  https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971
>>
>
> Hi,
> Thanks for the link and the answers!
>
>
> I don't think iOS will need all the toolchain and stl selection logic.
>>
>> Ideally CMake would gain iOS platform modules such that one could
>> set CMAKE_SYSTEM_NAME to `iOS`.
>>
>> set(CMAKE_FIND_ROOT_PATH
>>>  ${CMAKE_IOS_DEVELOPER_ROOT}
>>>  ${CMAKE_IOS_SDK_ROOT}
>>>  ${CMAKE_PREFIX_PATH}
>>>  /path/to/boost_1_64_0_build/install
>>>  CACHE string  "iOS find search path root")
>>> ```
>>>
>>> where this path is hard coded, and points to the fat static libraries
>>> prefix path of boost. If I remove this path, FindBoost does not find the
>>> boost libraries anymore (of course I am passing BOOST_ROOT). In
>>> addition, I have this:
>>>
>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>>
>>
>> These last three lines tell the find commands to only look at
>> paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.
>> If boost is not under one of those then it won't be found.
>>
>> set(CMAKE_MACOSX_BUNDLE YES)
>>>
>>
>> Is it possible to build any binary of any form on iOS without this?
>>
>
> You're right, I do not think this is possible.
>
> If not then the iOS platform modules should set something to tell
>> the generators that this should always be enabled.
>>
>> set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
>>>
>>
>> Similarly for this, but perhaps only during `try_compile`.
>>
>
> What I understand from this variable is that, it sets the default of
> CODE_SIGNING_REQUIRED to "NO", and this can be overriden per target by
> setting the XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED target property to
> something else.
>
> Is that correct?
>
> I believe that for iOS developments, the default should rather be the
> opposite, and the try_compile should be informed of not trying to sign the
> app, via "some mechanism" as you suggested.
>
> Concerning this "some mechanism" part, what do you have in mind? Would it
> be an extra variable like 
> CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED_IN_TRY_COMPILE
> ?
>
> What I fail to understand here, is the purpose of the "try_compile" that
> is performed at the beginning. Isn't this try_compile supposed to compile
> source files only, without trying to link nor bundle anything? If this is
> the case, signing the result is irrelevant, and I do not understand why
> this fails.
>
> If you have an idea, good, otherwise I believe this is secondary right now.
>
> I'm not familiar enough with iOS development to answer the rest of
>> your questions.
>>
>
> Me neither :)
>
> Currently the main issue I am seeing is the multiarch/multisysroot target
> of XCode that is kind of lost when using CMake. By multiarch/multisysroot,
> I mean that Xcode is able to switch from iPhoneSimulatorXY to iPhoneXY
> without changing the project, and within the same view.
>
> The switching means changing the target architecture, as well as changing
> the SYSROOT. I checked the command lines emitted by XCode, and it changes
> the "-isysroot" flag based on the type of target.
>
> From the posts I can read online, this is causing a lot of troubles,
> especially when linking with libraries.
>
> For users' libraries, the workaround is to have fat libraries by combining
> all the target archs into one with lipo. The compilation is done with
> different "-isysroot" then. What I understood is that Apple is discouraging
> this, and this is for me not a proper solution neither, but might work.
>
> The real problem seems to be when linking to system libraries, those that
> are under sysroot, and I cannot find a good answer to this.
>
> Example:
>
> Suppose in the toolchain file, we have something like this, where
> CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not:
>
> '''
> set(CMAKE_FIND_ROOT_PATH
> ${CMAKE_IOS_DEVELOPER_ROOT}
> ${CMAKE_IOS_SDK_ROOT}
> ${CMAKE_PREFIX_PATH}
> /some/other/path
> CACHE string  "iOS find search path root")
>
> # set up the default search directories for frameworks
> set (CMAKE_SYSTEM_FRAMEWORK_PATH
> 

Re: [cmake-developers] iOS: direction to official support and questions

[Raffi Enficiaud]

Le 10.08.17 à 17:04, Brad King a écrit :

On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:

I have looked a bit to the Android toolchains, and I have to say I found
those quite complicated as a first reading :)


This note may help:

 https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971


Hi,
Thanks for the link and the answers!



I don't think iOS will need all the toolchain and stl selection logic.

Ideally CMake would gain iOS platform modules such that one could
set CMAKE_SYSTEM_NAME to `iOS`.


set(CMAKE_FIND_ROOT_PATH
 ${CMAKE_IOS_DEVELOPER_ROOT}
 ${CMAKE_IOS_SDK_ROOT}
 ${CMAKE_PREFIX_PATH}
 /path/to/boost_1_64_0_build/install
 CACHE string  "iOS find search path root")
```

where this path is hard coded, and points to the fat static libraries
prefix path of boost. If I remove this path, FindBoost does not find the
boost libraries anymore (of course I am passing BOOST_ROOT). In
addition, I have this:

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)


These last three lines tell the find commands to only look at
paths re-rooted under CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT.
If boost is not under one of those then it won't be found.


set(CMAKE_MACOSX_BUNDLE YES)


Is it possible to build any binary of any form on iOS without this?


You're right, I do not think this is possible.


If not then the iOS platform modules should set something to tell
the generators that this should always be enabled.


set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")


Similarly for this, but perhaps only during `try_compile`.


What I understand from this variable is that, it sets the default of 
CODE_SIGNING_REQUIRED to "NO", and this can be overriden per target by 
setting the XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED target property to 
something else.


Is that correct?

I believe that for iOS developments, the default should rather be the 
opposite, and the try_compile should be informed of not trying to sign 
the app, via "some mechanism" as you suggested.


Concerning this "some mechanism" part, what do you have in mind? Would 
it be an extra variable like 
CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED_IN_TRY_COMPILE ?


What I fail to understand here, is the purpose of the "try_compile" that 
is performed at the beginning. Isn't this try_compile supposed to 
compile source files only, without trying to link nor bundle anything? 
If this is the case, signing the result is irrelevant, and I do not 
understand why this fails.


If you have an idea, good, otherwise I believe this is secondary right now.


I'm not familiar enough with iOS development to answer the rest of
your questions.


Me neither :)

Currently the main issue I am seeing is the multiarch/multisysroot 
target of XCode that is kind of lost when using CMake. By 
multiarch/multisysroot, I mean that Xcode is able to switch from 
iPhoneSimulatorXY to iPhoneXY without changing the project, and within 
the same view.


The switching means changing the target architecture, as well as 
changing the SYSROOT. I checked the command lines emitted by XCode, and 
it changes the "-isysroot" flag based on the type of target.


From the posts I can read online, this is causing a lot of troubles, 
especially when linking with libraries.


For users' libraries, the workaround is to have fat libraries by 
combining all the target archs into one with lipo. The compilation is 
done with different "-isysroot" then. What I understood is that Apple is 
discouraging this, and this is for me not a proper solution neither, but 
might work.


The real problem seems to be when linking to system libraries, those 
that are under sysroot, and I cannot find a good answer to this.


Example:

Suppose in the toolchain file, we have something like this, where 
CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not:


'''
set(CMAKE_FIND_ROOT_PATH
${CMAKE_IOS_DEVELOPER_ROOT}
${CMAKE_IOS_SDK_ROOT}
${CMAKE_PREFIX_PATH}
/some/other/path
CACHE string  "iOS find search path root")

# set up the default search directories for frameworks
set (CMAKE_SYSTEM_FRAMEWORK_PATH
${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks
${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks
)
'''

and later in our CMakeLists, we have eg.

'''
find_package(ZLIB REQUIRED)
'''

The selection of the SYSROOT is done then on the cmd line given to 
CMake, and set up once.


The library that is found by ZLIB are related to CMAKE_IOS_SDK_ROOT, 
that is a constant in a build tree. Although Xcode can reroot the 
SYSROOT depending on the target device/arch (simulator/non-simulator).


Even if later XCode is able to switch sysroots on the command line, 
depending on the target, the libraries we are linking to are constant, 
and not honoring the dynamically determined sysroot anymore.


I believe this 

[cmake-developers] Future of ccmake and cmake-gui

[Daniel Pfeifer]

Hi,

With !977 merged, it is possible to base ccmake and cmake-gui on top of the
cmake server.
For demonstration, I copied the contents of the Source/CursesDialog
directory and added a proxy implementation of the classes `cmake` and
`cmState`. The result is 100% compatible with `ccmake`. The same would be
possible with cmake-gui.

Shall we proceed in this direction?

To make the server available everywhere, we should backport the code from
C++14 to C++11. I think this is limited to replacing `std::make_shared`.

For cmake-gui, the proxies could use Qt functionality (QProcess,
QJsonDocument, etc.). As a result, cmake-gui would not have any build
dependencies apart from Qt.

It might be worth considering to move ccmake and cmake-gui to their own
repositories.

Cheers, Daniel
-- 

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] [CPack] hdiutil error while executing cpack on macOS

[Robert Maynard]

Do better understand why the hdutil command is failing you should run
it manually and add in the -verbose option.

On Tue, Aug 15, 2017 at 8:53 AM, brian heim  wrote:
> Hi all,
>
> I'm getting an error trying to use CPack to create a macOS DragNDrop
> package. I tried to search for this message in the ML archives and elsewhere
> but wasn't able to find any conclusive solution, so I'm hoping someone with
> more experience with CPack may be able to help. My environment is:
>
> macOS 10.13
> cmake/cpack 3.9.1
>
> The output I'm getting is:
>
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Install project: SuperCollider
> CPack: -   Install component: Runtime
> CPack: -   Install component: Unspecified
> CPack: Create package
> CPack Error: Error executing: /usr/bin/hdiutil convert
> "/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/temp.dmg"
> -format UDBZ -imagekey zlib-level=9 -o
> "/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/SuperCollider-3.9.dev-OSX/SuperCollider-3.9.dev-OSX.dmg"
> CPack Error: Error compressing disk image.
> CPack Error: Problem compressing the directory
> CPack Error: Error when generating package: SuperCollider
>
> The output with --debug is here:
> https://gist.github.com/brianlheim/de692727fb0fc1ef629baf9f2c89d89b
>
> And the contents of my CPackConfig.cmake file are here:
> https://gist.github.com/brianlheim/6d40b5c6b047b1a18e1160715aa163c7
>
> This is a somewhat legacy project, so it's possible this used to work on an
> earlier version of CMake. I wouldn't know what version to compare it to,
> though.
>
> Thanks in advance.
>
> -Brian
>
>
>
> --
>
> 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] perpetually executed custom commands and timestamps

[Pawel Veselov]

Hello.

I'm trying something I don't think is unreasonable.

I need to have an automatically generated file, let's say version.h

I have to run a custom command to generate it.

The contents of the file depend on some external forces, the custom command
m
ay or may not change it (but it will always generate it if it is there).

That header is then included in bunch of other files, creating multiple
targets

So, I created a custom command that has declared output of version.h, and
have version.h included as sources for other (multiple) targets. This
worked,
but, of course, if the version.h is already there, the command wouldn't run.

I couldn't find any way to force the command to run, so after reading this
SO post: https://stackoverflow.com/questions/13920072, I added a PHONY
output
to the command, and dependency to the targets. This forced the command to
run every time.

However, when the command runs, but doesn't change the output file, there is
some target that forces the file to be updated (the touch_nocreate). This
causes the targets to both recompile and relink for no reason.

Questions:
1) Can I make a custom command run every time, even if its target is present
(without creating a PHONY target)? I don't want the
2) Can I turn the touching off?

I don't think using TARGET based custom command is right, as it's a
pre-build
target activity, and such is not supported for !VS.

I don't think using an ALL custom target is right, because custom target has
no output files, and target-to-target dependency wouldn't correctly
determine
that I need that .h file in time.

I would love to know what's the point of touch_no_create, really, I can't
imagine a good reason the file is refreshed when it wasn't touched, it seems
that the point would be to "cheat" the dependency resolution that way, which
may have valid use cases, but as a forced default?

Thank you,
  Pawel.
-- 

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, master, updated. v3.9.1-476-g8ebd590

[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  8ebd590b211c26ea9a35a33d6f019e1909e0283c (commit)
   via  f2cab9855bf5a041379e3a5bbdd26ca3ddeab87a (commit)
   via  8cfd52981d70bb0219fb23118b35a50faf320022 (commit)
   via  9b3c5ccf1200e237c0bad3336235b9dde289f016 (commit)
   via  1df3875871af9aa3f144ab065479b98e255aca5a (commit)
   via  187332b2fa169056a2c3682d9a7628d872b2d49b (commit)
   via  a17ef5748abc8ef5d3117b5c6c8138ef1cdc9719 (commit)
   via  53640a4610a650f59aa88240789737f873523fe0 (commit)
  from  e1c92163d3231f10100b4246c938957ad09e1951 (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=8ebd590b211c26ea9a35a33d6f019e1909e0283c
commit 8ebd590b211c26ea9a35a33d6f019e1909e0283c
Merge: f2cab98 a17ef57
Author: Brad King 
AuthorDate: Tue Aug 15 17:19:43 2017 +
Commit: Kitware Robot 
CommitDate: Tue Aug 15 13:19:53 2017 -0400

Merge topic 'cpack-deb-ipk'

a17ef574 CPackDeb: Loosen filename requirement to allow for .ipk

Acked-by: Kitware Robot 
Merge-request: !1093


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2cab9855bf5a041379e3a5bbdd26ca3ddeab87a
commit f2cab9855bf5a041379e3a5bbdd26ca3ddeab87a
Merge: 8cfd529 9b3c5cc
Author: Brad King 
AuthorDate: Tue Aug 15 17:17:40 2017 +
Commit: Kitware Robot 
CommitDate: Tue Aug 15 13:17:49 2017 -0400

Merge topic 'server-allow-cache'

9b3c5ccf Server: test cache after reconnect
1df38758 cmServerProtocol: allow 'cache' request before 'configure'
187332b2 cmServerProtocol: fix test of empty values

Acked-by: Kitware Robot 
Merge-request: !977


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8cfd52981d70bb0219fb23118b35a50faf320022
commit 8cfd52981d70bb0219fb23118b35a50faf320022
Merge: e1c9216 53640a4
Author: Brad King 
AuthorDate: Tue Aug 15 17:16:32 2017 +
Commit: Kitware Robot 
CommitDate: Tue Aug 15 13:16:35 2017 -0400

Merge topic 'autogen-less-verbose'

53640a46 Autogen: Only print Qt Autogenerator messages when verbose

Acked-by: Kitware Robot 
Merge-request: !1133


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b3c5ccf1200e237c0bad3336235b9dde289f016
commit 9b3c5ccf1200e237c0bad3336235b9dde289f016
Author: Daniel Pfeifer 
AuthorDate: Wed Jun 21 21:26:09 2017 +0200
Commit: Daniel Pfeifer 
CommitDate: Sun Aug 13 23:20:11 2017 +0200

Server: test cache after reconnect

diff --git a/Tests/Server/CMakeLists.txt b/Tests/Server/CMakeLists.txt
index e7eaa8d..2ad05c3 100644
--- a/Tests/Server/CMakeLists.txt
+++ b/Tests/Server/CMakeLists.txt
@@ -20,6 +20,7 @@ macro(do_test bsname file)
   endif()
 endmacro()
 
+do_test("test_cache" "tc_cache.json")
 do_test("test_handshake" "tc_handshake.json")
 do_test("test_globalSettings" "tc_globalSettings.json")
 do_test("test_buildsystem1" "tc_buildsystem1.json")
diff --git a/Tests/Server/cmakelib.py b/Tests/Server/cmakelib.py
index 78450d5..2218e02 100644
--- a/Tests/Server/cmakelib.py
+++ b/Tests/Server/cmakelib.py
@@ -95,6 +95,21 @@ def initProc(cmakeCommand):
 
   return cmakeCommand
 
+def exitProc(cmakeCommand):
+  # Tell the server to exit.
+  cmakeCommand.stdin.close()
+  cmakeCommand.stdout.close()
+
+  # Wait for the server to exit.
+  # If this version of python supports it, terminate the server after a 
timeout.
+  try:
+cmakeCommand.wait(timeout=5)
+  except TypeError:
+cmakeCommand.wait()
+  except:
+cmakeCommand.terminate()
+raise
+
 def waitForMessage(cmakeCommand, expected):
   data = ordered(expected)
   packet = ordered(waitForRawMessage(cmakeCommand))
@@ -197,3 +212,27 @@ def validateGlobalSettings(cmakeCommand, cmakeCommandPath, 
data):
 print("Validating", i)
 if (packet[i] != data[i]):
   sys.exit(1)
+
+def validateCache(cmakeCommand, data):
+  packet = waitForReply(cmakeCommand, 'cache', '', False)
+
+  cache = packet['cache']
+
+  if (data['isEmpty']):
+if (cache != []):
+  print('Expected empty cache, but got data.\n')
+  sys.exit(1)
+return;
+
+  if (cache == []):
+print('Expected cache contents, but got none.\n')
+sys.exit(1)
+
+  hadHomeDir = False
+  for value in cache:
+if (value['key'] == 'CMAKE_HOME_DIRECTORY'):
+  hadHomeDir = True
+
+  if (not hadHomeDir):
+print('No CMAKE_HOME_DIRECTORY found in cache.')
+

[Cmake-commits] CMake branch, master, updated. v3.9.1-468-ge1c9216

[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  e1c92163d3231f10100b4246c938957ad09e1951 (commit)
   via  683dbfe14dbf0c41dde6b916b221597075a775aa (commit)
   via  8fb9a5770af381a1f12bc5aa6ab1e99d136b5b01 (commit)
   via  060cef0c44300c3fa8fb655619eb7a599083ef49 (commit)
   via  9e0026216fb81e71ecd6918294a7ff8004132f1d (commit)
   via  fb0c3c564c6623750964bbbf6db602e089c2ecc4 (commit)
   via  45623e7255b62c4cd17c01a687130f05deeaac1d (commit)
  from  4ca8c08f36d86ad9f04a1e3c68695691f5ea3499 (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=e1c92163d3231f10100b4246c938957ad09e1951
commit e1c92163d3231f10100b4246c938957ad09e1951
Merge: 683dbfe 060cef0
Author: Brad King 
AuthorDate: Tue Aug 15 17:09:34 2017 +
Commit: Kitware Robot 
CommitDate: Tue Aug 15 13:09:40 2017 -0400

Merge topic 'update-kwsys'

060cef0c Merge branch 'upstream-KWSys' into update-kwsys
9e002621 KWSys 2017-08-11 (e1006189)

Acked-by: Kitware Robot 
Merge-request: !1130


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=683dbfe14dbf0c41dde6b916b221597075a775aa
commit 683dbfe14dbf0c41dde6b916b221597075a775aa
Merge: 8fb9a57 fb0c3c5
Author: Brad King 
AuthorDate: Tue Aug 15 17:09:15 2017 +
Commit: Kitware Robot 
CommitDate: Tue Aug 15 13:09:20 2017 -0400

Merge topic 'require-cmake-3.1'

fb0c3c56 Require CMake 3.1 to build CMake itself

Acked-by: Kitware Robot 
Acked-by: Ben Boeckel 
Acked-by: Craig Scott 
Merge-request: !1126


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8fb9a5770af381a1f12bc5aa6ab1e99d136b5b01
commit 8fb9a5770af381a1f12bc5aa6ab1e99d136b5b01
Merge: 4ca8c08 45623e7
Author: Brad King 
AuthorDate: Tue Aug 15 17:08:19 2017 +
Commit: Kitware Robot 
CommitDate: Tue Aug 15 13:08:26 2017 -0400

Merge topic 'cpackifw-package-file-extension'

45623e72 CPackIFW: Add CPACK_IFW_PACKAGE_FILE_EXTENSION variable

Acked-by: Kitware Robot 
Acked-by: Craig Scott 
Merge-request: !1117


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=060cef0c44300c3fa8fb655619eb7a599083ef49
commit 060cef0c44300c3fa8fb655619eb7a599083ef49
Merge: c47c011 9e00262
Author: Brad King 
AuthorDate: Fri Aug 11 10:13:23 2017 -0400
Commit: Brad King 
CommitDate: Fri Aug 11 10:13:23 2017 -0400

Merge branch 'upstream-KWSys' into update-kwsys

* upstream-KWSys:
  KWSys 2017-08-11 (e1006189)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e0026216fb81e71ecd6918294a7ff8004132f1d
commit 9e0026216fb81e71ecd6918294a7ff8004132f1d
Author: KWSys Upstream 
AuthorDate: Fri Aug 11 10:12:58 2017 -0400
Commit: Brad King 
CommitDate: Fri Aug 11 10:13:22 2017 -0400

KWSys 2017-08-11 (e1006189)

Code extracted from:

https://gitlab.kitware.com/utils/kwsys.git

at commit e100618908f7f7a41cbe623afa79ca0e4f17834a (master).

Upstream Shortlog
-

Chuck Atkins (2):
  993f0ea4 Add an option to split object and interface libs.
  b61faf89 Fix install rules and usage requirements for 
interface+object libs

Justin Berger (2):
  6d73752d Allow KWSYSPE_USE_SELECT macro to be overriden at compile 
time.
  da61baff Added cmake settable property to enable the macro

Sean McBride (1):
  dfa13188 Fixed a couple of trivial clang -Wunused-macros warnings

Shawn Waldon (1):
  da8a9e65 SystemTools: make GetFilenameName handle either kind of slash

diff --git a/CMakeLists.txt b/CMakeLists.txt
index e915b1a..d7d0c51 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,6 +20,21 @@
 #  KWSYS_HEADER_ROOT = The directory into which to generate the kwsys headers.
 #  A directory called "${KWSYS_NAMESPACE}" will be
 #  created under this root directory to hold the files.
+#  KWSYS_SPLIT_OBJECTS_FROM_INTERFACE
+#= Instead of creating a single ${KWSYS_NAMESPACE} library
+#  target, create three separate targets:
+#${KWSYS_NAMESPACE}
+#  - An INTERFACE library only containing usage
+# 

Re: [CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

[Brad King]

On 08/12/2017 03:28 AM, Clément Gregoire wrote:
> Should I file a bug report for this? 

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

Re: [CMake] Failed to build C++ source with CMakeLists.txt

[Chuck Atkins]

Hi Jupiter,


Compiling the C compiler identification source file "CMakeCCompilerId.c"
> failed.
> Compiler: /usr/local/gcc/4.9.1/bin/gcc
> Build flags: /usr/local/cppcms/1.1.0/include
>

It looks like you have an errant "/usr/local/cppcms/1.1.0/include" set in
your CFLAGS environment variable, or otherwise specified as a default
argument to the compiler, which is obviously not a valid flag.

- Chuck
-- 

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] Passing lists with generator expression through add_custom_command

[Raffi Enficiaud]

Le 15.08.17 à 16:48, Brad King a écrit :

On 08/13/2017 11:36 AM, Raffi Enficiaud wrote:

-DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}"


That is actually an unquoted argument whose value contains literal quotes.
See the cmake-language(7) manual for details on the syntax.  Switch it to

  "-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}"

to quote the argument so that add_custom_command receives it unexpanded.
Then use the VERBATIM option to add_custom_command to make sure it is
re-escaped for the shell properly.

-Brad



Ahh, thanks! and sorry for the noise!

Raffi

--

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] Passing lists with generator expression through add_custom_command

[Brad King]

On 08/13/2017 11:36 AM, Raffi Enficiaud wrote:
> -DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}"

That is actually an unquoted argument whose value contains literal quotes.
See the cmake-language(7) manual for details on the syntax.  Switch it to

  "-DALL_DEPENDENCIES=${ALL_DEPENDENCIES_FILES}"

to quote the argument so that add_custom_command receives it unexpanded.
Then use the VERBATIM option to add_custom_command to make sure it is
re-escaped for the shell properly.

-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] Windows symbolic links handling

[Brad King]

On 08/14/2017 06:35 AM, Manu wrote:
> Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...)
> behaviour changed. Now it reports symbolic link timestamp instead of pointed
> file timestamp.

Can you track down when that happened?

> patch to fix both get_filename_compoment and FILE(TIMESTAMP ...)
> 
> What troubles me is that symlink under Windows is a feature introduced in
> Windows Vista and the change for handling them will break Windows XP
> compatibility. Is this acceptable?

We still support running on XP.  If any newer Windows APIs are needed they
need to be looked up dynamically.  Also, behavior changes for existing commands
may need a policy.

See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for discussion
of symbolic link APIs.

-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] [CPack] hdiutil error while executing cpack on macOS

[brian heim]

Hi all,

I'm getting an error trying to use CPack to create a macOS DragNDrop
package. I tried to search for this message in the ML archives and
elsewhere but wasn't able to find any conclusive solution, so I'm hoping
someone with more experience with CPack may be able to help. My environment
is:

macOS 10.13
cmake/cpack 3.9.1

The output I'm getting is:

CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Install project: SuperCollider
CPack: -   Install component: Runtime
CPack: -   Install component: Unspecified
CPack: Create package
CPack Error: Error executing: /usr/bin/hdiutil convert
"/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/temp.dmg"
-format UDBZ -imagekey zlib-level=9 -o
"/Users/brianheim/git/supercollider/build/_CPack_Packages/OSX/DragNDrop/SuperCollider-3.9.dev-OSX/SuperCollider-3.9.dev-OSX.dmg"
CPack Error: Error compressing disk image.
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: SuperCollider

The output with --debug is here:
https://gist.github.com/brianlheim/de692727fb0fc1ef629baf9f2c89d89b

And the contents of my CPackConfig.cmake file are here:
https://gist.github.com/brianlheim/6d40b5c6b047b1a18e1160715aa163c7

This is a somewhat legacy project, so it's possible this used to work on an
earlier version of CMake. I wouldn't know what version to compare it to,
though.

Thanks in advance.

-Brian
-- 

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