[Cmake-commits] CMake branch, master, updated. v3.9.0-354-gbfb40bc

[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  bfb40bcf666050feb9913131a8f6c0e9b7f57299 (commit)
  from  ab17dc6befdde5cebafc83f198793dd751454ea0 (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=bfb40bcf666050feb9913131a8f6c0e9b7f57299
commit bfb40bcf666050feb9913131a8f6c0e9b7f57299
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Jul 28 00:01:07 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Jul 28 00:01:07 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 134982f..72011b2 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 20170727)
+set(CMake_VERSION_PATCH 20170728)
 #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] CMake and Learning from bad examples

[Brian J. Davis]

Also at 
https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html?highlight=configure_package_config_file


set(INCLUDE_INSTALL_DIR  include/  ...  CACHE  )
set(LIB_INSTALL_DIR  lib/  ...  CACHE  )
set(SYSCONFIG_INSTALL_DIR  etc/foo/  ...  CACHE  )
#...
include(CMakePackageConfigHelpers)
configure_package_config_file(FooConfig.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
  INSTALL_DESTINATION  ${LIB_INSTALL_DIR}/Foo/cmake
  PATH_VARS  INCLUDE_INSTALL_DIR  SYSCONFIG_INSTALL_DIR)
write_basic_package_version_file(
  ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
  VERSION  1.2.3
  COMPATIBILITY  SameMajorVersion  )
install(FILES  ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
  ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION  ${LIB_INSTALL_DIR}/Foo/cmake  )


Does

INSTALL_DESTINATION  ${LIB_INSTALL_DIR}/Foo/cmake

from configure_package_config_file and

install(FILES  ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake 

install the file twice?  Is this from department of redundancy 
department department?.




-- 

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] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

[J. Caleb Wherry]

Not sure I understand your question but Visual Studio support just lagged a
version for that feature. It is available in CMake 3.9:

https://cmake.org/cmake/help/v3.9/release/3.9.html

Or are you asking before this version how was CUDA supported?

-Caleb

On Thu, Jul 27, 2017 at 9:07 PM Brian Davis  wrote:

>
> Can someone explain to me the meaning of the statement at:
>
> https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda
>
>
> Make learned to support CUDA as a first-class language that can be enabled
> via the project() and enable_language() commands.
> CUDA is currently supported by the Makefile Generators and the Ninja
> generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE
> is under development but not included in this release.*
> The NVIDIA CUDA Toolkit compiler (nvcc) is supported.
>
> Specifically:
>
> *Support for the Visual Studio IDE is under development but not included
> in this release.*
>
> Is CUDA as a first class language not supported for seemingly second class
> citizens such as Visual Studio?
> --
>
> 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

-- 
Sent from my iPhone 4s
-- 

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] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

[Christian Mazakas]

Probably means no more hacky MSBuild custom tasks which can't be
parallelized.


On Jul 27, 2017 6:07 PM, "Brian Davis"  wrote:

>
> Can someone explain to me the meaning of the statement at:
>
> https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda
>
>
> Make learned to support CUDA as a first-class language that can be enabled
> via the project() and enable_language() commands.
> CUDA is currently supported by the Makefile Generators and the Ninja
> generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE
> is under development but not included in this release.*
> The NVIDIA CUDA Toolkit compiler (nvcc) is supported.
>
> Specifically:
>
> *Support for the Visual Studio IDE is under development but not included
> in this release.*
>
> Is CUDA as a first class language not supported for seemingly second class
> citizens such as Visual Studio?
>
> --
>
> 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] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

[Brian Davis]

Can someone explain to me the meaning of the statement at:

https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda


Make learned to support CUDA as a first-class language that can be enabled
via the project() and enable_language() commands.
CUDA is currently supported by the Makefile Generators and the Ninja
generator on Linux, macOS, and Windows. *Support for the Visual Studio IDE
is under development but not included in this release.*
The NVIDIA CUDA Toolkit compiler (nvcc) is supported.

Specifically:

*Support for the Visual Studio IDE is under development but not included in
this release.*

Is CUDA as a first class language not supported for seemingly second class
citizens such as Visual Studio?
-- 

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] CMake 3.8+ and CUDA as a first class language, but not for Visual Studio... err what?

[Brian Davis]

Reading:

https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda

Can someone explain to me how CUDA is now supported as a first class
language,
-- 

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] CMake and Learning from bad examples

[Brian Davis]

In latest CMake Doc for cmake modules at:

https://cmake.org/cmake/help/v3.0/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers

I find:

Example using both configure_package_config_file() and
write_basic_package_version_file(): CMakeLists.txt:

set(INCLUDE_INSTALL_DIR include/ ... CACHE )
set(LIB_INSTALL_DIR lib/ ... CACHE )
set(SYSCONFIG_INSTALL_DIR etc/foo/ ... CACHE )
...
include(CMakePackageConfigHelpers)
configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
  INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
  PATH_VARS INCLUDE_INSTALL_DIR
SYSCONFIG_INSTALL_DIR)
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
 VERSION 1.2.3
 COMPATIBILITY SameMajorVersion )
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )



Uses for the install directory

INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake

which leads me to beleive that install will be to

${CMAKE_INSTALL_PREIX}/lib/Foo/cmake

However lets look at where say come projects from a company called Kitware
put them:

./lib/cmake
./lib/cmake/ITK-4.8
./lib/cmake/vtk-7.0

And note the version say  ITK-4.8 because if your intalling multiple
versions say old on top of new I may be a good idea not to have directories
without version info say like

lib/Foo

better might be

lib/cmake/Foo-1.2.3

but hey for documentation stating the "best practices" CMake still appears
all over the map when in comes to packages.

Thoughts?
-- 

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] CMake 3.9 change to dependencies of object compilation

[Puetz Kevin A]

I saw the following in the CMake 3.9 release notes, but didn't immediately 
realize all the implications. Sorry for not catching this during the -rc 
phase...

. The Ninja generator has loosened the dependencies of object compilation. 
Object compilation now depends only on custom targets and custom commands 
associated with libraries on which the object's target depends and no longer 
depends on the libraries themselves. Source files in dependent targets may now 
compile without waiting for their targets' dependencies to link.

We have a few cases where the object compilation really does depend on the 
TARGET_FILE itself, e.g.
1. An RC compiler embedding the resulting file of a custom target (I think this 
one may still work, since custom targets appear to have been exempted from the 
change)

2. MSVC's #import construct which needs the indirect dependencies (dependencies 
of the #import-ed dependency) be registered, which is handled as part of the 
target using add_custom_command(TARGET foo POST_BUILD COMMAND ...)

So. I appreciate this loosening in most cases, it's greatly fixed some 
unnecessary stalls in our parallel build, and for dependencies acquired 
target_link_libraries this seems 100% correct to apply them only to the linker 
rule. But it seems the changes impacted add_dependencies as well, so now how do 
I now express a real dependency between a compile rule and another target (i.e. 
get a target listed at the same level as cmake_object_order_depend_*?

add_custom_command(OUTPUT... DEPENDS...) seemingly still allows target-level 
dependencies for a file compilation step, but I can't figure out what property 
has the same effect on a normal source file (that's going to be built by a 
"built-in" rule like CMAKE_RC_COMPILE_OBJECT, CMAKE_CXX_COMPILE_OBJECT, etc). 
AddFileDependencies(.) (aka OBJECT_DEPENDS) doesn't allow say it allows 
target-level dependencies, and it doesn't seem to work in practice either.

The best I've been able to come up with far requires an indirect SYMBOLIC 
output file to carry the dependency between a phony add_custom_command and the 
real source's OBJECT_DEPENDS

ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.depends 
DEPENDS bar)
SET_PROPERTY(SOURCE ${CMAKE_CURRENT_BINARY_DIR}/foo.depends PROPERTY 
SYMBOLIC 1)
SET_PROPERTY(SOURCE source.cpp APPEND PROPERTY OBJECT_DEPENDS 
${CMAKE_CURRENT_BINARY_DIR}/foo.depends)

That works, but it definitely feels more like a workaround than the intended 
solution. If the generators can handle this for add_custom_command, it seems 
like they should be able to handle it for language compile rules too. Any 
better suggestions?


-- 

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] Android NDK, clang, and ODR violations

[Christopher Broadbent]

On 28/07/2017 02:28, Dan Albert wrote:
(in case threading doesn't work since I'm not a list member and can't 
reply to the original message: 
https://cmake.org/pipermail/cmake/2017-July/065886.html)


I'm pretty sure -Wl,--detect-odr-violations is just giving you false 
positives. Note that the warning message says "/possible/ ODR 
violation". We tried using this flag in the Android platform recently 
and found lots of false positives too.


Those symbols are weak in libc++abi, so this is not an ODR violation 
(they're not weak in libstdc++.so, and that's a bug, but not a harmful 
one; I'm fixing it right now either way).


FWIW, CMake shouldn't be linking libstdc++.so /and/ libc++_static.a in 
the same link either way, but this is actually something that both 
upstream CMake, the NDK's CMake toolchain file, and ndk-build all get 
wrong. It's something that we should resolve eventually, but it doesn't 
actually cause any problems so it hasn't been prioritized. Could argue 
that it has caused this problem, but this would still be firing on false 
positives if you'd added your own new/delete replacements, and this 
warning is still pretty much guaranteed to fire for libc++ because 
libandroid_support will do exactly the same thing and try to replace a 
bunch of things in libc.


Thanks, I'll move ahead with the switch, and look in to filtering out 
the warnings on these symbols, rather than disabling the ODR checks 
entirely.


--

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.0-353-gab17dc6

[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  ab17dc6befdde5cebafc83f198793dd751454ea0 (commit)
   via  eddbd62d0f7a1cbc6ae3eb1e6c79b955125502d4 (commit)
  from  1ed58b686c0f7b8690e89e1b6a7ffd6fb6dcee60 (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=ab17dc6befdde5cebafc83f198793dd751454ea0
commit ab17dc6befdde5cebafc83f198793dd751454ea0
Merge: 1ed58b6 eddbd62
Author: Craig Scott 
AuthorDate: Thu Jul 27 20:59:35 2017 +
Commit: Kitware Robot 
CommitDate: Thu Jul 27 16:59:39 2017 -0400

Merge topic 'FindBoost'

eddbd62d FindBoost: pop policy stack before returning

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eddbd62d0f7a1cbc6ae3eb1e6c79b955125502d4
commit eddbd62d0f7a1cbc6ae3eb1e6c79b955125502d4
Author: Cristian Adam 
AuthorDate: Mon Jul 24 11:34:34 2017 +0200
Commit: Craig Scott 
CommitDate: Thu Jul 27 07:49:48 2017 +1000

FindBoost: pop policy stack before returning

CMake would give a fatal error if the policy stack was cleaned up
upon exiting the module.

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index cc273e0..b4abf75 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -244,6 +244,8 @@ if (NOT Boost_NO_BOOST_CMAKE)
   message("Found Boost components:")
   message("   ${Boost_FIND_COMPONENTS}")
 endif()
+# Restore project's policies
+cmake_policy(POP)
 return()
   endif()
 endif()

---

Summary of changes:
 Modules/FindBoost.cmake |2 ++
 1 file changed, 2 insertions(+)


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

[Cmake-commits] CMake branch, master, updated. v3.9.0-351-g1ed58b6

[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  1ed58b686c0f7b8690e89e1b6a7ffd6fb6dcee60 (commit)
   via  0e434fcf0428f43dcc5f540ca0a61e078c9f4b4c (commit)
  from  ba184cefcd5941701237331251cfc8df6aa5563e (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=1ed58b686c0f7b8690e89e1b6a7ffd6fb6dcee60
commit 1ed58b686c0f7b8690e89e1b6a7ffd6fb6dcee60
Merge: ba184ce 0e434fc
Author: Craig Scott 
AuthorDate: Thu Jul 27 19:52:52 2017 +
Commit: Kitware Robot 
CommitDate: Thu Jul 27 15:52:56 2017 -0400

Merge topic 'autogen-tests-split'

0e434fcf Autogen: Move repeated tests to new QtAutogenRerun test

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e434fcf0428f43dcc5f540ca0a61e078c9f4b4c
commit 0e434fcf0428f43dcc5f540ca0a61e078c9f4b4c
Author: Sebastian Holtermann 
AuthorDate: Thu Jul 20 22:35:05 2017 +0200
Commit: Sebastian Holtermann 
CommitDate: Fri Jul 21 17:03:40 2017 +0200

Autogen: Move repeated tests to new QtAutogenRerun test

By moving QtAutogen tests that run repeatedly to a new QtAutogenRerun
test, the `ctest -R Qt[45]Autogen -j4` call runs approximately 25%
faster.

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 34418c5..13d796e 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1285,12 +1285,28 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   --build-exe-dir "${CMake_BINARY_DIR}/Tests/Qt5Autogen"
   --force-new-ctest-process
   --build-options ${build_options}
--DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE} 
-DQT_TEST_VERSION=5
+-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+-DQT_TEST_VERSION=5
 ${QtAutogen_BUILD_OPTIONS}
   --test-command ${run_autogen_test}
   )
 list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Qt5Autogen")
 
+add_test(NAME Qt5AutogenRerun COMMAND ${CMAKE_CTEST_COMMAND}
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/QtAutogenRerun"
+  "${CMake_BINARY_DIR}/Tests/Qt5AutogenRerun"
+  ${build_generator_args}
+  --build-project QtAutogenRerun
+  --build-exe-dir "${CMake_BINARY_DIR}/Tests/Qt5AutogenRerun"
+  --force-new-ctest-process
+  --build-options ${build_options}
+-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+-DQT_TEST_VERSION=5
+${QtAutogen_BUILD_OPTIONS}
+  )
+list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Qt5AutogenRerun")
+
 add_test(Qt5AutoUicInterface ${CMAKE_CTEST_COMMAND}
   --build-and-test
   "${CMake_SOURCE_DIR}/Tests/QtAutoUicInterface"
@@ -1315,12 +1331,28 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   --build-exe-dir "${CMake_BINARY_DIR}/Tests/Qt4Autogen"
   --force-new-ctest-process
   --build-options ${build_options}
--DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE} 
-DQT_TEST_VERSION=4
+-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+-DQT_TEST_VERSION=4
 ${QtAutogen_BUILD_OPTIONS}
   --test-command ${run_autogen_test}
   )
 list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Qt4Autogen")
 
+add_test(NAME Qt4AutogenRerun COMMAND ${CMAKE_CTEST_COMMAND}
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/QtAutogenRerun"
+  "${CMake_BINARY_DIR}/Tests/Qt4AutogenRerun"
+  ${build_generator_args}
+  --build-project QtAutogenRerun
+  --build-exe-dir "${CMake_BINARY_DIR}/Tests/Qt4AutogenRerun"
+  --force-new-ctest-process
+  --build-options ${build_options}
+-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+-DQT_TEST_VERSION=4
+${QtAutogen_BUILD_OPTIONS}
+  )
+list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/Qt4AutogenRerun")
+
 add_test(Qt4AutoUicInterface ${CMAKE_CTEST_COMMAND}
   --build-and-test
   "${CMake_SOURCE_DIR}/Tests/QtAutoUicInterface"
@@ -1330,7 +1362,8 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   --build-exe-dir "${CMake_BINARY_DIR}/Tests/Qt4AutoUicInterface"
   --force-new-ctest-process
   --build-options ${build_options}
--DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE} 
-DQT_TEST_VERSION=4
+-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
+-DQT_TEST_VERSION=4
   --test-command ${run_autouic_test}
   )
 

[CMake] Incorrect path to network drive location when installing libraries

[Ben Gregorski]

Hello,
 I have a library project (headers + libs) that I want to install onto a
Windows network drive location.
The project is created on my local drive as an out-of-source build.

When I use install(DIRECTORY ...) the network location is written correctly
into the cmake_install.cmake file as //foo/headers.

When I use install(TARGETS ...) the network location is written as
/foo/lib_32.lib which does not seem to work.

Any idea how I can fix this? I am using cmake 3.9

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

Re: [CMake] cmakedefine based on find_package

[Aaron Boxer]

Never mind, figured it out :)

#cmakedefine OPENCL_FOUND

On Thu, Jul 27, 2017 at 9:23 AM, Aaron Boxer  wrote:

> Hello,
>
> I am using find_package to find the OpenCL install on my system.
> Finding the package sets OPENCL_FOUND to true.
> I would like to create a #define in the code that will match this cmake
> variable,
> so I have set
>
> #cmakedefine HAVE_OPENCL @OPENCL_FOUND@
>
> in my config.h.cmake.in file.
>
> However, I get
>
> /* #undef HAVE_OPENCL */
>
> in the corresponding include file.
>
> Thanks,
> Aaron
>
>
>
-- 

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] cmakedefine based on find_package

[Aaron Boxer]

Hello,

I am using find_package to find the OpenCL install on my system.
Finding the package sets OPENCL_FOUND to true.
I would like to create a #define in the code that will match this cmake
variable,
so I have set

#cmakedefine HAVE_OPENCL @OPENCL_FOUND@

in my config.h.cmake.in file.

However, I get

/* #undef HAVE_OPENCL */

in the corresponding include file.

Thanks,
Aaron
-- 

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] Correct handling of absolute/relative installation paths

[David Demelier]

Le 27/07/2017 à 13:08, Eric Noulard a écrit :



2017-07-27 12:28 GMT+02:00 David Demelier >:


Hello,

I'm still trying to find a correct solution to handle user specified
installation paths.

Let's consider two kind of paths:

   - WITH_BINDIR (default: bin/) where to install executables,
   - WITH_DATADIR (default: share/project_name/) where to install
extra data.

I want to let the user configuring those paths because not all
distributions use the same paths (e.g. bin vs usr/bin).

Then, I also like to build the whole CMake project by creating the
hierarchy as it would be installed like:

/WITH_BINDIR/myapp
/WITH_DATADIR/somestuff.txt


Do you mean here that you setup CMAKE__OUTPUT_DIRECTORY (variable 
or target property) to your favorite value

or

Both, I set the output directory for executable to WITH_BINDIR value and 
also install it as destination.


My opinion is that you should never use absolute path (besides some very 
specific case on unix where you want to put something in /etc/...)

You should ask your user for

DATADIR
BINDIR
etc...



This is what I have done in my CMakeLists.txt, the cmake invocation 
fails if BINDIR and/or DATADIR are absolute. But again, then with some 
package managers you get in troubles because they specify absolute path.


See the RPM default macro:

  /usr/bin/cmake \
-DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
-DCMAKE_INSTALL_PREFIX:PATH=/usr \
-DINCLUDE_INSTALL_DIR:PATH=/usr/include \
-DLIB_INSTALL_DIR:PATH=/usr/lib64 \
-DSYSCONF_INSTALL_DIR:PATH=/etc \
-DSHARE_INSTALL_PREFIX:PATH=/usr/share \

And if you add any new variable, you should prefix by %{prefix} which is 
also absolute...


I wouldn't try to mimic install tree during the build (if it is what you 
are doing),


The nice thing is that you can easily run/debug the application 
especially if that application needs to find some plugins/data while 
running by evaluating paths to them.


I'll probably go for something like a pre-install target like you said 
instead of mimic'ing the build tree. And disable that target if any of 
the paths are absolute.


Thanks for the answers!
--

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] Correct handling of absolute/relative installation paths

[J Decker]

It's also handy to get installation paths from GNUInstallDirs

https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html  especially if
you expect to install libs on linux which either go to lib or lib64.

many things that install to windows just supply a standard base path
(/program files/) and then still use bin, lib, share, etc in that
path...

It is an annoyance to have to override dll installation to bin instead of
lib on windows

include( GNUInstallDirs )

if( WIN32 )
set( BINARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} )
set( SHARED_LIBRARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} )
set( SHARED_LIBRARY_LINK_DIR ${CMAKE_INSTALL_LIBDIR} )
else( WIN32 )
  set( BINARY_OUTPUT_DIR ${CMAKE_INSTALL_BINDIR} )
  set( SHARED_LIBRARY_OUTPUT_DIR ${CMAKE_INSTALL_LIBDIR} )
  set( SHARED_LIBRARY_LINK_DIR ${CMAKE_INSTALL_LIBDIR} )
endif( WIN32 )

and then use the aliased path instead

macro( install_my_thing )
install( TARGETS ${ARGV}
RUNTIME DESTINATION ${BINARY_OUTPUT_DIR}
LIBRARY DESTINATION ${SHARED_LIBRARY_OUTPUT_DIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} )
endmacro( install_my_thing )

People will inevitably also respond and say 'but dlls install as runtime'
which is probably true these days.  All I can do is copy the cmake stuff I
have that definitely works; which has been around since 2.6 or something...

So it's probably simpler than what I've shared above.


On Thu, Jul 27, 2017 at 4:08 AM, Eric Noulard 
wrote:

>
>
> 2017-07-27 12:28 GMT+02:00 David Demelier :
>
>> Hello,
>>
>> I'm still trying to find a correct solution to handle user specified
>> installation paths.
>>
>> Let's consider two kind of paths:
>>
>>   - WITH_BINDIR (default: bin/) where to install executables,
>>   - WITH_DATADIR (default: share/project_name/) where to install extra
>> data.
>>
>> I want to let the user configuring those paths because not all
>> distributions use the same paths (e.g. bin vs usr/bin).
>>
>> Then, I also like to build the whole CMake project by creating the
>> hierarchy as it would be installed like:
>>
>> /WITH_BINDIR/myapp
>> /WITH_DATADIR/somestuff.txt
>>
>
> Do you mean here that you setup CMAKE__OUTPUT_DIRECTORY (variable or
> target property) to your favorite value
> or
> You build and then install with the / prefix?
>
>
>>
>> Using relative paths makes the application relocatable, if I keep
>> WITH_BINDIR set as "bin" I can get the executable path at runtime, going
>> through its parent (bin/../) and then I can go share/project_name.
>> Obviously this is only valid for relative paths.
>>
>> However, a very high number of package managers build programs by
>> specifying absolute paths, it is not an issue: instead of getting the
>> directories at runtime, I use directly the absolute ones.
>>
>> On unix it can still work because it will just be translated as:
>>
>> /usr/local/bin/myapp
>> /usr/local/share/project_name/somestuff.txt
>>
>> This is much bigger an issue on Windows if the user set WITH_BINDIR to
>> something like D:/alt/bin
>>
>> The path would be translated to
>>
>> D:/alt/bin
>>
>> which is invalid on Windows.
>>
>> I like very much having this kind of `fakeroot' directory where you can
>> have a preview on how the project looks like but I don't know what to do if
>> paths are absolute, especially on Windows.
>>
>
> My opinion is that you should never use absolute path (besides some very
> specific case on unix where you want to put something in /etc/...)
> You should ask your user for
>
>DATADIR
>BINDIR
>etc...
>
> all those var should be relative path.
>
> and an eventual
>INSTALL_PREFIX
> which could be absolute.
>
> In any case if you really want to tolerate absolute path given by the
> user, but still want to mimic install location during the build
> then you'll have to escape it.
>
> For each path you expect from the user:
>
> check the path with if(IS_ABSOLUTE path) and compute some relative path
>   a) if you are on Windows remove the drive letter, i.e. D:/alt/bin
> becomes alt/bin
>   (or network drive share name //shairedisk/alt/bin  becomes
> alt/bin)
>   b) if you are on Unix
>
>
>>
>> What are your thoughts on that, recommandations?
>>
>
> I wouldn't try to mimic install tree during the build (if it is what you
> are doing),
> If I have a need to "verify" install tree structure then **after the
> build** I would do a fake install with a particular
> local prefix (as CPack does before packaging).
>
> Note that for similar reason CPack has to track files installed with
> absolute destination and
> possibly error out when it cannot handle it, particularly on Windows
> oriented generator:
> see e.g.:
> https://cmake.org/cmake/help/v3.7/variable/CPACK_ERROR_ON_
> ABSOLUTE_INSTALL_DESTINATION.html
>
> AFAIK, IFW and NSIS do not work with, absolute installed files.
>
>
> --
> Eric
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> 

Re: [CMake] Correct handling of absolute/relative installation paths

[Eric Noulard]

2017-07-27 12:28 GMT+02:00 David Demelier :

> Hello,
>
> I'm still trying to find a correct solution to handle user specified
> installation paths.
>
> Let's consider two kind of paths:
>
>   - WITH_BINDIR (default: bin/) where to install executables,
>   - WITH_DATADIR (default: share/project_name/) where to install extra
> data.
>
> I want to let the user configuring those paths because not all
> distributions use the same paths (e.g. bin vs usr/bin).
>
> Then, I also like to build the whole CMake project by creating the
> hierarchy as it would be installed like:
>
> /WITH_BINDIR/myapp
> /WITH_DATADIR/somestuff.txt
>

Do you mean here that you setup CMAKE__OUTPUT_DIRECTORY (variable or
target property) to your favorite value
or
You build and then install with the / prefix?


>
> Using relative paths makes the application relocatable, if I keep
> WITH_BINDIR set as "bin" I can get the executable path at runtime, going
> through its parent (bin/../) and then I can go share/project_name.
> Obviously this is only valid for relative paths.
>
> However, a very high number of package managers build programs by
> specifying absolute paths, it is not an issue: instead of getting the
> directories at runtime, I use directly the absolute ones.
>
> On unix it can still work because it will just be translated as:
>
> /usr/local/bin/myapp
> /usr/local/share/project_name/somestuff.txt
>
> This is much bigger an issue on Windows if the user set WITH_BINDIR to
> something like D:/alt/bin
>
> The path would be translated to
>
> D:/alt/bin
>
> which is invalid on Windows.
>
> I like very much having this kind of `fakeroot' directory where you can
> have a preview on how the project looks like but I don't know what to do if
> paths are absolute, especially on Windows.
>

My opinion is that you should never use absolute path (besides some very
specific case on unix where you want to put something in /etc/...)
You should ask your user for

   DATADIR
   BINDIR
   etc...

all those var should be relative path.

and an eventual
   INSTALL_PREFIX
which could be absolute.

In any case if you really want to tolerate absolute path given by the user,
but still want to mimic install location during the build
then you'll have to escape it.

For each path you expect from the user:

check the path with if(IS_ABSOLUTE path) and compute some relative path
  a) if you are on Windows remove the drive letter, i.e. D:/alt/bin becomes
alt/bin
  (or network drive share name //shairedisk/alt/bin  becomes
alt/bin)
  b) if you are on Unix


>
> What are your thoughts on that, recommandations?
>

I wouldn't try to mimic install tree during the build (if it is what you
are doing),
If I have a need to "verify" install tree structure then **after the
build** I would do a fake install with a particular
local prefix (as CPack does before packaging).

Note that for similar reason CPack has to track files installed with
absolute destination and
possibly error out when it cannot handle it, particularly on Windows
oriented generator:
see e.g.:
https://cmake.org/cmake/help/v3.7/variable/CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION.html

AFAIK, IFW and NSIS do not work with, absolute installed files.


-- 
Eric
-- 

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] Correct handling of absolute/relative installation paths

[David Demelier]

Hello,

I'm still trying to find a correct solution to handle user specified 
installation paths.


Let's consider two kind of paths:

  - WITH_BINDIR (default: bin/) where to install executables,
  - WITH_DATADIR (default: share/project_name/) where to install extra 
data.


I want to let the user configuring those paths because not all 
distributions use the same paths (e.g. bin vs usr/bin).


Then, I also like to build the whole CMake project by creating the 
hierarchy as it would be installed like:


/WITH_BINDIR/myapp
/WITH_DATADIR/somestuff.txt

Using relative paths makes the application relocatable, if I keep 
WITH_BINDIR set as "bin" I can get the executable path at runtime, going 
through its parent (bin/../) and then I can go share/project_name. 
Obviously this is only valid for relative paths.


However, a very high number of package managers build programs by 
specifying absolute paths, it is not an issue: instead of getting the 
directories at runtime, I use directly the absolute ones.


On unix it can still work because it will just be translated as:

/usr/local/bin/myapp
/usr/local/share/project_name/somestuff.txt

This is much bigger an issue on Windows if the user set WITH_BINDIR to 
something like D:/alt/bin


The path would be translated to

D:/alt/bin

which is invalid on Windows.

I like very much having this kind of `fakeroot' directory where you can 
have a preview on how the project looks like but I don't know what to do 
if paths are absolute, especially on Windows.


What are your thoughts on that, recommandations?

Regards,

--
David Demelier
--

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