from:"A A"

Re: [CMake] Custom installation of cmake

2019-10-20 Thread Raymond Wan

Hi Mahmood,

Did you try typing "./bootstrap --help"?

Perhaps something there is what you need?

Ray



On Sun, Oct 20, 2019 at 2:19 AM Mahmood Naderan via CMake
 wrote:
>
> OK and how about custom installation path of cmake?
>
>
> Regards,
> Mahmood
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[cmake-developers] [ANNOUNCE] CMake 3.16.0-rc2 is ready for testing

2019-10-20 Thread Robert Maynard via cmake-developers

I am proud to announce the second CMake 3.16 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.16

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.16/release/3.16.html

Some of the more significant changes in CMake 3.16 are:

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* "ctest(1)" now has the ability to serialize tests based on
  hardware requirements for each test. See Hardware Allocation for
  details.

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".


CMake 3.16 Release Notes


Changes made since CMake 3.15 include the following.


New Features



Languages
-

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.


Compilers
-

* The "Clang" compiler is now supported on "Solaris".


Platforms
-

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One

[CMake] [ANNOUNCE] CMake 3.16.0-rc2 is ready for testing

2019-10-20 Thread Robert Maynard via CMake

I am proud to announce the second CMake 3.16 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.16

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.16/release/3.16.html

Some of the more significant changes in CMake 3.16 are:

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* "ctest(1)" now has the ability to serialize tests based on
  hardware requirements for each test. See Hardware Allocation for
  details.

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".


CMake 3.16 Release Notes


Changes made since CMake 3.15 include the following.


New Features



Languages
-

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.


Compilers
-

* The "Clang" compiler is now supported on "Solaris".


Platforms
-

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One

[CMake] Policy Stack within Macros/Functions

2019-10-20 Thread Sérgio Agostinho

Hey everyone,

I’m shipping a config file for my library and inside I set push/pop
specific policies so that me and the consumers of my library can target
different policies without us clashing against each other. However I’m
struggling with |cmake_policy(PUSH)|/|cmake_policy(POP)| once they are
invoked from macro/functions.

Here’s a minimal failure example illustrating my problem

|project(pcl-config-test) cmake_minimum_required(VERSION 3.5)
cmake_policy(PUSH) macro(return_early) # clean up code cmake_policy(POP)
return() endmacro() # 1. do a bunch of things. invoke a couple of
macros/functions # from within other macros/functions, etc... # 2. some
error occurs if(ERROR) return_early() endif() # 3. Everything went well
cmake_policy(POP) |

This produces the following output

|CMake Error at CMakeLists.txt:27 (my_macro): cmake_policy POP without
matching PUSH CMake Error in CMakeLists.txt: cmake_policy PUSH without
matching POP -- Configuring incomplete, errors occurred! |

I was counting on the policy stack being preserved for at least macros,
but that is not the case.

Is there a way for me to return early from my config file from within
macros?

Best regards,

Sérgio




signature.asc
Description: OpenPGP digital signature
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Custom installation of cmake

2019-10-20 Thread Robert Maynard via CMake

The easiest way is to specify the custom compiler via the CC and CXX
environment variables.

On Sat, Oct 19, 2019 at 2:19 PM Mahmood Naderan via CMake
 wrote:
>
> OK and how about custom installation path of cmake?
>
>
> Regards,
> Mahmood
>
>
> On Saturday, October 19, 2019, 4:44:28 PM GMT+3:30, 15 knots 
>  wrote:
>
>
> What worked for me, is to add 'ools/gcc-7.1.0/bin/' in front of the
> PATh environment variable for the time cmake is invoked. E.g from
> bash.
> PATH=tools/gcc-7.1.0/bin/;$PATH cmake -G ...
>
> Martin
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc2-88-g41854d608b

2019-10-19 Thread Kitware Robot via Cmake-commits

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  41854d608ba2c76f81a1488a6156606232184a5f (commit)
  from  0671f71d70db238b35c7cd64296e0b9f3a5e68a9 (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=41854d608ba2c76f81a1488a6156606232184a5f
commit 41854d608ba2c76f81a1488a6156606232184a5f
Author: Kitware Robot 
AuthorDate: Sun Oct 20 00:01:04 2019 -0400
Commit: Kitware Robot 
CommitDate: Sun Oct 20 00:01:04 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index f129c3aa18..ed093297c2 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191019)
+set(CMake_VERSION_PATCH 20191020)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Custom installation of cmake

2019-10-19 Thread Mahmood Naderan via CMake

OK and how about custom installation path of cmake?

Regards,
Mahmood 

On Saturday, October 19, 2019, 4:44:28 PM GMT+3:30, 15 knots 
 wrote:  
 
 What worked for me, is to add 'ools/gcc-7.1.0/bin/' in front of the
PATh environment variable for the time cmake is invoked. E.g from
bash.
PATH=tools/gcc-7.1.0/bin/;$PATH cmake -G ...

Martin
  -- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Custom installation of cmake

2019-10-19 Thread Mahmood Naderan via CMake

 Hi
I would like to compile cmake source with a non default gcc version. That is, I 
have built gcc in my home$ ls tools/gcc-7.1.0/bin/
c++  gcc-ar  gcov-dumpx86_64-pc-linux-gnu-gcc
x86_64-pc-linux-gnu-gcc-ranlib
cpp  gcc-nm  gcov-toolx86_64-pc-linux-gnu-gcc-7.1.0
g++  gcc-ranlib  x86_64-pc-linux-gnu-c++  x86_64-pc-linux-gnu-gcc-ar
gcc  gcovx86_64-pc-linux-gnu-g++  x86_64-pc-linux-gnu-gcc-nm
and 
$ ls ~/cmake-3.14.6
Auxiliary   CMakeFiles  configure 
doxygen.config  Source
bootstrap   CMakeGraphVizOptions.cmake  CONTRIBUTING.rst  
HelpTemplates
Bootstrap.cmk   CMakeLists.txt  Copyright.txt 
LicensesTests
CMakeCache.txt  CMakeLogo.gif   CTestConfig.cmake 
Modules Utilities
CMakeCPack.cmakecmake_uninstall.cmake.inCTestCustom.cmake.in  
Packaging
CMakeCPackOptions.cmake.in  CompileFlags.cmake  DartConfig.cmake  
README.rst
In the manual, it is only stated to build cmake with the default options which 
will install cmake in the system paths.
./bootstrap
make
make install
I want to give it my gcc and install it in my home. How can I do that?
 

Regards,
Mahmood-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc2-87-g0671f71d70

2019-10-18 Thread Kitware Robot via Cmake-commits

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  0671f71d70db238b35c7cd64296e0b9f3a5e68a9 (commit)
  from  493c4e781a35a92c5c912b22493b84de750b1fe1 (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=0671f71d70db238b35c7cd64296e0b9f3a5e68a9
commit 0671f71d70db238b35c7cd64296e0b9f3a5e68a9
Author: Kitware Robot 
AuthorDate: Sat Oct 19 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Sat Oct 19 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index beeb0a6dac..f129c3aa18 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191018)
+set(CMake_VERSION_PATCH 20191019)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] CMake link order

2019-10-18 Thread Juan Sanchez

Hello,

I have always used all of the libraries at once to the
TARGET_LINK_LIBRARIES command.

In the following example, the link line order appears the same as the
libraries are listed on the line.

TARGET_LINK_LIBRARIES(devsim_tcl ${LIBRARIES} ${TCL_ARCHIVE}
${SUPERLU_ARCHIVE} ${BLAS_ARCHIVE} ${SQLITE3_ARCHIVE}
${SYMDIFF_ARCHIVE} ${OPTIONAL_LIBS} ${PTHREAD_LIB} ${DLOPEN_LIB})

This is important because my LIBRARIES need to all be on the link line
before the other libraries I am using.

Another option is to explicitly us ADD_DEPENDENCY to add dependencies
between the libraries:
https://cmake.org/cmake/help/latest/command/add_dependencies.html

If I had multiple libraries hopelessly intertwined, I would list them
multiple times:
A B A C

or force the linker to do multiple passes:

 -Wl,--start-group A B C  -Wl,--end-group

This is by using the start-group and end-group flags in your
TARGET_LINK_LIBRARIES line.
https://cmake.org/pipermail/cmake/2011-May/044478.html

Regards,

Juan






On Fri, Oct 18, 2019 at 9:56 AM Bon, William 
wrote:

> Hello,
>
> we are facing an issue while using cmake and we have no idea how to solve
> or debug it.
> We have a complex and huge project (about 50 subdirectories and
> dependencies everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize,
> we have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
> IMPORTED_LINK_INTERFACE_LANGUAGES "C"
> IMPORTED_LOCATION ${A_LIBRARY})
> ```
>
> B is a system library part of a package.
>
> We need to link A before B in every case.
>
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
>
> but from time to time, we don't know why, the library produced link in the
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
>
> Is there a way to find out what happens and why cmake change the link
> order for some project and not all projects ?
>
> Best regards,
>
> Bill
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake link order

2019-10-18 Thread Andreas Naumann


Hey all,

I face a similar problem when constructing a correct (and predictable)
link order for Linux and Cygwin. It would be of great help, if there is
some documentation.

In particular, I would raise two question
    1) when does the link order change?
    2) when does a clean up happen and in which way?

I did also some experiments on linux with cmake 3.13.4 and ended up with
the appended (nearly) minimal example. The example consists of:

 * two "fake"-libraries A and B, whose paths are stored in two
   variables libA and libB respectively. (they serve just for
   demonstration, no real linking is required)
 * two interface libraries interfaceA and interfaceB. Each links to the
   corresponding fake library.
 * two imported libraries impA and impB, each has the location to the
   corresponding fake library.

Now I construct some combinations:

1. An interface library interfaceA_B_vA, which links against the
   interface libraries "interfaceA interfaceB ${libA}" and an
   executable, which links only against interfaceA_B_vA. For that
   executable, I get the link order "B A"
2. Suppose one tries to correct that and link explicitly against with
   the variable. Such an executable which links as "${libA}
   interfaceA_B_vA". In that case, I got the link order "A A B". So we
   have a changed order compared to the previous experiment.
3. If I use the imported libraries instead of the variables from
   experiment 1, I get the link order A B A, as expected.

From these experiments, I got the impression, that

1. linking through variables remains a nightmare. That is nothing new.
2. interface libraries might change their order
3. imported libraries lead to a more stable link order?

I hope somebody could shed some light in this behavior.

Best regards,
Andreas


Am 18.10.19 um 18:24 schrieb Fred Baksik:



On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:


In target_link_libraries it states that "The library dependency graph
is normally acyclic (a DAG)".  I recall from my own experience that
the DAG is not always created the same way when generating the
project.  It has to do with the way with this part of CMake is
implemented (C++ containers and that sort of thing) so while all the
inputs are the same the order is Not the same so it produces a
different DAG which changed the ordering of the components build
order which also altered the link order.

For the GHS Generator to ensure that the exact same project files are
output we sorted the components by name into a vector first (instead
of just using a set) before supplying it to this algorithm.  Then the
results were always the same.



Sorry, I wanted to clarify this a bit.  The DAG is correct. For
example lets say A depends on B and C and then C on D.  This DAG
always comes out the same.  But when you try to extract the dependents
of A it sometimes returns something that will give you B then C or C
then B when accessing them in a linear order. So there were
differences if you inspected these items with the debugger.

When I ran across these kinds of things with the GHS Generator we sort
things in lexicographical order to produce the same results every time.

Best regards,
Fred



project(testLinkOrder)
cmake_minimum_required(VERSION 3.5)

file(WRITE "simpleProg.cc" "int main() { return 0; }")
set(libA "${CMAKE_BINARY_DIR}/A.a")
file(WRITE "${libA}" "i am not a library")

set(libB "${CMAKE_BINARY_DIR}/B.a")
file(WRITE "${libB}" "i am not a library")

add_library(impA IMPORTED STATIC)
set_target_properties(impA PROPERTIES IMPORTED_LOCATION ${libA})

add_library(impB IMPORTED STATIC)
set_target_properties(impB PROPERTIES IMPORTED_LOCATION ${libB})

add_library(interfaceA INTERFACE)
target_link_libraries(interfaceA INTERFACE ${libA})

add_library(interfaceB INTERFACE)
target_link_libraries(interfaceB INTERFACE ${libB})
#target_link_libraries(interfaceA INTERFACE ${libB})

add_library(interface_A_B_vA INTERFACE)
target_link_libraries(interface_A_B_vA INTERFACE interfaceA interfaceB ${libA})

add_executable(linkInterface_A_B_vA simpleProg.cc)
target_link_libraries(linkInterface_A_B_vA interface_A_B_vA)

add_executable(linkvA_IABAVA simpleProg.cc)
target_link_libraries(linkvA_IABAVA ${libA} interface_A_B_vA)

add_library(interface_impA_impB_vA INTERFACE)
target_link_libraries(interface_impA_impB_vA INTERFACE impA impB ${libA})

add_executable(linkInterface_impA_impB_vA simpleProg.cc)
target_link_libraries(linkInterface_impA_impB_vA interface_impA_impB_vA)
-- 

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

Re: [CMake] CMake link order

2019-10-18 Thread Fred Baksik

On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:
> 
> In target_link_libraries it states that "The library dependency graph is 
> normally acyclic (a DAG)". I recall from my own experience that the DAG is 
> not always created the same way when generating the project. It has to do 
> with the way with this part of CMake is implemented (C++ containers and that 
> sort of thing) so while all the inputs are the same the order is Not the same 
> so it produces a different DAG which changed the ordering of the components 
> build order which also altered the link order.
> 
> For the GHS Generator to ensure that the exact same project files are output 
> we sorted the components by name into a vector first (instead of just using a 
> set) before supplying it to this algorithm. Then the results were always the 
> same.
> 

Sorry, I wanted to clarify this a bit. The DAG is correct. For example lets say 
A depends on B and C and then C on D. This DAG always comes out the same. But 
when you try to extract the dependents of A it sometimes returns something that 
will give you B then C or C then B when accessing them in a linear order. So 
there were differences if you inspected these items with the debugger.

When I ran across these kinds of things with the GHS Generator we sort things 
in lexicographical order to produce the same results every time.

Best regards,
Fred-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake link order

2019-10-18 Thread Fred Baksik

On Fri, Oct 18, 2019, at 6:24 AM, Bon, William wrote:
> Hello,
> 
> we are facing an issue while using cmake and we have no idea how to solve or 
> debug it.
> We have a complex and huge project (about 50 subdirectories and dependencies 
> everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize, we 
> have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
>  IMPORTED_LINK_INTERFACE_LANGUAGES "C"
>  IMPORTED_LOCATION ${A_LIBRARY})
> ```
> 
> B is a system library part of a package.
> 
> We need to link A before B in every case.
> 
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
> 
> but from time to time, we don't know why, the library produced link in the 
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
> 
> Is there a way to find out what happens and why cmake change the link order 
> for some project and not all projects ?
> 
> Best regards,
> 
> Bill
> 

I'm going by memory when I saw something similar when updating the GHS 
Generator in CMake.

In target_link_libraries it states that "The library dependency graph is 
normally acyclic (a DAG)". I recall from my own experience that the DAG is not 
always created the same way when generating the project. It has to do with the 
way with this part of CMake is implemented (C++ containers and that sort of 
thing) so while all the inputs are the same the order is Not the same so it 
produces a different DAG which changed the ordering of the components build 
order which also altered the link order.

For the GHS Generator to ensure that the exact same project files are output we 
sorted the components by name into a vector first (instead of just using a set) 
before supplying it to this algorithm. Then the results were always the same.

But if I remember correctly an "add_dependency( B A )" or otherwise make B 
dependent on A does forces a dependency between the two libraries which forces 
the DAG to always put A before B.

I would bet that if you just did the project generation over and over again 
into different build directories you'll notice these kinds of differences in 
the different Makefiles (or whatever output that is expected by the generator).

This is how I noticed the issue with the GHS Generator because the ordering of 
some items were just changing in an unexpected fashion and I was always 
comparing what it generated against what I was expecting it to generate.

I never asked the main developers about this; and again this is just my own 
observations.

Best regards,
Fred-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake link order

2019-10-18 Thread Bon, William

Hello,

we are facing an issue while using cmake and we have no idea how to solve or 
debug it.
We have a complex and huge project (about 50 subdirectories and dependencies 
everywhere), and we are facing issue regarding the link order.
There is a lot of dependencies between those projects, and to summarize, we 
have two libraries A and B
A is an imported library from headers and shared lib .so declared like this
```
add_library(A SHARED IMPORTED GLOBAL)
set_target_properties(A PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES "C"
IMPORTED_LOCATION ${A_LIBRARY})
```

B is a system library part of a package.

We need to link A before B in every case.

In every project, we include A before B using
```
find_package(B)
target_link_libraries(${library_produced} PUBLIC A)
target_link_libraries(${library_produced} PUBLIC B)
```

but from time to time, we don't know why, the library produced link in the 
wrong order (checked with ldd and make VERBOSE=1).
it links B before A.

Is there a way to find out what happens and why cmake change the link order for 
some project and not all projects ?

Best regards,

Bill
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake annotated tag, v3.16.0-rc2, created. v3.16.0-rc2

2019-10-18 Thread Kitware Robot via Cmake-commits

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 annotated tag, v3.16.0-rc2 has been created
at  371dbf3c152a397447bfae8ddff298b64b01b83b (tag)
   tagging  92780281c2e8a46223b262b152caa9c8329373b1 (commit)
  replaces  v3.16.0-rc1
 tagged by  Brad King
on  Fri Oct 18 10:35:38 2019 -0400

- Log -
CMake 3.16.0-rc2
-BEGIN PGP SIGNATURE-

iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAl2pzboWHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhERaD/9OVP0OTe1NQSzV5hE+AemsP6lk
TGenQa7XQLAP3i6V4iEoGBjVal/VnwMLqT2VKwVdEyzQCj/rJlormMR18ejS48ug
Zq0WWlTa4wgjDQWl6WJNMvciBZgunHq1QgSxWkzuOwDM89+WFQseH2vaDUyIuP4D
avAl97+uFyiFkAdRHFZkISkKDY0unnMyGoxN4QdplrsbrOV+DR01eCzSPGma5oyl
dc5GawFB2HdWFDC92hU2dvSQZL8kJOyyUGoOHK2Fe1gDszRMJNqtkhrZy9qMklJ6
i4wZc5FMCh4kGMPYtzH7Y2n0Nt5WkOBpeUK4IsK0j8cANRpmOlnYtn+DnI2vpdX0
ubGFJG+sBnsP5SO6KndKHMyWFnGKkgw0Fq/0ytrt5fa752AofY0Mevfj9nP0kKxF
yeHN3YMPY0D7ATEuPQ8Ts2nnkhYVYdEOHHgO4N7buRKPp5jlVSxJJJL+T48L3O1N
n+TNwRKYmTZ4VmooiGxsK0OWfj8DBszHWtpBFha5E1QrG3/cl/9Frpi370gXc5sH
fu5ViCrBvHrnAh3+zsSmz16ezvpHO44hlkGi0AQ6r3/cqnldRNWrMBMe3lXTUJlU
qcwWJErQuMUQGhO85L5O2YNJp35YK989+2goBEi93DhiIvnF4dlADcY3I+bHX2cT
sB9+D/SZYgrZrlsPFQ==
=S0Rj
-END PGP SIGNATURE-

Ben Boeckel (2):
  FindPostgreSQL: support version 12
  FindPostgreSQL: support macports installation scheme

Brad King (36):
  Intel: Fix default C++ dialect detection on Windows
  Tests: Update CompileFeatures test for Intel 19 with VS 2015
  Help: Document CMAKE_UNITY_BUILD in 3.16 release notes
  Help: Improve UNITY_BUILD documentation formatting
  Help: Extend documentation of CMAKE_UNITY_BUILD variable
  Help: Document CMAKE_UNITY_BUILD/CMAKE_EXPORT_COMPILE_COMMANDS limitation
  Merge branch 'intel-19-compile-features' into release-3.16
  Merge branch 'doc-unity-build' into release-3.16
  Merge branch 'objc-c++flags' into release-3.16
  Merge branch 'iar-8051-support' into release-3.16
  Merge branch 'FindPostgreSQL-macports-and-v12' into release-3.16
  VS: Add toolset v142 CSharp flag table
  Merge branch 'vs-v142-csharp-flags' into release-3.16
  IRSL: Prefer MSVC runtime libraries from newest toolset first
  IRSL: Install vcruntime140_1.dll if available
  Merge branch 'InstallRequiredSystemLibraries-redist' into release-3.16
  CMakeVersion: Prefer Git information provided by 'git archive' exports
  Merge branch 'no-git-version' into release-3.16
  Merge branch 'FindOpenMP-clang-HIP-device' into release-3.16
  Merge branch 'cmake-initial-cache-relative' into release-3.16
  Help: Clarify documentation of CMAKE_STATIC_LINKER_FLAGS
  CMakeFindBinUtils: Remove unnecessary variable unset calls
  Merge branch 'doc-static-lib-flags' into release-3.16
  Merge branch 'FindHDF5-cray' into release-3.16
  Merge branch 'FindCurses-tinfow' into release-3.16
  Merge branch 'CMakeFindBinUtils-cleanup' into release-3.16
  Merge branch 'swift-cross-compile' into release-3.16
  Merge branch 'doc-add_link_options-typos' into release-3.16
  PCH: Document and test COMPILE_LANGUAGE genex for per-language header
  Merge branch 'doc-pch-compile-language' into release-3.16
  install,export: Do not treat language names as target names
  cmMakefileTargetGenerator: Inline WriteObjectBuildFile in only call site
  Merge branch 'export-target-lang-name' into release-3.16
  PCH: Fix Makefile dependencies to rebuild PCH on header changes
  Merge branch 'pch-makefile-depends' into release-3.16
  CMake 3.16.0-rc2

Cristian Adam (1):
  Objective-C: Do not treat Objective-C files as C++ files

Konstantin Pyzhov (1):
  FindOpenMP: Add support for HIP clang device pass

Kyle Edwards (1):
  CMakeVersion: Add option to disable Git suffix

Manuel Herrmann (1):
  FindCurses: use tinfow when wide support is requested

Micael Borgefeldt (2):
  IAR: Fix v850 assembler support file extensions
  IAR: Add 8051 support

Peter Waller (1):
  cmake: Fix relative path regression in -C

Saleem Abdulrasool (1):
  try_compile: support Swift for cross-compilation

Tom Lankhorst (1):
  Help: Fix typos and style in add_link_options documentation

Willem Deconinck (2):
  FindHDF5: Cray HDF5 Fortran module filename is usually capitalized
  FindHDF5: Append hdf5 to hdf5_hl to avoid undefined references

---


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-49-g92780281c2

2019-10-18 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  92780281c2e8a46223b262b152caa9c8329373b1 (commit)
  from  6dedb9742094470196698a5009441e3860e61f2a (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 -
---

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
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-135-g493c4e781a

2019-10-18 Thread Kitware Robot via Cmake-commits

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  493c4e781a35a92c5c912b22493b84de750b1fe1 (commit)
   via  92780281c2e8a46223b262b152caa9c8329373b1 (commit)
  from  fdb41a5102e1fef50fb918eba5f84cfc19a62734 (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=493c4e781a35a92c5c912b22493b84de750b1fe1
commit 493c4e781a35a92c5c912b22493b84de750b1fe1
Merge: fdb41a5102 92780281c2
Author: Brad King 
AuthorDate: Fri Oct 18 10:36:40 2019 -0400
Commit: Brad King 
CommitDate: Fri Oct 18 10:36:40 2019 -0400

Merge branch 'release-3.16'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] setting rpath in executable in build directory

2019-10-18 Thread Jędrzej Dudkiewicz

Hello,

I have the following scenario. I have gcc 9.2.0 and boost 1.71.0
installed in /opt/ZS/deps/... directory, built for both arm and
x86_64. I can build programs using them just fine and they run as
expected provided -Wl,-rpaht,/opt/ZS/deps... is added to g++ command
line.

Now I'm trying to build  mqtt_cpp library
(https://github.com/redboltz/mqtt_cpp) using them. Everything builds
just fine using:

export CXX=x86_64-linux-gnu-g++-9.2.0
cmake -G'Unix Makefiles' -S. -Bbuild \
-DBOOST_ROOT=/opt/ZS/deps/include/ \
-DBOOST_LIBRARYDIR=/opt/ZS/deps/x86_64-linux-gnu/lib/

This of course does not contain any information regarding RPATH. I
assumed this is why binaries (examples in fact) in build directory
can't find proper libraries, so I tried installing them (examples).
Unfortunately "make install" installs library (it is header-only
library) and not examples, so I can't run any of them.

Since I *really* want to run these examples, I tried configuring and
building using this command:

export CXX=x86_64-linux-gnu-g++-9.2.0
cmake -G'Unix Makefiles' -S. -Bbuild \
-DBOOST_ROOT=/opt/ZS/deps/include/ \
-DBOOST_LIBRARYDIR=/opt/ZS/deps/x86_64-linux-gnu/lib/ \
-DCMAKE_SKIP_BUILD_RPATH=FALSE \
-DCMAKE_SKIP_RPATH=OFF \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE

I assumed that -DCMAKE_SKIP_BUILD_RPATH=FALSE means that I want
binaries in build directory (not installed ones) to already have RPATH
embedded.
I also assumed that -DCMAKE_SKIP_RPATH=OFF assures me that RPATH will
be used during build and/or installation.
I assumed that -DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE is supposed to
add to binaries in build directory RPATH containing paths to libraries
found and used by CMake.

All of this simply isn't true, binaries generated by "make -j 4" not
only don't have proper RPATH, they don't have rpath at all, not even
invalid one. I tried with:

readelf -a build/example/broker | grep -i rpath

and using chrpath:

chrpath build/exampl/broker

but there is not even a trace of rpath. Greps comes back emptyhanded
and `chrpath` util informs me, that:

broker: no rpath or runpath tag found

Is there some some magical combination of these flags that allows me
to build and run (this is paramount) binaries that were not installed?

CMake used is 3.15.4, I don't think earlier ones are aware of boost's
version 1.71.0.

I also tried adding -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=ON , but it
changes nothing.

Thanks in advance,
-- 
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-133-gfdb41a5102

2019-10-18 Thread Kitware Robot via Cmake-commits

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  fdb41a5102e1fef50fb918eba5f84cfc19a62734 (commit)
   via  b34b4c5eac27bfc4a1e46f2b46ba17f5be6a8565 (commit)
   via  e7d57bc3c35e7c47746caf91591ef748b9ce3012 (commit)
   via  45b4b4b93076e16281ecee628ef8ffb0aae8f3d6 (commit)
   via  4bedf6c9fa3f55a19b09d5ab26cfd149ee2e13e6 (commit)
   via  548e9051a4f20657d04341107924171ea9d1bcb5 (commit)
   via  99e83d423500e11a8e85c2032e8c536bce175ed1 (commit)
  from  c867981c9d9bc8548d34f726940cd50b8d05d71c (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=fdb41a5102e1fef50fb918eba5f84cfc19a62734
commit fdb41a5102e1fef50fb918eba5f84cfc19a62734
Merge: b34b4c5eac 4bedf6c9fa
Author: Brad King 
AuthorDate: Fri Oct 18 13:01:57 2019 +
Commit: Kitware Robot 
CommitDate: Fri Oct 18 09:02:29 2019 -0400

Merge topic 'variable_watch-modernize'

4bedf6c9fa Refactor: Modernize `cmVariableWatchCommand` a little

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b34b4c5eac27bfc4a1e46f2b46ba17f5be6a8565
commit b34b4c5eac27bfc4a1e46f2b46ba17f5be6a8565
Merge: c867981c9d e7d57bc3c3
Author: Brad King 
AuthorDate: Fri Oct 18 13:01:36 2019 +
Commit: Kitware Robot 
CommitDate: Fri Oct 18 09:01:48 2019 -0400

Merge topic 'vs-vctargetspath'

e7d57bc3c3 VS: Propagate CMAKE_VS_GLOBALS into custom targets
45b4b4b930 VS: Propagate CMAKE_VS_GLOBALS into compiler id projects
548e9051a4 VS: Add support to override VCTargetsPath through toolset
99e83d4235 cmake: Teach --build mode to load CMAKE_GENERATOR_TOOLSET

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7d57bc3c35e7c47746caf91591ef748b9ce3012
commit e7d57bc3c35e7c47746caf91591ef748b9ce3012
Author: Alexander Boczar 
AuthorDate: Mon Sep 16 16:55:26 2019 -0700
Commit: Brad King 
CommitDate: Thu Oct 17 10:19:01 2019 -0400

VS: Propagate CMAKE_VS_GLOBALS into custom targets

Issue: #19708

diff --git a/Help/release/dev/vs-vctargetspath.rst 
b/Help/release/dev/vs-vctargetspath.rst
index 462d183b2a..d40af349e4 100644
--- a/Help/release/dev/vs-vctargetspath.rst
+++ b/Help/release/dev/vs-vctargetspath.rst
@@ -6,4 +6,5 @@ vs-vctargetspath
   to specify the ``VCTargetsPath`` value for project files.
 
 * The :variable:`CMAKE_VS_GLOBALS` variable value now applies during
-  compiler identification.
+  compiler identification and in targets created by the
+  :command:`add_custom_target` command.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 99c16f2374..a4f904b155 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -511,8 +511,7 @@ cmTarget::cmTarget(std::string const& name, 
cmStateEnums::TargetType type,
 initProp("DOTNET_TARGET_FRAMEWORK_VERSION");
   }
 
-  if (this->GetType() != cmStateEnums::INTERFACE_LIBRARY &&
-  this->GetType() != cmStateEnums::UTILITY) {
+  if (this->GetType() != cmStateEnums::INTERFACE_LIBRARY) {
 
 // check for "CMAKE_VS_GLOBALS" variable and set up target properties
 // if any

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45b4b4b93076e16281ecee628ef8ffb0aae8f3d6
commit 45b4b4b93076e16281ecee628ef8ffb0aae8f3d6
Author: Alexander Boczar 
AuthorDate: Thu Sep 26 17:37:47 2019 -0700
Commit: Brad King 
CommitDate: Thu Oct 17 10:18:52 2019 -0400

VS: Propagate CMAKE_VS_GLOBALS into compiler id projects

Issue: #19708

diff --git a/Help/release/dev/vs-vctargetspath.rst 
b/Help/release/dev/vs-vctargetspath.rst
index ff9d148134..462d183b2a 100644
--- a/Help/release/dev/vs-vctargetspath.rst
+++ b/Help/release/dev/vs-vctargetspath.rst
@@ -4,3 +4,6 @@ vs-vctargetspath
 * With :ref:`Visual Studio Generators` for VS 2010 and above,
   the :variable:`CMAKE_GENERATOR_TOOLSET` setting gained an option
   to specify the ``VCTargetsPath`` value for project files.
+
+* The :variable:`CMAKE_VS_GLOBALS` variable value now applies during
+  compiler identification.
diff --git a/Modules/CMakeDetermineCompilerId.cmake 
b/Modules/CMakeDetermineCompilerId.cmake
index 976b291220..f7ef755aeb 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -320,6 +320,12 @@ Id flags: ${testflags} 
${CMAKE_${lang}_COMPILER_ID_FLAGS_ALWAYS}
 if(CMAKE_VS_PLATFORM_TOOLSET_VCTARGETS_CUSTOM_DIR)
   set(id_ToolsetVCTargetsDir 
"${CMAKE_VS_PLATFORM_TOOLSET_VCTARGETS_CUSTOM_DIR}")
 endif()
+set(id_CustomGlobals "")
+foreach(pair IN LISTS CMAKE_VS_GLOBALS)
+

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-48-g6dedb97420

2019-10-18 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  6dedb9742094470196698a5009441e3860e61f2a (commit)
   via  797689ab35c6f1edc37b120804e348b03ce7b161 (commit)
   via  0b10b3ed6b3ee644a44414d8b5c205d94a967c12 (commit)
  from  7aab792716bb647aac2b5802e6e21148471a0c79 (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 -
---

Summary of changes:
 Source/cmMakefileTargetGenerator.cxx  | 27 +--
 Source/cmMakefileTargetGenerator.h|  5 -
 Tests/BuildDepends/CMakeLists.txt | 16 ++--
 Tests/BuildDepends/Project/CMakeLists.txt |  6 ++
 Tests/BuildDepends/Project/zot.cxx|  5 +++--
 Tests/BuildDepends/Project/zot_pch.cxx|  6 ++
 6 files changed, 38 insertions(+), 27 deletions(-)
 create mode 100644 Tests/BuildDepends/Project/zot_pch.cxx


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-126-gc867981c9d

2019-10-18 Thread Kitware Robot via Cmake-commits

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  c867981c9d9bc8548d34f726940cd50b8d05d71c (commit)
   via  1c84b5c86f23d3e1998f67d0cd417b317cd9558b (commit)
   via  6dedb9742094470196698a5009441e3860e61f2a (commit)
   via  797689ab35c6f1edc37b120804e348b03ce7b161 (commit)
   via  0b10b3ed6b3ee644a44414d8b5c205d94a967c12 (commit)
  from  154aa87ca6bd906b6422ad81f51161995c89cc14 (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=c867981c9d9bc8548d34f726940cd50b8d05d71c
commit c867981c9d9bc8548d34f726940cd50b8d05d71c
Merge: 1c84b5c86f 6dedb97420
Author: Brad King 
AuthorDate: Fri Oct 18 08:58:01 2019 -0400
Commit: Brad King 
CommitDate: Fri Oct 18 08:58:01 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c84b5c86f23d3e1998f67d0cd417b317cd9558b
commit 1c84b5c86f23d3e1998f67d0cd417b317cd9558b
Merge: 154aa87ca6 797689ab35
Author: Brad King 
AuthorDate: Fri Oct 18 12:57:06 2019 +
Commit: Kitware Robot 
CommitDate: Fri Oct 18 08:57:16 2019 -0400

Merge topic 'pch-makefile-depends'

797689ab35 PCH: Fix Makefile dependencies to rebuild PCH on header changes
0b10b3ed6b cmMakefileTargetGenerator: Inline WriteObjectBuildFile in only 
call site

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


---

Summary of changes:
 Source/cmMakefileTargetGenerator.cxx  | 27 +--
 Source/cmMakefileTargetGenerator.h|  5 -
 Tests/BuildDepends/CMakeLists.txt | 16 ++--
 Tests/BuildDepends/Project/CMakeLists.txt |  6 ++
 Tests/BuildDepends/Project/zot.cxx|  5 +++--
 Tests/BuildDepends/Project/zot_pch.cxx|  6 ++
 6 files changed, 38 insertions(+), 27 deletions(-)
 create mode 100644 Tests/BuildDepends/Project/zot_pch.cxx


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Help request for hierarchical directory example

2019-10-18 Thread David Aldrich

Hi Eric

Thanks very much for your answer. I understand now.

David

On Fri, Oct 18, 2019 at 12:57 PM Eric Noulard 
wrote:

>
>
> Le ven. 18 oct. 2019 à 12:53, David Aldrich 
> a écrit :
>
>> Hi
>>
>>
>>
>> I'm learning how to use hierarchical directories in CMake and am trying
>> to get an example to work that I saw on YouTube. The example isn't doing
>> what I expect so I would be grateful for some help in understanding why.
>>
>>
>>
>> I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
>>
>>
>>
>> I have a project called 'cmake-good' that should build library
>> 'libsay-hello.a' and executable 'cmake-good'.
>>
>>
>>
>> Here's the directory tree (excluding CMake artifacts which I don't think
>> I need to show):
>>
>>
>>
>> ├── CMakeLists.txt
>>
>> ├── build
>>
>> │   ├── CMakeCache.txt
>>
>> │   ├── CMakeFiles
>>
>> │   ├── Makefile
>>
>> │   ├── cmake_install.cmake
>>
>> │   ├── hello-exe
>>
>> │   │   ├── Makefile
>>
>> │   │   ├── cmake-good
>>
>> │   └── say-hello
>>
>> │   ├── Makefile
>>
>> │   └── libsay-hello.a
>>
>> ├── hello-exe
>>
>> │   ├── CMakeLists.txt
>>
>> │   └── main.cpp
>>
>> ├── say-hello
>>
>> ├── CMakeLists.txt
>>
>> └── src
>>
>> └── say-hello
>>
>> ├── hello.cpp
>>
>> └── hello.hpp
>>
>>
>>
>> Here are the CMakeLists.txt files:
>>
>>
>>
>> 1) Top level CMakeLists.txt:
>>
>>
>>
>> cmake_minimum_required(VERSION 3.10)
>>
>> project(MyProject VERSION 1.0.0)
>>
>> add_subdirectory(say-hello)
>>
>> add_subdirectory(hello-exe)
>>
>>
>>
>> 2) hello_exe/CMakeLists.txt:
>>
>>
>>
>> add_executable(cmake-good main.cpp )
>>
>> target_link_libraries(cmake-good PRIVATE say-hello)
>>
>>
>>
>> 3) say-hello/CMakeLists.txt:
>>
>>
>>
>> add_library(
>>
>> say-hello
>>
>> src/say-hello/hello.hpp
>>
>> src/say-hello/hello.cpp
>>
>> )
>>
>> target_include_directories(say-hello PUBLIC
>> "${CMAKE_CURRENT_SOURCE_DIR}/src")
>>
>>
>>
>> My problem is that I expect to see:
>>
>>
>>
>> hello-exe/cmake-good
>>
>> say-hello/libsay-hello.a
>>
>>
>>
>> but I see:
>>
>>
>>
>> build\hello-exe\cmake-good
>>
>> build\say-hello\libsay-hello.a
>>
>>
>>
>> Why is that?
>>
>
> Because build/ is your build directory and you apparently did an
> out-of-source build (which is good practice)
> see :
> https://gitlab.kitware.com/cmake/community/wikis/FAQ#out-of-source-build-trees
>
> You should have done something like:
>
> cd cmake-good/build
> cmake ..
> make
>
> In this case everything the build is generating (CMake artefact, build
> artefact etc...) gets written build/
> the directory hierarchy in build will have the same structure as your
> source tree.
>
> This is an expected behaviour.
>
>
>
> --
> 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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Help request for hierarchical directory example

2019-10-18 Thread Eric Noulard

Le ven. 18 oct. 2019 à 12:53, David Aldrich 
a écrit :

> Hi
>
>
>
> I'm learning how to use hierarchical directories in CMake and am trying to
> get an example to work that I saw on YouTube. The example isn't doing what
> I expect so I would be grateful for some help in understanding why.
>
>
>
> I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
>
>
>
> I have a project called 'cmake-good' that should build library
> 'libsay-hello.a' and executable 'cmake-good'.
>
>
>
> Here's the directory tree (excluding CMake artifacts which I don't think I
> need to show):
>
>
>
> ├── CMakeLists.txt
>
> ├── build
>
> │   ├── CMakeCache.txt
>
> │   ├── CMakeFiles
>
> │   ├── Makefile
>
> │   ├── cmake_install.cmake
>
> │   ├── hello-exe
>
> │   │   ├── Makefile
>
> │   │   ├── cmake-good
>
> │   └── say-hello
>
> │   ├── Makefile
>
> │   └── libsay-hello.a
>
> ├── hello-exe
>
> │   ├── CMakeLists.txt
>
> │   └── main.cpp
>
> ├── say-hello
>
> ├── CMakeLists.txt
>
> └── src
>
> └── say-hello
>
> ├── hello.cpp
>
> └── hello.hpp
>
>
>
> Here are the CMakeLists.txt files:
>
>
>
> 1) Top level CMakeLists.txt:
>
>
>
> cmake_minimum_required(VERSION 3.10)
>
> project(MyProject VERSION 1.0.0)
>
> add_subdirectory(say-hello)
>
> add_subdirectory(hello-exe)
>
>
>
> 2) hello_exe/CMakeLists.txt:
>
>
>
> add_executable(cmake-good main.cpp )
>
> target_link_libraries(cmake-good PRIVATE say-hello)
>
>
>
> 3) say-hello/CMakeLists.txt:
>
>
>
> add_library(
>
> say-hello
>
> src/say-hello/hello.hpp
>
> src/say-hello/hello.cpp
>
> )
>
> target_include_directories(say-hello PUBLIC
> "${CMAKE_CURRENT_SOURCE_DIR}/src")
>
>
>
> My problem is that I expect to see:
>
>
>
> hello-exe/cmake-good
>
> say-hello/libsay-hello.a
>
>
>
> but I see:
>
>
>
> build\hello-exe\cmake-good
>
> build\say-hello\libsay-hello.a
>
>
>
> Why is that?
>

Because build/ is your build directory and you apparently did an
out-of-source build (which is good practice)
see :
https://gitlab.kitware.com/cmake/community/wikis/FAQ#out-of-source-build-trees

You should have done something like:

cd cmake-good/build
cmake ..
make

In this case everything the build is generating (CMake artefact, build
artefact etc...) gets written build/
the directory hierarchy in build will have the same structure as your
source tree.

This is an expected behaviour.



-- 
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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Help request for hierarchical directory example

2019-10-18 Thread David Aldrich

Hi



I'm learning how to use hierarchical directories in CMake and am trying to
get an example to work that I saw on YouTube. The example isn't doing what
I expect so I would be grateful for some help in understanding why.



I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.



I have a project called 'cmake-good' that should build library
'libsay-hello.a' and executable 'cmake-good'.



Here's the directory tree (excluding CMake artifacts which I don't think I
need to show):



├── CMakeLists.txt

├── build

│   ├── CMakeCache.txt

│   ├── CMakeFiles

│   ├── Makefile

│   ├── cmake_install.cmake

│   ├── hello-exe

│   │   ├── Makefile

│   │   ├── cmake-good

│   └── say-hello

│   ├── Makefile

│   └── libsay-hello.a

├── hello-exe

│   ├── CMakeLists.txt

│   └── main.cpp

├── say-hello

├── CMakeLists.txt

└── src

└── say-hello

├── hello.cpp

└── hello.hpp



Here are the CMakeLists.txt files:



1) Top level CMakeLists.txt:



cmake_minimum_required(VERSION 3.10)

project(MyProject VERSION 1.0.0)

add_subdirectory(say-hello)

add_subdirectory(hello-exe)



2) hello_exe/CMakeLists.txt:



add_executable(cmake-good main.cpp )

target_link_libraries(cmake-good PRIVATE say-hello)



3) say-hello/CMakeLists.txt:



add_library(

say-hello

src/say-hello/hello.hpp

src/say-hello/hello.cpp

)

target_include_directories(say-hello PUBLIC
"${CMAKE_CURRENT_SOURCE_DIR}/src")



My problem is that I expect to see:



hello-exe/cmake-good

say-hello/libsay-hello.a



but I see:



build\hello-exe\cmake-good

build\say-hello\libsay-hello.a



Why is that?
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-121-g154aa87ca6

2019-10-17 Thread Kitware Robot via Cmake-commits

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  154aa87ca6bd906b6422ad81f51161995c89cc14 (commit)
  from  f6dac38c1120660c589b218e9d55cef190089dae (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=154aa87ca6bd906b6422ad81f51161995c89cc14
commit 154aa87ca6bd906b6422ad81f51161995c89cc14
Author: Kitware Robot 
AuthorDate: Fri Oct 18 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Fri Oct 18 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index c15eda7281..beeb0a6dac 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191017)
+set(CMake_VERSION_PATCH 20191018)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-45-g7aab792716

2019-10-17 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  7aab792716bb647aac2b5802e6e21148471a0c79 (commit)
   via  0e436c573c52add744f0ff7c8845be9c7ff381a0 (commit)
   via  84e14a52ff694b5fc28511bae68dbb1e39dde246 (commit)
   via  ac75886525c647ef7081dc11f6c0c128463b7ecd (commit)
  from  c2a7729177fa62a4a8eb3e2f7385f3f517c42f91 (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 -
---

Summary of changes:
 Help/command/target_precompile_headers.rst |  4 +++
 Source/cmExportFileGenerator.cxx   | 31 +-
 Source/cmExportFileGenerator.h |  8 +-
 Tests/ExportImport/Export/CMakeLists.txt   |  5 
 .../PrecompileHeaders/PchMultilanguage-check.cmake | 14 ++
 .../PrecompileHeaders/PchMultilanguage.cmake   |  5 +++-
 6 files changed, 52 insertions(+), 15 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-120-gf6dac38c11

2019-10-17 Thread Kitware Robot via Cmake-commits

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  f6dac38c1120660c589b218e9d55cef190089dae (commit)
   via  5417737fac3b6dce325a1e7b97267f974837da70 (commit)
   via  d61b8921acde5650dbe6d20ec7b77c6f7522c876 (commit)
   via  7aab792716bb647aac2b5802e6e21148471a0c79 (commit)
   via  84e14a52ff694b5fc28511bae68dbb1e39dde246 (commit)
   via  ac75886525c647ef7081dc11f6c0c128463b7ecd (commit)
   via  553658393c0e775efdec6b29b69c1274fb771e83 (commit)
  from  ea048ed66c488a57ff1fe4477e07b489bf235972 (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=f6dac38c1120660c589b218e9d55cef190089dae
commit f6dac38c1120660c589b218e9d55cef190089dae
Merge: 5417737fac 7aab792716
Author: Brad King 
AuthorDate: Thu Oct 17 13:55:23 2019 -0400
Commit: Brad King 
CommitDate: Thu Oct 17 13:55:23 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5417737fac3b6dce325a1e7b97267f974837da70
commit 5417737fac3b6dce325a1e7b97267f974837da70
Merge: d61b8921ac 553658393c
Author: Brad King 
AuthorDate: Thu Oct 17 17:54:11 2019 +
Commit: Kitware Robot 
CommitDate: Thu Oct 17 13:54:26 2019 -0400

Merge topic 'graphviz'

553658393c Graphviz: added test suite, fixes, enhancements

Acked-by: Kitware Robot 
Acked-by: slodki 
Merge-request: !3766


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d61b8921acde5650dbe6d20ec7b77c6f7522c876
commit d61b8921acde5650dbe6d20ec7b77c6f7522c876
Merge: ea048ed66c ac75886525
Author: Brad King 
AuthorDate: Thu Oct 17 17:52:28 2019 +
Commit: Kitware Robot 
CommitDate: Thu Oct 17 13:52:49 2019 -0400

Merge topic 'doc-pch-compile-language'

ac75886525 PCH: Document and test COMPILE_LANGUAGE genex for per-language 
header

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=553658393c0e775efdec6b29b69c1274fb771e83
commit 553658393c0e775efdec6b29b69c1274fb771e83
Author: Corentin Plouet 
AuthorDate: Tue Oct 8 13:45:30 2019 +1100
Commit: Corentin Plouet 
CommitDate: Tue Oct 8 13:45:56 2019 +1100

Graphviz: added test suite, fixes, enhancements

* Added a fairly comprehensive test suite
* Separated the graph traversal logic from the Graphviz generation
  code by introducing a new class, cmLinkItemsGraphVisitor{.h,cxx}
* Made the graph traversal logic less ad-hoc by using existing
  methods in the GlobalGenerator; this fixed a few bugs
* Added support for new target types: custom targets, object
  and unknown libraries
* Improved support for ALIAS libraries by showing the alias(es)
  in the graph
* Introduced new flags to control those new libraries (consistent
  with existing flags)
* Updated the documentation
* Removed useless setting to set graph type in dot file
* Improved the node/edge shapes (nicer, more consistent)
* Added a legend to the graph
* Some refactoring and cleanup of the Graphviz generation code
* Added test and fix for issue 19746

diff --git a/Modules/CMakeGraphVizOptions.cmake 
b/Modules/CMakeGraphVizOptions.cmake
index 1911e7392e..be4a3be365 100644
--- a/Modules/CMakeGraphVizOptions.cmake
+++ b/Modules/CMakeGraphVizOptions.cmake
@@ -5,119 +5,145 @@
 CMakeGraphVizOptions
 
 
-The builtin graphviz support of CMake.
+The builtin Graphviz support of CMake.
 
-Variables specific to the graphviz support
-^^
+Generating Graphviz files
+^
 
-CMake
-can generate `graphviz `_ files, showing the 
dependencies between the
-targets in a project and also external libraries which are linked
-against.  When CMake is run with the ``--graphviz=foo.dot`` option, it will
-produce:
+CMake can generate `Graphviz `_ files showing the
+dependencies between the targets in a project, as well as external libraries
+which are linked against.
 
-* a ``foo.dot`` file showing all dependencies in the project
-* a ``foo.dot.`` file for each target, file showing on which other 
targets the respective target depends
-* a ``foo.dot..dependers`` file, showing which other targets depend on 
the respective target
+When running CMake with the ``--graphviz=foo.dot`` option, it produces:
 
-The different dependency types ``PUBLIC``, ``PRIVATE`` and ``INTERFACE``
-are represented as solid, dashed and dotted edges.
+* a ``foo.dot`` file, showing all dependencies in the project
+* a ``foo.dot.`` file for each target, showing

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-113-gea048ed66c

2019-10-17 Thread Kitware Robot via Cmake-commits

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  ea048ed66c488a57ff1fe4477e07b489bf235972 (commit)
   via  b903092b31389e21ff74dfccd4cbd7d9deeb7c22 (commit)
   via  0e436c573c52add744f0ff7c8845be9c7ff381a0 (commit)
   via  89ff3ee779f54e982e96b21b7d370371e639cc6f (commit)
  from  095fc6d9d96bf9f12770f85ebf0b75d384a7d5fb (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=ea048ed66c488a57ff1fe4477e07b489bf235972
commit ea048ed66c488a57ff1fe4477e07b489bf235972
Merge: b903092b31 0e436c573c
Author: Brad King 
AuthorDate: Thu Oct 17 17:51:33 2019 +
Commit: Kitware Robot 
CommitDate: Thu Oct 17 13:52:00 2019 -0400

Merge topic 'export-target-lang-name'

0e436c573c install,export: Do not treat language names as target names

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b903092b31389e21ff74dfccd4cbd7d9deeb7c22
commit b903092b31389e21ff74dfccd4cbd7d9deeb7c22
Merge: 095fc6d9d9 89ff3ee779
Author: Brad King 
AuthorDate: Thu Oct 17 17:51:00 2019 +
Commit: Kitware Robot 
CommitDate: Thu Oct 17 13:51:11 2019 -0400

Merge topic 'vs_dotnet_documentation_file'

89ff3ee779 VS: Add VS_DOTNET_DOCUMENTATION_FILE property

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e436c573c52add744f0ff7c8845be9c7ff381a0
commit 0e436c573c52add744f0ff7c8845be9c7ff381a0
Author: Brad King 
AuthorDate: Wed Oct 16 12:03:41 2019 -0400
Commit: Brad King 
CommitDate: Wed Oct 16 12:48:20 2019 -0400

install,export: Do not treat language names as target names

When generating `IMPORTED_LINK_INTERFACE_LANGUAGES`, do not treat the
entries as target names.

Fixes: #19846

diff --git a/Source/cmExportFileGenerator.cxx b/Source/cmExportFileGenerator.cxx
index 3d7eccc315..aeef602bf6 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -752,9 +752,9 @@ void cmExportFileGenerator::SetImportLinkInterface(
 
   if (iface->ImplementationIsInterface) {
 // Policy CMP0022 must not be NEW.
-this->SetImportLinkProperty(suffix, target,
-"IMPORTED_LINK_INTERFACE_LIBRARIES",
-iface->Libraries, properties, missingTargets);
+this->SetImportLinkProperty(
+  suffix, target, "IMPORTED_LINK_INTERFACE_LIBRARIES", iface->Libraries,
+  properties, missingTargets, ImportLinkPropertyTargetNames::Yes);
 return;
   }
 
@@ -832,14 +832,14 @@ void cmExportFileGenerator::SetImportDetailProperties(
   // Add the transitive link dependencies for this configuration.
   if (cmLinkInterface const* iface =
 target->GetLinkInterface(config, target)) {
-this->SetImportLinkProperty(suffix, target,
-"IMPORTED_LINK_INTERFACE_LANGUAGES",
-iface->Languages, properties, missingTargets);
+this->SetImportLinkProperty(
+  suffix, target, "IMPORTED_LINK_INTERFACE_LANGUAGES", iface->Languages,
+  properties, missingTargets, ImportLinkPropertyTargetNames::No);
 
 std::vector dummy;
-this->SetImportLinkProperty(suffix, target,
-"IMPORTED_LINK_DEPENDENT_LIBRARIES",
-iface->SharedDeps, properties, dummy);
+this->SetImportLinkProperty(
+  suffix, target, "IMPORTED_LINK_DEPENDENT_LIBRARIES", iface->SharedDeps,
+  properties, dummy, ImportLinkPropertyTargetNames::Yes);
 if (iface->Multiplicity > 0) {
   std::string prop =
 cmStrCat("IMPORTED_LINK_INTERFACE_MULTIPLICITY", suffix);
@@ -880,7 +880,8 @@ template 
 void cmExportFileGenerator::SetImportLinkProperty(
   std::string const& suffix, cmGeneratorTarget* target,
   const std::string& propName, std::vector const& entries,
-  ImportPropertyMap& properties, std::vector& missingTargets)
+  ImportPropertyMap& properties, std::vector& missingTargets,
+  ImportLinkPropertyTargetNames targetNames)
 {
   // Skip the property if there are no entries.
   if (entries.empty()) {
@@ -895,9 +896,13 @@ void cmExportFileGenerator::SetImportLinkProperty(
 link_entries += sep;
 sep = ";";
 
-std::string temp = asString(l);
-this->AddTargetNamespace(temp, target, missingTargets);
-link_entries += temp;
+if (targetNames == ImportLinkPropertyTargetNames::Yes) {
+  std::string temp = asString(l);
+  this->AddTargetNamespace(temp, target, missingTargets);
+  link_entries += temp;
+} else {
+  link_entries +=

Re: [CMake] error executing script with cmake -P

2019-10-17 Thread Tom Finegan via CMake

On Thu, Oct 17, 2019 at 2:14 AM Edoardo Pasca  wrote:

> Hi Tom,
>
> I thought ${testdata} was going to be filled in by the actual
> patch_script.cmake at this line.
>
> file (STRINGS TestData.py testdata NEWLINE_CONSUME)
>

Sorry, some nasty formatting in my email client had me misreading your
script. My advice is mainly based on this error:

  CMake Error at build/patch_script.cmake:3 (string):
string sub-command REPLACE requires at least four arguments

Looking at this line:
string(REPLACE \"sys.prefix\" \"os.environ[\\\'SIRF_INSTALL_PATH\\\']\"
patched \${testdata})

The most likely possible reason for that error being reported by CMake is
that ${testdata} is not defined when that line of script is executed. What
does line 3 of patch_script.cmake look like immediately after the error
message is output? My guess is that it looks something like this:

  string(REPLACE "sys.prefix" "os.environ[\'SIRF_INSTALL_PATH\']" patched )

As you'll notice REPLACE is only receiving 3 args in the above version.

Also note: I don't think you need to escape the single quotes in the
os.environ argument (unless they must be escaped in the final output).
Basic toy scripts here show it as unnecessary unless they must be escaped
in the patched file.

>
>  So it appears that this command doesn't quite work.
>
> I'll try also Alan's suggestion.
>
> Thanks
>
> Edo
>
> On Tue, Oct 15, 2019 at 7:00 PM Tom Finegan  wrote:
>
>> It looks like you aren't passing the $testdata variable down to the
>> script. From your message it looks like you need to add the following to
>> your PATCH_COMMAND:
>>
>> -Dtestdata=${testdata}
>>
>> You must explicitly pass $testdata (and any other variables defined in
>> the calling script) to patch_script.cmake via -D parameters on the command
>> line. Also note that the -Dvar=value args must precede the -P

Re: [CMake] error executing script with cmake -P

2019-10-17 Thread Edoardo Pasca

Hi Tom,

I thought ${testdata} was going to be filled in by the actual
patch_script.cmake at this line.

file (STRINGS TestData.py testdata NEWLINE_CONSUME)

 So it appears that this command doesn't quite work.

I'll try also Alan's suggestion.

Thanks

Edo

On Tue, Oct 15, 2019 at 7:00 PM Tom Finegan  wrote:

> It looks like you aren't passing the $testdata variable down to the
> script. From your message it looks like you need to add the following to
> your PATCH_COMMAND:
>
> -Dtestdata=${testdata}
>
> You must explicitly pass $testdata (and any other variables defined in the
> calling script) to patch_script.cmake via -D parameters on the command
> line. Also note that the -Dvar=value args must precede the -P

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-109-g095fc6d9d9

2019-10-16 Thread Kitware Robot via Cmake-commits

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  095fc6d9d96bf9f12770f85ebf0b75d384a7d5fb (commit)
  from  e60412b63ed4665559c89e4f39a71973dd41a61a (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=095fc6d9d96bf9f12770f85ebf0b75d384a7d5fb
commit 095fc6d9d96bf9f12770f85ebf0b75d384a7d5fb
Author: Kitware Robot 
AuthorDate: Thu Oct 17 00:01:09 2019 -0400
Commit: Kitware Robot 
CommitDate: Thu Oct 17 00:01:09 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4edadd8e06..c15eda7281 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191016)
+set(CMake_VERSION_PATCH 20191017)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-41-gc2a7729

2019-10-16 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  c2a7729177fa62a4a8eb3e2f7385f3f517c42f91 (commit)
   via  a7ef28b9d8b30b7d5249ade425a9cd2e267da68c (commit)
  from  3658f4425a8ba10761682b5db323ab45650f230b (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 -
---

Summary of changes:
 Help/command/LINK_OPTIONS_LINKER.txt | 18 +-
 Help/command/OPTIONS_SHELL.txt   |  4 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-108-ge60412b

2019-10-16 Thread Kitware Robot via Cmake-commits

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  e60412b63ed4665559c89e4f39a71973dd41a61a (commit)
   via  4116d5104e9b4aa5ad5ce8ab412d2230a6a62dbf (commit)
   via  c2a7729177fa62a4a8eb3e2f7385f3f517c42f91 (commit)
   via  a7ef28b9d8b30b7d5249ade425a9cd2e267da68c (commit)
  from  96a93a7f6436681d1d196de84b95ad38d88a8aaa (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=e60412b63ed4665559c89e4f39a71973dd41a61a
commit e60412b63ed4665559c89e4f39a71973dd41a61a
Merge: 4116d51 c2a7729
Author: Brad King 
AuthorDate: Wed Oct 16 10:24:00 2019 -0400
Commit: Brad King 
CommitDate: Wed Oct 16 10:24:00 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4116d5104e9b4aa5ad5ce8ab412d2230a6a62dbf
commit 4116d5104e9b4aa5ad5ce8ab412d2230a6a62dbf
Merge: 96a93a7 a7ef28b
Author: Brad King 
AuthorDate: Wed Oct 16 14:23:12 2019 +
Commit: Kitware Robot 
CommitDate: Wed Oct 16 10:23:22 2019 -0400

Merge topic 'doc-add_link_options-typos'

a7ef28b9d8 Help: Fix typos and style in add_link_options documentation

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


---

Summary of changes:
 Help/command/LINK_OPTIONS_LINKER.txt | 18 +-
 Help/command/OPTIONS_SHELL.txt   |  4 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [cmake-developers] CTest load balancing

2019-10-16 Thread Brad King via cmake-developers

On 10/16/19 10:05 AM, Wouter Klouwen wrote:
> Is the intent for CTest to specifically manage CPU load or system load
> overall?

I don't think a careful distinction was made at the time.

If Linux needs some updates to be consistent with other platforms
then that would be fine with me.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] CTest load balancing

2019-10-16 Thread Wouter Klouwen

Hi all,

CTest has a very useful feature that performs load balancing. This works
by comparing the current system load to a target load.

The current implementation defers to
SystemInformationImplementation::GetLoadAverage() to return a value.
This is implemented on the platforms that have getloadavg() by returning
the first value of that.

While this function is present on many UNIX platforms, on Linux it means
something slightly different than on say Solaris and *BSD. Namely on the
former it is representing a "system load" and on the latter it is "CPU
load", which is a subtle but rather important distinction.

The system load includes processes which are in the uninterruptable
state on purpose, a rather interesting blog post by Brendan Gregg has
some juicy details:
http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

Now, this has recently become a problem for us, as on some of our
systems there are some kernel level processes active that by design are
in the uninterruptable state, therefore contributing to the system load
average, even if they do not affect the CPU load of the system. The
number of processes in this state can easily outnumber the number of
cores (i.e. 11 uninterruptable processes vs 4 CPU threads). So an idle
system can have a load of > 10, for instance.

At present we are working around this by setting a higher load to manage
the tests, this as you might imagine is not a perfect solution as the
number of uninterruptable processes does vary over time.

The implementation of this feature specifically mentions checking for
CPU load, which to be consistent on all platforms would require checking
slightly different details on Linux.

Is the intent for CTest to specifically manage CPU load or system load
overall? The original commit message and comments point more towards the
former. The Windows implementation of GetLoadAverage() also points
towards merely CPU load.

A Linux specific implementation would have to, most likely, investigate
/proc/stat and derive a CPU load from that.

Any ideas/suggestions?

Thanks,
W

This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-104-g96a93a7

2019-10-16 Thread Kitware Robot via Cmake-commits

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  96a93a7f6436681d1d196de84b95ad38d88a8aaa (commit)
   via  3658f4425a8ba10761682b5db323ab45650f230b (commit)
   via  080163a6574c6fcdcdb1b194dbd85778ff5a0b66 (commit)
   via  c3c751e9ddb06702c9a046ab2c0eda12750d09ed (commit)
   via  c89794feaeec7c7acd22caee9c20252bfc7b33d9 (commit)
  from  0e5a3ae7a9161628ff0de65a31cc1a870803fc17 (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=96a93a7f6436681d1d196de84b95ad38d88a8aaa
commit 96a93a7f6436681d1d196de84b95ad38d88a8aaa
Merge: 0e5a3ae 3658f44
Author: Brad King 
AuthorDate: Wed Oct 16 09:53:14 2019 -0400
Commit: Brad King 
CommitDate: Wed Oct 16 09:53:14 2019 -0400

Merge branch 'release-3.16'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-39-g3658f44

2019-10-16 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  3658f4425a8ba10761682b5db323ab45650f230b (commit)
   via  466ad466b44561c8d48360fed0e491b3c09313be (commit)
   via  080163a6574c6fcdcdb1b194dbd85778ff5a0b66 (commit)
   via  c3c751e9ddb06702c9a046ab2c0eda12750d09ed (commit)
   via  c89794feaeec7c7acd22caee9c20252bfc7b33d9 (commit)
   via  f0da223ff0ddd2b1dcc5112d7df920b23515cbd3 (commit)
   via  9fc87ef2e712eda340457811a1e1ac0af3e70bb5 (commit)
   via  08f4b5dcf9243754a3b6f88fc61d0c99578b08f6 (commit)
   via  cd6f0ef35a9a7669e95219684f3a8398932a1b4d (commit)
  from  4041f6a3273f5638c28c7c9ff48f0326088531c7 (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 -
---

Summary of changes:
 Modules/CMakeFindBinUtils.cmake | 12 
 Modules/FindCurses.cmake|  6 --
 Modules/FindHDF5.cmake  |  4 ++--
 Source/cmCoreTryCompile.cxx |  3 +++
 4 files changed, 9 insertions(+), 16 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-99-g0e5a3ae

2019-10-16 Thread Kitware Robot via Cmake-commits

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  0e5a3ae7a9161628ff0de65a31cc1a870803fc17 (commit)
   via  93b80638ce9d034e9574c526aa5378ea4fc8801e (commit)
   via  e0e109611a7c22ea4fe80cac38ba495ec19d1e07 (commit)
   via  4abdb1900aa47d714633f8ec9576d76781ee2f79 (commit)
   via  2e133ca30b46d0d189d4ced92d2794e2fccf78db (commit)
   via  c11e7c5c3d5c5e682adf761c4b0de734ff68e690 (commit)
   via  466ad466b44561c8d48360fed0e491b3c09313be (commit)
   via  f0da223ff0ddd2b1dcc5112d7df920b23515cbd3 (commit)
   via  9fc87ef2e712eda340457811a1e1ac0af3e70bb5 (commit)
   via  08f4b5dcf9243754a3b6f88fc61d0c99578b08f6 (commit)
   via  cd6f0ef35a9a7669e95219684f3a8398932a1b4d (commit)
  from  220d5995076f794e222c882963fb634169a6600b (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=0e5a3ae7a9161628ff0de65a31cc1a870803fc17
commit 0e5a3ae7a9161628ff0de65a31cc1a870803fc17
Merge: 93b8063 c11e7c5
Author: Brad King 
AuthorDate: Wed Oct 16 13:51:24 2019 +
Commit: Kitware Robot 
CommitDate: Wed Oct 16 09:51:32 2019 -0400

Merge topic 'FindCURL-cmake-package'

c11e7c5c3d FindCURL: Try to find CURLConfig.cmake

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93b80638ce9d034e9574c526aa5378ea4fc8801e
commit 93b80638ce9d034e9574c526aa5378ea4fc8801e
Merge: e0e1096 f0da223
Author: Brad King 
AuthorDate: Wed Oct 16 13:43:16 2019 +
Commit: Kitware Robot 
CommitDate: Wed Oct 16 09:45:59 2019 -0400

Merge topic 'CMakeFindBinUtils-cleanup'

f0da223ff0 CMakeFindBinUtils: Remove unnecessary variable unset calls

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e0e109611a7c22ea4fe80cac38ba495ec19d1e07
commit e0e109611a7c22ea4fe80cac38ba495ec19d1e07
Merge: 4abdb19 466ad46
Author: Brad King 
AuthorDate: Wed Oct 16 13:43:26 2019 +
Commit: Kitware Robot 
CommitDate: Wed Oct 16 09:45:11 2019 -0400

Merge topic 'swift-cross-compile'

466ad466b4 try_compile: support Swift for cross-compilation

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4abdb1900aa47d714633f8ec9576d76781ee2f79
commit 4abdb1900aa47d714633f8ec9576d76781ee2f79
Merge: 2e133ca 9fc87ef
Author: Brad King 
AuthorDate: Wed Oct 16 13:43:11 2019 +
Commit: Kitware Robot 
CommitDate: Wed Oct 16 09:44:08 2019 -0400

Merge topic 'FindCurses-tinfow'

9fc87ef2e7 FindCurses: use tinfow when wide support is requested

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e133ca30b46d0d189d4ced92d2794e2fccf78db
commit 2e133ca30b46d0d189d4ced92d2794e2fccf78db
Merge: 220d599 08f4b5d
Author: Brad King 
AuthorDate: Wed Oct 16 13:43:04 2019 +
Commit: Kitware Robot 
CommitDate: Wed Oct 16 09:43:12 2019 -0400

Merge topic 'FindHDF5-cray'

08f4b5dcf9 FindHDF5: Append hdf5 to hdf5_hl to avoid undefined references
cd6f0ef35a FindHDF5: Cray HDF5 Fortran module filename is usually 
capitalized

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c11e7c5c3d5c5e682adf761c4b0de734ff68e690
commit c11e7c5c3d5c5e682adf761c4b0de734ff68e690
Author: Charles Barto 
AuthorDate: Thu Oct 10 16:29:00 2019 -0700
Commit: Brad King 
CommitDate: Tue Oct 15 13:56:28 2019 -0400

FindCURL: Try to find CURLConfig.cmake

diff --git a/Help/release/dev/FindCURL-cmake-package.rst 
b/Help/release/dev/FindCURL-cmake-package.rst
new file mode 100644
index 000..67c5bbc
--- /dev/null
+++ b/Help/release/dev/FindCURL-cmake-package.rst
@@ -0,0 +1,7 @@
+FindCURL-cmake-package
+--
+
+* The :module:`FindCURL` module learned to find CURL using
+  the ``CURLConfig.cmake`` package configuration file generated by
+  CURL's cmake buildsystem.  It also gained a new ``CURL_NO_CURL_CMAKE``
+  option to disable this behavior.
diff --git a/Modules/FindCURL.cmake b/Modules/FindCURL.cmake
index aeebc84..919babc 100644
--- a/Modules/FindCURL.cmake
+++ b/Modules/FindCURL.cmake
@@ -37,8 +37,35 @@ This module defines the following variables:
 
 ``CURL_VERSION_STRING``
   The version of ``curl`` found.
+
+CURL CMake
+^^
+
+If CURL was built using the CMake buildsystem then it provides its own
+``CURLConfig.cmake`` file for use with the :command:`find_package` command's
+config mode. This module looks for this file and, if found,
+returns its results

Re: [CMake] using `install()` with EXPORT and COMPONENT

2019-10-16 Thread Craig Scott

On Mon, Sep 30, 2019 at 4:09 AM Stefan Seefeld  wrote:

> Hi Craig,
>
> thanks for the detailed explanation !
> On 2019-09-29 5:13 a.m., Craig Scott wrote:
>
>
> If all of your headers should be installed to a single directory, then you
> can list the headers in the target's PUBLIC_HEADER or PRIVATE_HEADER target
> property, then make sure you add those destinations in the install(TARGETS
> ...) command. For example:
>
> include(GNUInstallDirs)
> install(TARGETS myLib
> EXPORT SomeProj_Targets
> RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
> COMPONENT SomeProj_Runtime
> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> COMPONENT  SomeProj_Runtime
> NAMELINK_COMPONENT SomeProj_Development   # Requires CMake 3.12
> ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
> COMPONENT SomeProj_Development
> PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> COMPONENT SomeProj_Development
> INCLUDES DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
> )
>
> I hadn't noticed one can have multiple 'COMPONENT' sections in a single
> `install` call. The CMake documentation could be a bit more clear about
> that.
>
>
> If you need to install headers into more than one directory (i.e. your
> headers have some sort of directory hierarchy), then the above doesn't work
> because it flattens all of the headers into a single location. Instead, you
> have to use install(FILES ...) to install the headers directly for such
> cases. Also, the target_include_directories() command has nothing to do
> with what header files get installed. Rather, it only controls the header
> search paths attached to a target.
>
> Right, true.
>
> FYI, part of my CppCon talk "Deep CMake For Library Authors" from a couple
> of weeks ago has a fair amount of overlap with this topic (specifically
> install components and destinations). I'm waiting for the YouTube clip to
> be made available and then I'll be posting a blog article on my website
> with links and the slides. When it goes up, you'll be able to find it at
> https://crascit.com (hopefully sometime this week, but depends how
> quickly the production people get the video done).
>
> Great, looking forward to reading the slides.
>

The CppCon talk and slides are now available. You can find them here:

https://crascit.com/2019/10/16/cppcon-2019-deep-cmake-for-library-authors/

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-88-g220d599

2019-10-15 Thread Kitware Robot via Cmake-commits

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  220d5995076f794e222c882963fb634169a6600b (commit)
  from  60509518124e715994900afa88530558b248510c (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=220d5995076f794e222c882963fb634169a6600b
commit 220d5995076f794e222c882963fb634169a6600b
Author: Kitware Robot 
AuthorDate: Wed Oct 16 00:01:08 2019 -0400
Commit: Kitware Robot 
CommitDate: Wed Oct 16 00:01:08 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 458cc86..4edadd8 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191015)
+set(CMake_VERSION_PATCH 20191016)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] error executing script with cmake -P

2019-10-15 Thread Alan W. Irwin


On 2019-10-14 12:00+0100 Edoardo Pasca wrote:


Dear all,

I am using external project. I would like to patch a source file. I came
out with a cmake script that does the string replacement I'm interested in.

I tested in a standalone project, with the following CMakeLists.txt

cmake_minimum_required(VERSION 3.4)
project(patching_string)
file (STRINGS TestData.py testdata NEWLINE_CONSUME)
string(REPLACE "sys.prefix" "os.environ[\'SIRF_INSTALL_PATH\']" patched
${testdata})
file( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/TestData.py ${patched} )

and as a matter of facts this does the string replacement I'm interested in.

Good, now I would like to use this to the project I'm really interested in
which uses the ExternalProject_Add machinery. I added the patch step:



file (WRITE ${CMAKE_BINARY_DIR}/patch_script.cmake "
file (STRINGS
${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py testdata
NEWLINE_CONSUME)
string(REPLACE \"sys.prefix\" \"os.environ[\\\'SIRF_INSTALL_PATH\\\']\"
patched \${testdata})
file( WRITE
${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py
\${patched} ) ")
ExternalProject_Add(
...

PATCH_COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/patch_script.cmake

... )



Notice that I write the patch_script.cmake before the ExternalProject_Add


Now, all of this WORKS. Or at least I get the patch_script.cmake file in
the proper directoty, with the content I want. However, execution with
cmake -P patch_script.cmake doesn't work as expected.

I get
CMake Error at build/patch_script.cmake:3 (string):
 string sub-command REPLACE requires at least four arguments.

Given that the patch_script.cmake has the same content of the standalone
CMakeLists.txt above (without the first 2 lines), I don't know where things
don't go well, except that I execute the script with cmake -P

cmake version 3.15.2

Thanks for any help.


Hi Edo:

This help likely belongs to the "any" category.  :-)  That is, it is just a 
informed suggestion
that might help you but nothing definite.

It sounds to me from the research you reported above that you have an 
absolutely clear case where
standalone cmake operating on CMake logic contained in a file (with

cmake_minimum_required(VERSION 3.4)
project(patching_string)

prepended so standalone CMake works fine, but cmake -P operating on *that same 
file* does
not work.  I suggest you prepare a test tarball containing a file which contains
the CMake logic executed by cmake -P (i.e., all but the first two lines of the 
above
CMakeLists.txt file),
and the original TestData.py file that logic is supposed to work on.  That 
simple test
case should help others here (likely not me) replicate the issue you have found 
and
explain why it occurs for cmake -P but not for the standalone cmake case (with 
the two
lines prepended, separate build tree, etc., so standalone works).

N.B. Also note that even before that difference is confirmed and
explained, you have the option of either fixing the logic in the cmake
-P case (where the cmake options --debug-output and --trace-expand
might help you figure out exactly what the problem is) or else
adopting the current (prepended) logic for the standalone case and
executing that (rather clumsy, of course) standalone method in your
super-project.

Good luck, and I hope this overview of how I would deal with the
issue you have described is a help to you.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] error executing script with cmake -P

2019-10-15 Thread Tom Finegan via CMake

It looks like you aren't passing the $testdata variable down to the script.
>From your message it looks like you need to add the following to your
PATCH_COMMAND:

-Dtestdata=${testdata}

You must explicitly pass $testdata (and any other variables defined in the
calling script) to patch_script.cmake via -D parameters on the command
line. Also note that the -Dvar=value args must precede the -P

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-87-g6050951

2019-10-15 Thread Kitware Robot via Cmake-commits

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  60509518124e715994900afa88530558b248510c (commit)
   via  cdc8d75c495b4a7c8151b0aca1f6ceb515d9135e (commit)
   via  4041f6a3273f5638c28c7c9ff48f0326088531c7 (commit)
   via  dc164bccc1a5c3e3e20b8c4c1ee655e9d83d5779 (commit)
   via  e14518ec4507b008a4a1b842bb14a8587aacf055 (commit)
   via  fb16e0e7c05c9c227f6fb2a6ec5dbcae95b12880 (commit)
   via  7716be4561505118bee90d54357f83f37092b53f (commit)
   via  74035b0ad4eb2eccf6537d6348afeb5d63222b5d (commit)
   via  c9d73b26b0a78fac774a549de41eee55ed4e8d7b (commit)
   via  db5a8d78761e59d43db2b463a8f8aaa5e7d2be48 (commit)
  from  daf6a6ba68a6fa1c5d1956f151104d903f3447cc (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=60509518124e715994900afa88530558b248510c
commit 60509518124e715994900afa88530558b248510c
Merge: cdc8d75 4041f6a
Author: Brad King 
AuthorDate: Tue Oct 15 11:18:51 2019 -0400
Commit: Brad King 
CommitDate: Tue Oct 15 11:18:51 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdc8d75c495b4a7c8151b0aca1f6ceb515d9135e
commit cdc8d75c495b4a7c8151b0aca1f6ceb515d9135e
Merge: dc164bc fb16e0e
Author: Brad King 
AuthorDate: Tue Oct 15 15:16:55 2019 +
Commit: Kitware Robot 
CommitDate: Tue Oct 15 11:17:03 2019 -0400

Merge topic 'doc-static-lib-flags'

fb16e0e7c0 Help: Clarify documentation of CMAKE_STATIC_LINKER_FLAGS

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc164bccc1a5c3e3e20b8c4c1ee655e9d83d5779
commit dc164bccc1a5c3e3e20b8c4c1ee655e9d83d5779
Merge: e14518e c9d73b2
Author: Brad King 
AuthorDate: Tue Oct 15 15:13:12 2019 +
Commit: Kitware Robot 
CommitDate: Tue Oct 15 11:14:09 2019 -0400

Merge topic 'cmake-initial-cache-relative'

c9d73b26b0 cmake: Fix relative path regression in -C

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e14518ec4507b008a4a1b842bb14a8587aacf055
commit e14518ec4507b008a4a1b842bb14a8587aacf055
Merge: daf6a6b db5a8d7
Author: Brad King 
AuthorDate: Tue Oct 15 15:13:02 2019 +
Commit: Kitware Robot 
CommitDate: Tue Oct 15 11:13:10 2019 -0400

Merge topic 'FindOpenMP-clang-HIP-device'

db5a8d7876 FindOpenMP: Add support for HIP clang device pass

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


---

Summary of changes:
 Help/variable/CMAKE_STATIC_LINKER_FLAGS.rst   | 10 --
 Help/variable/CMAKE_STATIC_LINKER_FLAGS_CONFIG.rst| 12 +---
 Modules/FindOpenMP.cmake  |  2 ++
 Source/cmake.cxx  |  2 ++
 Tests/RunCMake/CommandLine/C-no-file-stderr.txt   |  2 +-
 Tests/RunCMake/CommandLine/C_basic-stderr.txt |  4 
 Tests/RunCMake/CommandLine/C_basic-stdout.txt |  1 +
 Tests/RunCMake/CommandLine/C_basic.cmake  |  2 ++
 Tests/RunCMake/CommandLine/C_basic_fullpath-stderr.txt|  4 
 Tests/RunCMake/CommandLine/C_basic_fullpath-stdout.txt|  1 +
 Tests/RunCMake/CommandLine/C_basic_fullpath.cmake |  2 ++
 .../initial-cache.txt => C_basic_initial-cache.txt}   |  1 -
 Tests/RunCMake/CommandLine/C_buildsrcdir-stderr.txt   |  8 
 Tests/RunCMake/CommandLine/C_buildsrcdir-stdout.txt   |  2 +-
 Tests/RunCMake/CommandLine/Cno-file-stderr.txt|  2 +-
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 15 ---
 16 files changed, 54 insertions(+), 16 deletions(-)
 create mode 100644 Tests/RunCMake/CommandLine/C_basic-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic-stdout.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic.cmake
 create mode 100644 Tests/RunCMake/CommandLine/C_basic_fullpath-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic_fullpath-stdout.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic_fullpath.cmake
 copy Tests/RunCMake/CommandLine/{C_buildsrcdir/initial-cache.txt => 
C_basic_initial-cache.txt} (76%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-30-g4041f6a

2019-10-15 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  4041f6a3273f5638c28c7c9ff48f0326088531c7 (commit)
   via  fb16e0e7c05c9c227f6fb2a6ec5dbcae95b12880 (commit)
   via  7716be4561505118bee90d54357f83f37092b53f (commit)
   via  74035b0ad4eb2eccf6537d6348afeb5d63222b5d (commit)
   via  c9d73b26b0a78fac774a549de41eee55ed4e8d7b (commit)
   via  db5a8d78761e59d43db2b463a8f8aaa5e7d2be48 (commit)
  from  6847d81856be2337d24d4db04fc3d23f43122c82 (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 -
---

Summary of changes:
 Help/variable/CMAKE_STATIC_LINKER_FLAGS.rst   | 10 --
 Help/variable/CMAKE_STATIC_LINKER_FLAGS_CONFIG.rst| 12 +---
 Modules/FindOpenMP.cmake  |  2 ++
 Source/cmake.cxx  |  2 ++
 Tests/RunCMake/CommandLine/C-no-file-stderr.txt   |  2 +-
 Tests/RunCMake/CommandLine/C_basic-stderr.txt |  4 
 Tests/RunCMake/CommandLine/C_basic-stdout.txt |  1 +
 Tests/RunCMake/CommandLine/C_basic.cmake  |  2 ++
 Tests/RunCMake/CommandLine/C_basic_fullpath-stderr.txt|  4 
 Tests/RunCMake/CommandLine/C_basic_fullpath-stdout.txt|  1 +
 Tests/RunCMake/CommandLine/C_basic_fullpath.cmake |  2 ++
 .../initial-cache.txt => C_basic_initial-cache.txt}   |  1 -
 Tests/RunCMake/CommandLine/C_buildsrcdir-stderr.txt   |  8 
 Tests/RunCMake/CommandLine/C_buildsrcdir-stdout.txt   |  2 +-
 Tests/RunCMake/CommandLine/Cno-file-stderr.txt|  2 +-
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 15 ---
 16 files changed, 54 insertions(+), 16 deletions(-)
 create mode 100644 Tests/RunCMake/CommandLine/C_basic-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic-stdout.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic.cmake
 create mode 100644 Tests/RunCMake/CommandLine/C_basic_fullpath-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic_fullpath-stdout.txt
 create mode 100644 Tests/RunCMake/CommandLine/C_basic_fullpath.cmake
 copy Tests/RunCMake/CommandLine/{C_buildsrcdir/initial-cache.txt => 
C_basic_initial-cache.txt} (76%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Can I use a *Targets-someName.cmake file to get access to _IMPORT_PREFIX ?

2019-10-15 Thread Daniel Oertwig

TL;DR:

 - For a project thing I get thingTargets.cmake when I install EXPORT it
 - thingTargets.cmake sets _IMPORT_PREFIX
 - thingTargets.cmake loads files thingTargets-*.cmake

Can I create and install thingTargets-someName.cmake which uses
_IMPORT_PREFIX to "hook" into above mechanism? Or is this likely to break /
change in the future?

Longer version:

I really like that you can use the exported targets of cmake even when
still in a staging directory and not installed. Example:

# in thing project
mkdir thing-build; cd thing-build
cmake .. -DCMAKE_INSTALL_PREFIX=""
make
# creates /path/to/staging/lib/cmake/thing/lib{Config,Targets}.cmake and
friends
make install DESTDIR=/path/to/staging

# in user project
mkdir user-build
cmake .. -Dthing_DIR=/path/to/staging/lib/cmake/thing
make # correctly uses libraries and headers from /path/to/staging/

Looking at /path/to/staging/lib/cmake/thing/libTargets.cmake I can see that
it calculates an _IMPORT_PREFIX variable (in this case to /path/to/staging/
while not yet installed). Also it loads files named libTargets-*.cmake (of
which there's only one for me, namely libTargets-noconfig.cmake).

Can I install a file libTargets-someName.cmake? In this file I'd have
access to the _IMPORT_PREFIX variable to e.g. set paths:

target_link_options(thing::lib
  INTERFACE
  -T ${_IMPORT_PREFIX}/share/link.ld)

Larger example at
https://github.com/musteresel/cmake-multiple-example-research

Best,
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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.15 fails to install on OS X

2019-10-14 Thread Eric Doenges

System Integrity Protection (SIP, introduced with macOS 10.11) prevents 
you from writing into various system directories (like /usr) even as the 
root user. You can either install cmake to a different location (like 
/usr/local, which apparently is not protected), or disable SIP entirely 
(which is not recommended). See this Wikipedia article 
 for more 
information on SIP.


Am 15.10.19 um 07:05 schrieb Jeffrey Walton:

I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is
stripped down, and only has the COmmand Line tools. No Xcode and
friends.

I configured with:

 ./configure --prefix=/usr

Configure appears OK. Make appears OK. Install is failing:

 $ sudo make install VERBOSE=1
 ...
[100%] Built target foo
/Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E
cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0
/Library/Developer/CommandLineTools/usr/bin/make -f
CMakeFiles/Makefile2 preinstall
make[1]: Nothing to be done for `preinstall'.
Install the project...
bin/cmake -P cmake_install.cmake
-- Install configuration: ""
CMake Error at Source/kwsys/cmake_install.cmake:36 (file):
   file cannot create directory: /usr/doc/cmake-3.15/cmsys.  Maybe need
   administrative privileges.
Call Stack (most recent call first):
   cmake_install.cmake:37 (include)

make: *** [install] Error 1

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake 3.15 fails to install on OS X

2019-10-14 Thread Jeffrey Walton

I'm building CMake cmake-3.15.4.tar.gz on OS X 10.12. The machine is
stripped down, and only has the COmmand Line tools. No Xcode and
friends.

I configured with:

./configure --prefix=/usr

Configure appears OK. Make appears OK. Install is failing:

$ sudo make install VERBOSE=1
...
[100%] Built target foo
/Users/jwalton/cmake-3.15.4/Bootstrap.cmk/cmake -E
cmake_progress_start /Users/jwalton/cmake-3.15.4/CMakeFiles 0
/Library/Developer/CommandLineTools/usr/bin/make -f
CMakeFiles/Makefile2 preinstall
make[1]: Nothing to be done for `preinstall'.
Install the project...
bin/cmake -P cmake_install.cmake
-- Install configuration: ""
CMake Error at Source/kwsys/cmake_install.cmake:36 (file):
  file cannot create directory: /usr/doc/cmake-3.15/cmsys.  Maybe need
  administrative privileges.
Call Stack (most recent call first):
  cmake_install.cmake:37 (include)

make: *** [install] Error 1
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-77-gdaf6a6b

2019-10-14 Thread Kitware Robot via Cmake-commits

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  daf6a6ba68a6fa1c5d1956f151104d903f3447cc (commit)
  from  30f0319e7f11f299cbe113b2c4db9f9c9a6ea21c (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=daf6a6ba68a6fa1c5d1956f151104d903f3447cc
commit daf6a6ba68a6fa1c5d1956f151104d903f3447cc
Author: Kitware Robot 
AuthorDate: Tue Oct 15 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Tue Oct 15 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 32b7686..458cc86 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191014)
+set(CMake_VERSION_PATCH 20191015)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] Mac Xcode 11 Generator bug/problem with CODE_SIGN_IDENTITY default

2019-10-14 Thread Eric Wing

I hit a problem with the CMake/Xcode Generator using Xcode 11. (I
think this problem started in Xcode 10 actually, but now I'm blocked
really hard and need to solve this.)


By default, Xcode is now trying to do "Sign to run locally" for the
Code Signing Identity (CODE_SIGN_IDENTITY) property, by default.



For trivial apps with no embedded libraries/frameworks, this seems to
get through. However, for my real, more complicated projects, I have
bundled libraries/frameworks. But since CMake doesn't really have full
support for Xcode signing, the embedded libraries/frameworks are not
signed, and the code sign process to local sign the .app fails.


So to workaround this, I would like to tell Xcode to disable code
signing entirely.

Unfortunately, the only way to disable this seems to be to set the
CODE_SIGN_IDENTITY to "", i.e. make the field completely blank. The
following link shows all the steps with pictures, but basically you
set the box to "Other" and then submit a completely blank input box.
This internally in the Xcode project sets CODE_SIGN_IDENTITY to "".

https://stackoverflow.com/a/54296008


But my problem in CMake is that when I try to set the Xcode property
to "", it ignores the setting and defer to Xcode's default value of
"Sign to run locally".

# This has no effect
set_property(TARGET ${my_app} PROPERTY XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "")


How can I force this property to be overridden with ""?

Thanks,
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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Sending you config file of an unknown system Platform/MINGW64_NT-10.0-17763

2019-10-14 Thread Artiom Blinovas

If it makes sense one could add mingw platform so next time cmake won't
speak warnings
# This is the CMakeCache file.
# For build in directory: 
/home/user/project/blatt-1-aufgabe-3-tendermonster/build
# It was generated by CMake: /usr/bin/cmake.exe
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Path to a program.
CMAKE_AR:FILEPATH=/mingw64/bin/ar.exe

//Choose the type of build, options are: None Debug Release RelWithDebInfo
// MinSizeRel ...
CMAKE_BUILD_TYPE:STRING=

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/mingw64/bin/g++.exe

//A wrapper around 'ar' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_AR:FILEPATH=/mingw64/bin/gcc-ar.exe

//A wrapper around 'ranlib' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/mingw64/bin/gcc-ranlib.exe

//Flags used by the CXX compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the CXX compiler during DEBUG builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the CXX compiler during RELEASE builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/mingw64/bin/gcc.exe

//A wrapper around 'ar' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_C_COMPILER_AR:FILEPATH=/mingw64/bin/gcc-ar.exe

//A wrapper around 'ranlib' adding the appropriate '--plugin' option
// for the GCC compiler
CMAKE_C_COMPILER_RANLIB:FILEPATH=/mingw64/bin/gcc-ranlib.exe

//Flags used by the C compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the C compiler during DEBUG builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the C compiler during MINSIZEREL builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the C compiler during RELEASE builds.
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the C compiler during RELWITHDEBINFO builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//Flags used by the linker during all build types.
CMAKE_EXE_LINKER_FLAGS:STRING=

//Flags used by the linker during DEBUG builds.
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during MINSIZEREL builds.
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during RELEASE builds.
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during RELWITHDEBINFO builds.
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Enable/Disable output of compile commands during generation.
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF

//Install path prefix, prepended onto install directories.
CMAKE_INSTALL_PREFIX:PATH=/usr/local

//Path to a program.
CMAKE_LINKER:FILEPATH=/mingw64/bin/ld.exe

//Path to a program.
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make.exe

//Flags used by the linker during the creation of modules during
// all build types.
CMAKE_MODULE_LINKER_FLAGS:STRING=

//Flags used by the linker during the creation of modules during
// DEBUG builds.
CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during the creation of modules during
// MINSIZEREL builds.
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=

//Flags used by the linker during the creation of modules during
// RELEASE builds.
CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=

//Flags used by the linker during the creation of modules during
// RELWITHDEBINFO builds.
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=

//Path to a program.
CMAKE_NM:FILEPATH=/mingw64/bin/nm.exe

//Path to a program.
CMAKE_OBJCOPY:FILEPATH=/mingw64/bin/objcopy.exe

//Path to a program.
CMAKE_OBJDUMP:FILEPATH=/mingw64/bin/objdump.exe

//Value Computed by CMake
CMAKE_PROJECT_DESCRIPTION:STATIC=

//Value Computed by CMake
CMAKE_PROJECT_HOMEPAGE_URL:STATIC=

//Value Computed by CMake
CMAKE_PROJECT_NAME:STATIC=main

//Path to a program.
CMAKE_RANLIB:FILEPATH=/mingw64/bin/ranlib.exe

//Flags used by the linker during the creation of shared libraries
// during all build types.
CMAKE_SHARED_LINKER_FLAGS:STRING=

//Flags used by the linker during the creation of shared libraries
// during DEBUG builds.
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=

//Flags used by the linker during the creation of shared libraries
// during MINSIZEREL builds.
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING=

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-14 Thread Alan W. Irwin


On 2019-10-13 17:15-0400 Paul Smith wrote:


A unity source file can lump together N real source files from the same
target (library/executable) as long as those files don't have extra
source-specific flags, because all other files in a given target have
the same flags.


I agree that it is not at all clear whether this is the cause of the
issue.  So I will stop speculating about that cause even though that
is a fun activity.  :-)

Nevertheless, it does sound like your complex test case does expose
some issue with EITHER how you have implemented the build system for
your complex case OR how CMake currently rejects certain builds from
being included in Unity builds.  So to figure out which it is, I think
your next step should be to attempt to implement the simplest possible
self-contained test case that illustrates the Unity exclusion issue
you have found.

I believe that course has already been suggested in this thread so I
am seconding that motion.  My own experiences with such
implementations is I often cannot demonstrate the issue in a simple
way, i.e., the "CMake bug" often tends to be due to an issue with my
implementation of the build system for the complex case.  However, when
I have demonstrated with such a simple test case there really is a
CMake bug, that test case normally helps CMake developers in a big way
to find and fix the issue.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make a hierarchical application using CMake?

2019-10-14 Thread J Decker

In the build directory, the build rules are generally like the would be in
the source too... so you can just go into src/libwhatever and do 'make' in
that branch.
like if your target was visual studio or some IDE, you could click on a
single project to build, and it would of course  check and build related
projects.

basically you don't even need ../ inclusions just a root that
add_subdirectory( lib1 ) ... 2, 3, utils (which itself adds other utiliy
thins that reference other lib targets )...


On Mon, Oct 14, 2019 at 11:11 AM Fred Baksik  wrote:

>
>
> On Mon, Oct 14, 2019, at 9:13 AM, David Aldrich wrote:
>
> Hi
>
>
>
> I am trying to convert a large software project from makefiles to CMake.
> The project is organised as a set of shared ‘star’ libraries, linked to a
> static ‘kernel’ library. The current directory arrangement is:
>
>
>
> |--stars
>
> | |-- star1_lib
>
> |  |-- source files
>
> |  |-- makefile
>
> | |-- star2_lib
>
> |  |-- source files
>
> |  |-- makefile
>
> | |-- solibs
>
> |  |-- Release
>
> | |-- .so files
>
> |
>
> |--kernel
>
> | |-- source files
>
> | |-- makefile
>
> | |-- Release
>
> |  |-- kernel.a
>
> |
>
> |--application
>
>   |-- makefile
>
>   |-- Release
>
>|-- myapp.exe
>
>
>
> In high-level terms, how could I implement this using CMake, such that
> invoking ‘make’ in directory ‘application’ invokes a make of each shared
> and static library, and links them to form ‘myapp.exe’?
>
>
>
> (I understand the basics of CMake, the issue here is how to handle the
> make of source code and libraries spread across a directory hierarchy).
>
>
>
> Best regards
>
>
>
> David
>
>
>
> add_subdirectory() can accept relative paths to outside the "root" source
> tree.
> So the main CMakeLists.txt would be located in ./application.
> Then do:
> add_subdirectory(../kernel kernel)
> add_subdirectory(../stars/stars1_lib stars1_lib)
>
> ./kernel/CMakeLists.txt would list it's files, and etcetera.
>
> I've use this method in the past for handling applications that are meant
> to target Windows, Linux, and embedded systems.
> Then by using variables to determine with platform / target ertain kernel
> and library characteristics are used.
> Everything is built in the build directory for that particular platform /
> target.
> This allows for app_target1, app_target2, app_target3, ..., build
> directories to be totally independent.
>
> --
> F
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make a hierarchical application using CMake?

2019-10-14 Thread Fred Baksik



On Mon, Oct 14, 2019, at 9:13 AM, David Aldrich wrote:
> Hi

> 

> I am trying to convert a large software project from makefiles to CMake. The 
> project is organised as a set of shared ‘star’ libraries, linked to a static 
> ‘kernel’ library. The current directory arrangement is:

> 

> |--stars

> | |-- star1_lib

> | |-- source files

> | |-- makefile

> | |-- star2_lib

> | |-- source files

> | |-- makefile

> | |-- solibs

> | |-- Release

> | |-- .so files

> |

> |--kernel

> | |-- source files

> | |-- makefile

> | |-- Release

> | |-- kernel.a

> |

> |--application

>  |-- makefile

>  |-- Release

>  |-- myapp.exe

> 

> In high-level terms, how could I implement this using CMake, such that 
> invoking ‘make’ in directory ‘application’ invokes a make of each shared and 
> static library, and links them to form ‘myapp.exe’?

> 

> (I understand the basics of CMake, the issue here is how to handle the make 
> of source code and libraries spread across a directory hierarchy).

> 

> Best regards

> 

> David

> 

> 
add_subdirectory() can accept relative paths to outside the "root" source tree.
So the main CMakeLists.txt would be located in ./application.
Then do:
 add_subdirectory(../kernel kernel)
add_subdirectory(../stars/stars1_lib stars1_lib)

./kernel/CMakeLists.txt would list it's files, and etcetera.

I've use this method in the past for handling applications that are meant to 
target Windows, Linux, and embedded systems.
Then by using variables to determine with platform / target ertain kernel and 
library characteristics are used.
Everything is built in the build directory for that particular platform / 
target.
This allows for app_target1, app_target2, app_target3, ..., build directories 
to be totally independent.

--
F-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] How to make a hierarchical application using CMake?

2019-10-14 Thread David Aldrich

Hi



I am trying to convert a large software project from makefiles to CMake.
The project is organised as a set of shared ‘star’ libraries, linked to a
static ‘kernel’ library. The current directory arrangement is:



|--stars

| |-- star1_lib

|  |-- source files

|  |-- makefile

| |-- star2_lib

|  |-- source files

|  |-- makefile

| |-- solibs

|  |-- Release

| |-- .so files

|

|--kernel

| |-- source files

| |-- makefile

| |-- Release

|  |-- kernel.a

|

|--application

  |-- makefile

  |-- Release

   |-- myapp.exe



In high-level terms, how could I implement this using CMake, such that
invoking ‘make’ in directory ‘application’ invokes a make of each shared
and static library, and links them to form ‘myapp.exe’?



(I understand the basics of CMake, the issue here is how to handle the make
of source code and libraries spread across a directory hierarchy).



Best regards



David
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-14 Thread Robert Maynard via CMake

Hi Paul,

As another reference point, I verified that -DCMAKE_UNITY_BUILD=ON
works with the VTK-m ( https://gitlab.kitware.com/vtk/vtk-m ) project.
I only verified using a clean CMake 3.16 build directory.

On Thu, Oct 10, 2019 at 6:43 PM Paul Smith  wrote:
>
> On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> > * The "UNITY_BUILD" target property was added to tell generators to
> >   batch include source files for faster compilation times.
>
> Are there any instructions on how to make this work?  I tried this:
>
>   cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .
>
> Then ran "make".  The output showed I had just as many output .o files
> as input .cpp files and that make ran one compile command per .cpp
> file.
>
> Is there something else I need to do to enable unity builds in my cmake
> files, than just give the above option?  The docs imply that the above
> is all that's needed.
>
> Cheers!
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

[CMake] error executing script with cmake -P

2019-10-14 Thread Edoardo Pasca

Dear all,

I am using external project. I would like to patch a source file. I came
out with a cmake script that does the string replacement I'm interested in.

I tested in a standalone project, with the following CMakeLists.txt

cmake_minimum_required(VERSION 3.4)
project(patching_string)
file (STRINGS TestData.py testdata NEWLINE_CONSUME)
string(REPLACE "sys.prefix" "os.environ[\'SIRF_INSTALL_PATH\']" patched
${testdata})
file( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/TestData.py ${patched} )

and as a matter of facts this does the string replacement I'm interested in.

Good, now I would like to use this to the project I'm really interested in
which uses the ExternalProject_Add machinery. I added the patch step:



file (WRITE ${CMAKE_BINARY_DIR}/patch_script.cmake "
file (STRINGS
${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py testdata
NEWLINE_CONSUME)
string(REPLACE \"sys.prefix\" \"os.environ[\\\'SIRF_INSTALL_PATH\\\']\"
patched \${testdata})
file( WRITE
${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py
\${patched} ) ")
ExternalProject_Add(
...

PATCH_COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/patch_script.cmake

... )



Notice that I write the patch_script.cmake before the ExternalProject_Add


Now, all of this WORKS. Or at least I get the patch_script.cmake file in
the proper directoty, with the content I want. However, execution with
cmake -P patch_script.cmake doesn't work as expected.

I get
CMake Error at build/patch_script.cmake:3 (string):
  string sub-command REPLACE requires at least four arguments.

Given that the patch_script.cmake has the same content of the standalone
CMakeLists.txt above (without the first 2 lines), I don't know where things
don't go well, except that I execute the script with cmake -P

cmake version 3.15.2

Thanks for any help.

Edo


-- 
Edo
I know you think you understand what you thought I said, but I'm not sure
you realize that what you heard is not what I meant (prob. Alan Greenspan)
:wq
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] finding cdk

2019-10-14 Thread Stéphane Ancelot


Hi,

I have got some problems finding cdk lib in my debian system

I used find_library without success

libcdk can be found in /usr/lib/x86_64-linux-gnu/

and cdk in include system path cdk/cdk.h

Regards,

S.Ancelot

-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-76-g30f0319

2019-10-13 Thread Kitware Robot via Cmake-commits

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  30f0319e7f11f299cbe113b2c4db9f9c9a6ea21c (commit)
  from  25eef45f16aa2046071d847d93314f3b843c870d (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=30f0319e7f11f299cbe113b2c4db9f9c9a6ea21c
commit 30f0319e7f11f299cbe113b2c4db9f9c9a6ea21c
Author: Kitware Robot 
AuthorDate: Mon Oct 14 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Mon Oct 14 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 1d575ba..32b7686 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191013)
+set(CMake_VERSION_PATCH 20191014)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-13 Thread Paul Smith

On Sat, 2019-10-12 at 19:25 -0700, Alan W. Irwin wrote:
> > Virtually all my properties are set on a per-target basis, so I assumed
> > they wouldn't be an issue here.
> > 
> > Am I misunderstanding that?
> 
> I think the current documentation is ambiguous about this.  But
> certain target and directory properties can affect the flags used to
> compile the source code just as much as source code properties.  So I
> am virtually positive the implementation has to pay attention to all
> these sources of properties to decide what can/cannot be lumped into a
> Unity source file.  If Kyle confirms this guess, then the
> documentation should be changed accordingly to remove the ambiguity
> about this.

I know no more than you but I'm quite sure that it's not the case that
adding library/executable-level options can cause unity to be disabled.
I've never heard of _ANY_ such target that didn't have at least some
properties defined for it.

A unity source file can lump together N real source files from the same
target (library/executable) as long as those files don't have extra
source-specific flags, because all other files in a given target have
the same flags.

-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-75-g25eef45

2019-10-13 Thread Kitware Robot via Cmake-commits

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  25eef45f16aa2046071d847d93314f3b843c870d (commit)
   via  7cf79f44195a86a907dba770f1f7a361d00e77c2 (commit)
   via  5bf85e25178f5d9f19d2f30cf66f088c21e1114a (commit)
   via  aa59badd6f1ab3c40d3674c26e1e55271d25225c (commit)
   via  7c579f0a03266e37bc0fcaaad4e3322068f65fdd (commit)
   via  4b021bd3e9f0d8b5ab5f8a8dc961441a7a063e25 (commit)
  from  001a1d2686243698527d59a9e5d00287a259 (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=25eef45f16aa2046071d847d93314f3b843c870d
commit 25eef45f16aa2046071d847d93314f3b843c870d
Merge: 001a1d2 7cf79f4
Author: Craig Scott 
AuthorDate: Sun Oct 13 21:08:23 2019 +
Commit: Kitware Robot 
CommitDate: Sun Oct 13 17:08:44 2019 -0400

Merge topic 'feature/CMAKE_MESSAGE_CONTEXT'

7cf79f4419 message: Support logging a context with each message
5bf85e2517 message: Add new CMAKE_MESSAGE_LOG_LEVEL variable
aa59badd6f Tests: Message log level tests must fail on unwanted output
7c579f0a03 Help: Move CMAKE_MESSAGE_INDENT variable to correct section
4b021bd3e9 message: Minor refactor to make code less verbose

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7cf79f44195a86a907dba770f1f7a361d00e77c2
commit 7cf79f44195a86a907dba770f1f7a361d00e77c2
Author: Alex Turbov 
AuthorDate: Sat Oct 12 13:37:15 2019 +1100
Commit: Craig Scott 
CommitDate: Sat Oct 12 18:21:36 2019 +1100

message: Support logging a context with each message

diff --git a/Help/command/message.rst b/Help/command/message.rst
index 1acf30a..beb820a 100644
--- a/Help/command/message.rst
+++ b/Help/command/message.rst
@@ -63,11 +63,22 @@ To make a log level persist between CMake runs, the
 :variable:`CMAKE_MESSAGE_LOG_LEVEL` variable can be set instead.
 Note that the command line option takes precedence over the cache variable.
 
-Messages of log levels ``NOTICE`` and below will also have each line preceded
+Messages of log levels ``NOTICE`` and below will have each line preceded
 by the content of the :variable:`CMAKE_MESSAGE_INDENT` variable (converted to
 a single string by concatenating its list items).  For ``STATUS`` to ``TRACE``
 messages, this indenting content will be inserted after the hyphens.
 
+Messages of log levels ``NOTICE`` and below can also have each line preceded
+with context of the form ``[some.context.example]``.  The content between the
+square brackets is obtained by converting the :variable:`CMAKE_MESSAGE_CONTEXT`
+list variable to a dot-separated string.  The message context will always
+appear before any indenting content but after any automatically added leading
+hyphens. By default, message context is not shown, it has to be explicitly
+enabled by giving the :manual:`cmake ` ``--log-context``
+command-line option or by setting the :variable:`CMAKE_MESSAGE_CONTEXT_SHOW`
+variable to true.  See the :variable:`CMAKE_MESSAGE_CONTEXT` documentation for
+usage examples.
+
 CMake Warning and Error message text displays using a simple markup
 language.  Non-indented text is formatted in line-wrapped paragraphs
 delimited by newlines.  Indented text is considered pre-formatted.
diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index 782a0f0..cad0df6 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -204,6 +204,8 @@ Variables that Change Behavior
/variable/CMAKE_LINK_DIRECTORIES_BEFORE
/variable/CMAKE_MFC_FLAG
/variable/CMAKE_MAXIMUM_RECURSION_DEPTH
+   /variable/CMAKE_MESSAGE_CONTEXT
+   /variable/CMAKE_MESSAGE_CONTEXT_SHOW
/variable/CMAKE_MESSAGE_INDENT
/variable/CMAKE_MESSAGE_LOG_LEVEL
/variable/CMAKE_MODULE_PATH
diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 08b7534..71110d1 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -214,6 +214,16 @@ Options
  For backward compatibility reasons, ``--loglevel`` is also accepted as a
  synonym for this option.
 
+``--log-context``
+ Enable the :command:`message` command outputting context attached to each
+ message.
+
+ This option turns on showing context for the current CMake run only.
+ To make showing the context persistent for all subsequent CMake runs, set
+ :variable:`CMAKE_MESSAGE_CONTEXT_SHOW` as a cache variable instead.
+ When this command line option is given, :variable:`CMAKE_MESSAGE_CONTEXT_SHOW`
+ is ignored.
+
 ``--debug-trycompile``
  Do not delete the :command:`try_compile` build tree.
  Only useful on one

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-69-g001a1d2

2019-10-12 Thread Kitware Robot via Cmake-commits

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  001a1d2686243698527d59a9e5d00287a259 (commit)
  from  3008d6988c08b7defe8029fee617e95860649230 (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=001a1d2686243698527d59a9e5d00287a259
commit 001a1d2686243698527d59a9e5d00287a259
Author: Kitware Robot 
AuthorDate: Sun Oct 13 00:01:09 2019 -0400
Commit: Kitware Robot 
CommitDate: Sun Oct 13 00:01:09 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index d6afa4b..1d575ba 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191012)
+set(CMake_VERSION_PATCH 20191013)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-12 Thread Alan W. Irwin


On 2019-10-12 15:40-0400 Paul Smith wrote:


On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote:

On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
<
alan.w.irwin1...@gmail.com

wrote:
The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS,
COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."


This is by far the most likely reason. We added this restriction
because we don't want files that have different COMPILE_FLAGS etc. to
be lumped together in a unity file. We decided that this was good
enough as a first past, but the way forward is to intelligently group
together files that have the same COMPILE_OPTIONS,
COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.


I saw this in the manual, and I interpreted it to mean that if we used
something like set_source_files_properties() or set_property(SOURCE) to
set these properties on specific source files, then those files which
are impacted by this won't be part of unity builds.

That seems quite sensible to me.

However, I don't do that hardly anywhere at all; maybe one or two files
have an extra INCLUDE_DIRECTORIES setting or similar.

Virtually all my properties are set on a per-target basis, so I assumed
they wouldn't be an issue here.

Am I misunderstanding that?


I think the current documentation is ambiguous about this.  But
certain target and directory properties can affect the flags used to
compile the source code just as much as source code properties.  So I
am virtually positive the implementation has to pay attention to all
these sources of properties to decide what can/cannot be lumped into a
Unity source file.  If Kyle confirms this guess, then the
documentation should be changed accordingly to remove the ambiguity
about this.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-12 Thread Paul Smith

On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote:
> On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
> <
> alan.w.irwin1...@gmail.com
> > wrote:
> > The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS,
> > COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."
> 
> This is by far the most likely reason. We added this restriction
> because we don't want files that have different COMPILE_FLAGS etc. to
> be lumped together in a unity file. We decided that this was good
> enough as a first past, but the way forward is to intelligently group
> together files that have the same COMPILE_OPTIONS,
> COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.

I saw this in the manual, and I interpreted it to mean that if we used
something like set_source_files_properties() or set_property(SOURCE) to
set these properties on specific source files, then those files which
are impacted by this won't be part of unity builds.

That seems quite sensible to me.

However, I don't do that hardly anywhere at all; maybe one or two files
have an extra INCLUDE_DIRECTORIES setting or similar.

Virtually all my properties are set on a per-target basis, so I assumed
they wouldn't be an issue here.

Am I misunderstanding that?

It's also possible that a previous attempt to introduce unity builds to
our setup via cotire is interfering with the new, standardized unity
builds.  I am not too familiar with the details of that but I can try
to look into it.

-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-68-g3008d69

2019-10-12 Thread Kitware Robot via Cmake-commits

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  3008d6988c08b7defe8029fee617e95860649230 (commit)
   via  07d15d70d2dcb74a2b53e4550cbde2e46dcdc266 (commit)
   via  0a52bada333ca968f6eef36076fe2df3f5cef051 (commit)
   via  3f10e564e04f1c619fcdc2c2fd4584961c46f9ec (commit)
   via  04ad7b8571f369e45feaba50941e20d082aa7b17 (commit)
   via  e13df96d26a7c10d2d10248f1695ebefaab5391d (commit)
   via  576424f89adbf49de59a52bfe483994ce06f5b28 (commit)
   via  7676966f997a22549b1a45ebedca566bb278acdb (commit)
   via  6847d81856be2337d24d4db04fc3d23f43122c82 (commit)
   via  874396a30d8dc85d45176de4ec53dc951179010e (commit)
   via  b254b0651ef093476322165f919e0a930534473b (commit)
   via  75f361a00c09d223bf2b0384155ef7804922a1ff (commit)
   via  83dbef11352c0075bf0c6c504f0094457b352051 (commit)
   via  ecbf6546d7b4b28ddda40649ecf9d7a4cbe12dcc (commit)
   via  2eecd1c3bce761510f7090629c807a93e3742b1e (commit)
   via  820f9523169bf3de75b2042c241457d8f7a73d74 (commit)
   via  881bca249defc148bc98d3caa9799f34536dd256 (commit)
   via  d26ef5d807917ddaafac83c50d251379d822d060 (commit)
   via  ec43d96657d3cc5d3a54555c6cbd0c1619c787ca (commit)
   via  908dff41c6a8fc98c77d40c5f3b4e7c34ee46c3d (commit)
   via  18f3e286521437adc3f231cc126833bdcd2c5807 (commit)
   via  5652e11ea1543a9d3038bf104607bf13feb5582a (commit)
   via  6e51db9a40cda01907322da384a84bf5c4237231 (commit)
   via  3709389520f091de10e2c1b7fb8350bacc3a0fb0 (commit)
   via  3e05637280e77d991f2270d13cead0343b13d029 (commit)
   via  13c8dbd5a6bede4f3455203958238165437396e9 (commit)
   via  ed06d27c7f0503a7d0d32d352d2e31bd4b82070e (commit)
   via  1d9155eb9351120eadfa7d6386d0625b076d4be2 (commit)
   via  806e01d638195905b1973c031ef71a4125f50376 (commit)
   via  8aac65a3614646073904b41baa4a57e5db28fcec (commit)
  from  b727e74fb0c6bd05a0e03ab08a5d38fac906c5e1 (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=3008d6988c08b7defe8029fee617e95860649230
commit 3008d6988c08b7defe8029fee617e95860649230
Merge: 07d15d7 6847d81
Author: Brad King 
AuthorDate: Sat Oct 12 10:30:48 2019 -0400
Commit: Brad King 
CommitDate: Sat Oct 12 10:30:48 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07d15d70d2dcb74a2b53e4550cbde2e46dcdc266
commit 07d15d70d2dcb74a2b53e4550cbde2e46dcdc266
Merge: 0a52bad 874396a
Author: Brad King 
AuthorDate: Sat Oct 12 14:29:10 2019 +
Commit: Kitware Robot 
CommitDate: Sat Oct 12 10:29:19 2019 -0400

Merge topic 'no-git-version'

874396a30d CMakeVersion: Add option to disable Git suffix
b254b0651e CMakeVersion: Prefer Git information provided by 'git archive' 
exports

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a52bada333ca968f6eef36076fe2df3f5cef051
commit 0a52bada333ca968f6eef36076fe2df3f5cef051
Merge: 3f10e56 ec43d96
Author: Brad King 
AuthorDate: Sat Oct 12 14:26:52 2019 +
Commit: Kitware Robot 
CommitDate: Sat Oct 12 10:28:05 2019 -0400

Merge topic 'FindPostgreSQL-macports-and-v12'

ec43d96657 FindPostgreSQL: support macports installation scheme
908dff41c6 FindPostgreSQL: support version 12

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f10e564e04f1c619fcdc2c2fd4584961c46f9ec
commit 3f10e564e04f1c619fcdc2c2fd4584961c46f9ec
Merge: 04ad7b8 5652e11
Author: Brad King 
AuthorDate: Sat Oct 12 14:26:42 2019 +
Commit: Kitware Robot 
CommitDate: Sat Oct 12 10:27:06 2019 -0400

Merge topic 'iar-8051-support'

5652e11ea1 IAR: Add 8051 support
6e51db9a40 IAR: Fix v850 assembler support file extensions

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=04ad7b8571f369e45feaba50941e20d082aa7b17
commit 04ad7b8571f369e45feaba50941e20d082aa7b17
Merge: e13df96 806e01d
Author: Brad King 
AuthorDate: Sat Oct 12 14:25:35 2019 +
Commit: Kitware Robot 
CommitDate: Sat Oct 12 10:26:13 2019 -0400

Merge topic 'objc-c++flags'

806e01d638 Objective-C: Do not treat Objective-C files as C++ files

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e13df96d26a7c10d2d10248f1695ebefaab5391d
commit e13df96d26a7c10d2d10248f1695ebefaab5391d
Merge: 576424f 13c8dbd
Author: Brad King 
AuthorDate: Sat Oct 12 14:24:51 2019 +
Commit: Kitware Robot

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-24-g6847d81

2019-10-12 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  6847d81856be2337d24d4db04fc3d23f43122c82 (commit)
   via  874396a30d8dc85d45176de4ec53dc951179010e (commit)
   via  b254b0651ef093476322165f919e0a930534473b (commit)
   via  75f361a00c09d223bf2b0384155ef7804922a1ff (commit)
   via  ecbf6546d7b4b28ddda40649ecf9d7a4cbe12dcc (commit)
   via  2eecd1c3bce761510f7090629c807a93e3742b1e (commit)
   via  820f9523169bf3de75b2042c241457d8f7a73d74 (commit)
   via  bbf216fb6bc85ab0db994655026ce5c934473aea (commit)
   via  d26ef5d807917ddaafac83c50d251379d822d060 (commit)
   via  ec43d96657d3cc5d3a54555c6cbd0c1619c787ca (commit)
   via  908dff41c6a8fc98c77d40c5f3b4e7c34ee46c3d (commit)
   via  18f3e286521437adc3f231cc126833bdcd2c5807 (commit)
   via  5652e11ea1543a9d3038bf104607bf13feb5582a (commit)
   via  6e51db9a40cda01907322da384a84bf5c4237231 (commit)
   via  3709389520f091de10e2c1b7fb8350bacc3a0fb0 (commit)
   via  3e05637280e77d991f2270d13cead0343b13d029 (commit)
   via  13c8dbd5a6bede4f3455203958238165437396e9 (commit)
   via  ed06d27c7f0503a7d0d32d352d2e31bd4b82070e (commit)
   via  1d9155eb9351120eadfa7d6386d0625b076d4be2 (commit)
   via  806e01d638195905b1973c031ef71a4125f50376 (commit)
   via  8aac65a3614646073904b41baa4a57e5db28fcec (commit)
  from  ef5875b5593833ba99bc7a8afd23a1c9cd80cd3e (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 -
---

Summary of changes:
 Help/prop_tgt/UNITY_BUILD.rst  | 36 +
 Help/release/3.16.rst  |  4 +
 Help/variable/CMAKE_EXPORT_COMPILE_COMMANDS.rst|  4 +
 Help/variable/CMAKE_UNITY_BUILD.rst| 10 ++-
 Modules/CMakeCXXCompiler.cmake.in  |  2 +-
 Modules/CMakePlatformId.h.in   |  3 +
 Modules/Compiler/IAR-ASM.cmake |  7 +-
 Modules/Compiler/IAR-C.cmake   |  5 ++
 Modules/Compiler/IAR-CXX.cmake |  6 ++
 Modules/Compiler/IAR-DetermineCompiler.cmake   |  2 +-
 Modules/Compiler/IAR-FindBinUtils.cmake|  3 +-
 Modules/FindPostgreSQL.cmake   |  5 +-
 Modules/InstallRequiredSystemLibraries.cmake   |  7 ++
 Source/CMakeVersion.cmake  | 90 +++---
 Source/cmVisualStudio10ToolsetOptions.cxx  |  3 +-
 .../{v141_CSharp.json => v142_CSharp.json} |  0
 Tests/CMakeLists.txt   | 12 +++
 .../cxx-file-extension-test/CMakeLists.txt |  8 ++
 .../main.m |  0
 19 files changed, 139 insertions(+), 68 deletions(-)
 copy Templates/MSBuild/FlagTables/{v141_CSharp.json => v142_CSharp.json} (100%)
 create mode 100644 Tests/Objective-C/cxx-file-extension-test/CMakeLists.txt
 copy Tests/Objective-C/{c-file-extension-test => 
cxx-file-extension-test}/main.m (100%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-38-gb727e74

2019-10-12 Thread Kitware Robot via Cmake-commits

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  b727e74fb0c6bd05a0e03ab08a5d38fac906c5e1 (commit)
   via  bbf216fb6bc85ab0db994655026ce5c934473aea (commit)
  from  a8d42ecb8dddc615e93559889994390bd10daf88 (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=b727e74fb0c6bd05a0e03ab08a5d38fac906c5e1
commit b727e74fb0c6bd05a0e03ab08a5d38fac906c5e1
Merge: a8d42ec bbf216f
Author: Brad King 
AuthorDate: Sat Oct 12 14:22:12 2019 +
Commit: Kitware Robot 
CommitDate: Sat Oct 12 10:22:21 2019 -0400

Merge topic 'vs-v142-csharp-flags'

bbf216fb6b VS: Add toolset v142 CSharp flag table

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bbf216fb6bc85ab0db994655026ce5c934473aea
commit bbf216fb6bc85ab0db994655026ce5c934473aea
Author: Brad King 
AuthorDate: Fri Oct 11 10:42:47 2019 -0400
Commit: Brad King 
CommitDate: Fri Oct 11 11:11:20 2019 -0400

VS: Add toolset v142 CSharp flag table

While the flag tables for C and C++ were generated from MSBuild `.xml`
files, the CSharp flag tables were written by hand.  Copy the `v141`
flag table to use for the `v142` toolset.

Remove the special case added by commit 626c51f47b (VS: Update for
Visual Studio 2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) that mapped
the v142 flag table lookup to v141 since we now have the real v142
table.

Fixes: #19828

diff --git a/Source/cmVisualStudio10ToolsetOptions.cxx 
b/Source/cmVisualStudio10ToolsetOptions.cxx
index a490e03..7fc33e6 100644
--- a/Source/cmVisualStudio10ToolsetOptions.cxx
+++ b/Source/cmVisualStudio10ToolsetOptions.cxx
@@ -34,8 +34,7 @@ std::string 
cmVisualStudio10ToolsetOptions::GetCSharpFlagTableName(
   std::string const useToolset = this->GetToolsetName(name, toolset);
 
   if (useToolset == "v142") {
-// FIXME: Add CSharp flag table for v142.
-return "v141";
+return "v142";
   } else if (useToolset == "v141") {
 return "v141";
   } else if (useToolset == "v140") {
diff --git a/Templates/MSBuild/FlagTables/v142_CSharp.json 
b/Templates/MSBuild/FlagTables/v142_CSharp.json
new file mode 100644
index 000..5989aea
--- /dev/null
+++ b/Templates/MSBuild/FlagTables/v142_CSharp.json
@@ -0,0 +1,574 @@
+[
+  {
+"name":  "ProjectName",
+"switch": "out:",
+"comment": "",
+"value": "",
+"flags": [
+  "UserValue",
+  "UserRequired"
+]
+  },
+  {
+"name":  "OutputType",
+"switch": "target:exe",
+"comment": "",
+"value": "Exe",
+"flags": []
+  },
+  {
+"name":  "OutputType",
+"switch": "target:winexe",
+"comment": "",
+"value": "Winexe",
+"flags": []
+  },
+  {
+"name":  "OutputType",
+"switch": "target:library",
+"comment": "",
+"value": "Library",
+"flags": []
+  },
+  {
+"name":  "OutputType",
+"switch": "target:module",
+"comment": "",
+"value": "Module",
+"flags": []
+  },
+  {
+"name":  "DocumentationFile",
+"switch": "doc",
+"comment": "",
+"value": "",
+"flags": [
+  "UserValue",
+  "UserRequired"
+]
+  },
+  {
+"name":  "Platform",
+"switch": "platform:x86",
+"comment": "",
+"value": "x86",
+"flags": []
+  },
+  {
+"name":  "Platform",
+"switch": "platform:Itanium",
+"comment": "",
+"value": "Itanium",
+"flags": []
+  },
+  {
+"name":  "Platform",
+"switch": "platform:x64",
+"comment": "",
+"value": "x64",
+"flags": []
+  },
+  {
+"name":  "Platform",
+"switch": "platform:arm",
+"comment": "",
+"value": "arm",
+"flags": []
+  },
+  {
+"name":  "Platform",
+"switch": "platform:anycpu32bitpreferred",
+"comment": "",
+"value": "anycpu32bitpreferred",
+"flags": []
+  },
+  {
+"name":  "Platform",
+"switch": "platform:anycpu",
+"comment": "",
+"value": "anycpu",
+"flags": []
+  },
+  {
+"name":  "References",
+"switch": "reference:",
+"comment": "mit alias",
+"value": "",
+"flags": []
+  },
+  {
+"name":  "References",
+"switch": "reference:",
+"comment": "dateiliste",
+"value": "",
+"flags": []
+  },
+  {
+"name":  "AddModules",
+"switch": "addmodule:",
+"comment": "",
+"value": "",
+"flags": [
+  "SemicolonAppendable"
+]
+  },
+  {
+"name":  "Win32Resource",
+"switch": "win32res:",
+"comment": "",
+"value": "",
+"flags": [
+  "UserValue",
+  "UserRequired"
+]
+  },
+  {
+"name":  "ApplicationIcon",
+

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-36-ga8d42ec

2019-10-11 Thread Kitware Robot via Cmake-commits

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  a8d42ecb8dddc615e93559889994390bd10daf88 (commit)
  from  fe9a903d8ee70b62a9d598dcfebeab0ded0b2e05 (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=a8d42ecb8dddc615e93559889994390bd10daf88
commit a8d42ecb8dddc615e93559889994390bd10daf88
Author: Kitware Robot 
AuthorDate: Sat Oct 12 00:01:14 2019 -0400
Commit: Kitware Robot 
CommitDate: Sat Oct 12 00:01:14 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index f7646c9..5670622 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191011)
+set(CMake_VERSION_PATCH 20191012)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

2019-10-11 Thread Innokentiy Alaytsev

Hello!

After some look into target installation, I've devised  the following
abomination

 
. It is ugly and not the way it should be done, but it works and only
requires some discipline at copying and pasting header files listing code.
The function expects the files that are to be installed to be listed with
BUILD_INTERFACE and INSTALL_INTERFACE generator expressions. 

I only use it for headers because I don't know how to separate file lists
into components (i.e. Dev for headers and Runtime for resource files
required at runtime). I use the following code for listing target header
files:

set (HEADERS
  # List of files here
  )

file(RELATIVE_PATH PREFIX
  ${PROJECT_SOURCE_DIR}
  ${CMAKE_CURRENT_LIST_DIR})


foreach (HEADER IN LISTS HEADERS)
  target_sources (my_target(s)
PRIVATE
$
$)
endforeach (HEADER IN HEADERS)

Hope that will somewhat help and won't hurt anyone's fillings and mind.

Best regards,
Innokentiy Alaytsev




--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

2019-10-11 Thread Alex Turbov

Hi,

On Fri, Oct 11, 2019 at 9:33 PM Michael Ellery  wrote:

> I’d like to make sure I understand two different aspects of header files
> management for libraries:
>
> (1) typically you can add header files to target_sources, but it’s only
> helpful for IDEs..so that the IDE will show the header files in its sources
> list, correct?. In theory, cmake does not actually need header files
> explicitly specified for dependency tracking, although I guess listing them
> makes it explicit.
>

yep, correct


> (2) setting the PUBLIC_HEADER property for a target then makes header
> files available for installation via the PUBLIC_HEADER destination. Is this
> the preferred way to install the library interface/public headers? How do
> you handle a header directory hierarchy — for example maybe you have detail
> and impl subdirectories if you are following boost/stdlib conventions.
>
>
Nowadays this feature useless if you have a directory hierarchy %( So
pity...


> I found Craig’s article about target_sources very helpful (
> https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/),
> but I don’t think it addresses the PUBLIC_HEADER installation use case.
>

Yep, it describes a trivial ("Hello World" level) projects.

Some time ago I've started a discussion about improvements to
`target_sources` addressed to resolve directory hierarchy install problem,
but it ends w/ no outcome... %(


> Thanks,
> Mike Ellery
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] target_sources vs. PUBLIC_HEADER for libraries

2019-10-11 Thread Fred Baksik



On Fri, Oct 11, 2019, at 3:33 PM, Michael Ellery wrote:
> I’d like to make sure I understand two different aspects of header files 
> management for libraries:
> 
> (1) typically you can add header files to target_sources, but it’s only 
> helpful for IDEs..so that the IDE will show the header files in its sources 
> list, correct?. In theory, cmake does not actually need header files 
> explicitly specified for dependency tracking, although I guess listing them 
> makes it explicit.
My experience has been that adding a header file makes sure it’s listed in the 
IDE along with the other sources. Some IDEs will determine other non-listed 
headers and list them under a different folder. But I’ve never seen listing an 
unused header file getting added as a dependency so that changing it causes the 
target to get rebuilt. I’ve always had to make sure that the header is included 
in something that gets compiled. 

—
F-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] target_sources vs. PUBLIC_HEADER for libraries

2019-10-11 Thread Michael Ellery

I’d like to make sure I understand two different aspects of header files 
management for libraries:

(1) typically you can add header files to target_sources, but it’s only helpful 
for IDEs..so that the IDE will show the header files in its sources list, 
correct?. In theory, cmake does not actually need header files explicitly 
specified for dependency tracking, although I guess listing them makes it 
explicit.

(2) setting the PUBLIC_HEADER property for a target then makes header files 
available for installation via the PUBLIC_HEADER destination. Is this the 
preferred way to install the library interface/public headers? How do you 
handle a header directory hierarchy — for example maybe you have detail and 
impl subdirectories if you are following boost/stdlib conventions.

I found Craig’s article about target_sources very helpful 
(https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/),
 but I don’t think it addresses the PUBLIC_HEADER installation use case.

Thanks,
Mike Ellery
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-11 Thread Kyle Edwards via CMake

On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
 wrote:
> The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, 
> COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."

This is by far the most likely reason. We added this restriction
because we don't want files that have different COMPILE_FLAGS etc. to
be lumped together in a unity file. We decided that this was good
enough as a first past, but the way forward is to intelligently group
together files that have the same COMPILE_OPTIONS,
COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.

Kyle
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Error because of MSVC_RUNTIME_LIBRARY value

2019-10-11 Thread Денис Смирнов

*Here is my root CMakeLists.txt file:*
cmake_minimum_required(VERSION 3.15)

cmake_policy(SET CMP0091 NEW)
project(test_masm)

set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$:Debug>")

add_subdirectory(src)

*Here is the src/CMakeLists.txt file:*
enable_language(ASM_MASM)
add_executable(test_executable main.asm)

*src/main.asm is empty.*

After run cmake.exe I get error "*MSVC_RUNTIME_LIBRARY value
'MultiThreadedDebug' not known for this ASM_MASM compiler*".

*Here is the full listing:*
cmake.exe -G "Visual Studio 16 2019" -A x64 ..
-- The C compiler identification is MSVC 19.22.27905.0
-- The CXX compiler identification is MSVC 19.22.27905.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe --
works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/cl.exe --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM_MASM compiler identification is MSVC
-- Found assembler: C:/Program Files (x86)/Microsoft Visual
Studio/2019/Community/VC/Tools/MSVC/14.22.27905/bin/Hostx64/x64/ml64.exe
-- Configuring done
CMake Error in src/CMakeLists.txt:
  MSVC_RUNTIME_LIBRARY value 'MultiThreadedDebug' not known for this
ASM_MASM
  compiler.
-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

Can someone please tell me if I am doing something wrong or it's a bug?
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-35-gfe9a903

2019-10-11 Thread Kitware Robot via Cmake-commits

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  fe9a903d8ee70b62a9d598dcfebeab0ded0b2e05 (commit)
   via  90bb63a5ef9805519c12cc693a7c3d23b990a42c (commit)
   via  ae24597202bbcc51ebcc9e32ae1b3ee8a8a99336 (commit)
   via  ef5875b5593833ba99bc7a8afd23a1c9cd80cd3e (commit)
   via  b7509dd674d9e0a1e428c5f4ceff7b78b47ac296 (commit)
   via  3fb146cb1149ecb90404a5276c8db3cb46e00889 (commit)
   via  847e8bc98c68cdf5bc0b7935c68764c0a6d5658e (commit)
  from  696b2d40d4bdf5a8094f7d7c3e9ac66b039f34bf (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=fe9a903d8ee70b62a9d598dcfebeab0ded0b2e05
commit fe9a903d8ee70b62a9d598dcfebeab0ded0b2e05
Merge: 90bb63a b7509dd
Author: Brad King 
AuthorDate: Fri Oct 11 12:36:49 2019 +
Commit: Kitware Robot 
CommitDate: Fri Oct 11 08:36:57 2019 -0400

Merge topic 'cmake-bin-link-job-pool'

b7509dd674 Add option to configure Ninja link job pool for CMake's own 
binaries

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90bb63a5ef9805519c12cc693a7c3d23b990a42c
commit 90bb63a5ef9805519c12cc693a7c3d23b990a42c
Merge: ae24597 ef5875b
Author: Brad King 
AuthorDate: Fri Oct 11 08:35:02 2019 -0400
Commit: Brad King 
CommitDate: Fri Oct 11 08:35:02 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae24597202bbcc51ebcc9e32ae1b3ee8a8a99336
commit ae24597202bbcc51ebcc9e32ae1b3ee8a8a99336
Merge: 696b2d4 3fb146c
Author: Brad King 
AuthorDate: Fri Oct 11 12:34:08 2019 +
Commit: Kitware Robot 
CommitDate: Fri Oct 11 08:34:16 2019 -0400

Merge topic 'intel-19-compile-features'

3fb146cb11 Tests: Update CompileFeatures test for Intel 19 with VS 2015
847e8bc98c Intel: Fix default C++ dialect detection on Windows

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b7509dd674d9e0a1e428c5f4ceff7b78b47ac296
commit b7509dd674d9e0a1e428c5f4ceff7b78b47ac296
Author: Brad King 
AuthorDate: Thu Oct 10 13:28:08 2019 -0400
Commit: Brad King 
CommitDate: Thu Oct 10 13:28:45 2019 -0400

Add option to configure Ninja link job pool for CMake's own binaries

Create an undocumented `CMake_JOB_POOL_LINK_BIN` option that builders
can set to avoid linking too many of our binaries at once.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 63e08de..d89a69d 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -1193,6 +1193,11 @@ if(WIN32)
   endforeach()
 endif()
 
+if(CMake_JOB_POOL_LINK_BIN)
+  set_property(TARGET ${_tools} PROPERTY JOB_POOL_LINK "link-bin")
+  set_property(GLOBAL APPEND PROPERTY JOB_POOLS 
"link-bin=${CMake_JOB_POOL_LINK_BIN}")
+endif()
+
 # Install tools
 
 foreach(_tool ${_tools})
diff --git a/Source/CursesDialog/CMakeLists.txt 
b/Source/CursesDialog/CMakeLists.txt
index 7009717..a9e46fd 100644
--- a/Source/CursesDialog/CMakeLists.txt
+++ b/Source/CursesDialog/CMakeLists.txt
@@ -34,5 +34,9 @@ else()
   target_link_libraries(ccmake cmForm)
 endif()
 
+if(CMake_JOB_POOL_LINK_BIN)
+  set_property(TARGET ccmake PROPERTY JOB_POOL_LINK "link-bin")
+endif()
+
 CMake_OPTIONAL_COMPONENT(ccmake)
 install(TARGETS ccmake DESTINATION ${CMAKE_BIN_DIR} ${COMPONENT})
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index cb89d19..98dd0e2 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -178,6 +178,10 @@ if(WIN32)
   target_sources(cmake-gui PRIVATE $)
 endif()
 
+if(CMake_JOB_POOL_LINK_BIN)
+  set_property(TARGET cmake-gui PROPERTY JOB_POOL_LINK "link-bin")
+endif()
+
 # cmake-gui has not been updated for `include-what-you-use`.
 # Block the tool until this is done.
 set_target_properties(cmake-gui PROPERTIES

---

Summary of changes:
 Modules/CMakeCXXCompilerId.cpp.in | 16 +---
 Source/CMakeLists.txt |  5 +
 Source/CursesDialog/CMakeLists.txt|  4 
 Source/QtDialog/CMakeLists.txt|  4 
 Tests/CompileFeatures/CMakeLists.txt  |  6 ++
 Tests/CompileFeatures/default_dialect.cpp | 12 +++-
 6 files changed, 43 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-3-gef5875b

2019-10-11 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  ef5875b5593833ba99bc7a8afd23a1c9cd80cd3e (commit)
   via  3fb146cb1149ecb90404a5276c8db3cb46e00889 (commit)
   via  847e8bc98c68cdf5bc0b7935c68764c0a6d5658e (commit)
  from  9150c818b7d2afb868575fcb2e0c9ba62b9d7f85 (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 -
---

Summary of changes:
 Modules/CMakeCXXCompilerId.cpp.in | 16 +---
 Tests/CompileFeatures/CMakeLists.txt  |  6 ++
 Tests/CompileFeatures/default_dialect.cpp | 12 +++-
 3 files changed, 30 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Unity builds vs. compile_commands.json

2019-10-11 Thread Brad King via CMake

On 10/10/19 6:53 PM, Paul Smith wrote:
> Is there an intent to address this before the 3.16 release?  
> 
> Or is this a known limitation, which may or may not be addressed in
> some future version of CMake?
> 
> If the latter it should probably be added to the release notes and/or
> documentation for unity builds.

I've opened an issue for it:

* https://gitlab.kitware.com/cmake/cmake/issues/19826

This won't block the release so I've updated the documentation to
mention this limitation.

-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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Linking twice for CRC32

2019-10-11 Thread Vincent van Beveren


Hello  everyone,

For integrating the CRC to an ELF I believe I will need to link twice. 
First to create a binary on which to caclulate the CRC, and using a 
second pass to actually put the CRC into a the symbol at the last part 
of the RAM. Using the pointers by Eric  Noulard I have constructed the 
following CMake code, which links the file, exports a binary BIN file 
(the actual ROM image, and then calculates the CRC into a file called 
$.crc32.


# Exprimental CRC32 support
add_library(clb_v2_dom.objs OBJECT ${F_GEN} ${F__DOM})
target_compile_definitions(clb_v2_dom.objs PUBLIC -DDOM -DCLBV2 )
add_executable(clb_v2_dom.elf $)
add_custom_command(TARGET clb_v2_dom.elf POST_BUILD
    COMMAND ${CMAKE_OBJCOPY} $ ${SECTIONS} 
-O binary $.bin
    COMMAND ${Python_EXECUTABLE} ${CMAKE_SOURCE_DIR}/tools/crc32.py 
$.bin > $.crc32

)

with linker flags defined as

# Bring up the linker
add_link_options(
    -nostartfiles
    -nodefaultlibs
    -Wl,--gc-sections
    -nostdlib
    -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld
    -Wl,--defsym=CRC_VALUE=0
    -Wl,--defsym=_start=0
    )

However, the last part is to link the file again with *exactly* the same 
invocation as the original linking, except for the 
'-Wl,--defsym=CRC_VALUE=<>' instead of 0.


Can anyone give me points on how to achieve this goal?

Kind regards,
Vincent

--
National Institute for Subatomic Physics Nikhef
Department of Computer Technology
Science Park 105
1098 XG AMSTERDAM

tel.  : +31 (0)20 592 2032
e-mail: v.van.beve...@nikhef.nl
site  : http://www.nikhef.nl/~vincentb

--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-10 Thread Alan W. Irwin


On 2019-10-10 18:21-0400 Paul Smith wrote:


On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.


Are there any instructions on how to make this work?  I tried this:

 cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .

Then ran "make".  The output showed I had just as many output .o files
as input .cpp files and that make ran one compile command per .cpp
file.

Is there something else I need to do to enable unity builds in my cmake
files, than just give the above option?  The docs imply that the above
is all that's needed.


Hi Paul:

I have never tried unity builds, but your question did inspire me to
look at [the unity build
documentation](https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html)
which if you follow the links to other related documentation does imply what
you have done above is correct and should by default group 8
source-code files into a lump to be compiled together.  Since you are
not getting that behaviour, I am wondering if one or more of the
documented reasons for skipping unity builds is making a difference in your
case. Those reasons are the following:

"The source files marked by GENERATED will be skipped from unity build. This 
applies also for the source files marked with SKIP_UNITY_BUILD_INCLUSION.

The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or 
INCLUDE_DIRECTORIES will also be skipped."

Good luck, and I hope you will keep the list informed of any further
progress you make with your unity build experiments.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-28-g696b2d4

2019-10-10 Thread Kitware Robot via Cmake-commits

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  696b2d40d4bdf5a8094f7d7c3e9ac66b039f34bf (commit)
  from  8d2f18af3268920412621e98e527830faa763448 (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=696b2d40d4bdf5a8094f7d7c3e9ac66b039f34bf
commit 696b2d40d4bdf5a8094f7d7c3e9ac66b039f34bf
Author: Kitware Robot 
AuthorDate: Fri Oct 11 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Fri Oct 11 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 404b475..f7646c9 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191010)
+set(CMake_VERSION_PATCH 20191011)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] Unity builds vs. compile_commands.json (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-10 Thread Paul Smith

On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

For some reason this didn't work with my actual cmake environment, but
I could enable it on a simple test environment.  I can look into that
later.

Here my concern is that you cannot use unity builds if you need
compile_commands.json (-DCMAKE_EXPORT_COMPILE_COMMANDS=ON); for example
if this is required by your IDE or other build tools.  When unity
builds are enabled the json file is not usable since it contains only
commands for the unity source files and doesn't describe the original
source files.

Is there an intent to address this before the 3.16 release?  

Or is this a known limitation, which may or may not be addressed in
some future version of CMake?

If the latter it should probably be added to the release notes and/or
documentation for unity builds.

Thanks!

-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-10 Thread Paul Smith

On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

Are there any instructions on how to make this work?  I tried this:

  cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .

Then ran "make".  The output showed I had just as many output .o files
as input .cpp files and that make ran one compile command per .cpp
file.

Is there something else I need to do to enable unity builds in my cmake
files, than just give the above option?  The docs imply that the above
is all that's needed.

Cheers!

-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing

2019-10-10 Thread Robert Maynard via CMake

I am proud to announce the first CMake 3.16 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.16

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.16/release/3.16.html

Some of the more significant changes in CMake 3.16 are:

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* "ctest(1)" now has the ability to serialize tests based on
  hardware requirements for each test. See Hardware Allocation for
  details.

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".


CMake 3.16 Release Notes


Changes made since CMake 3.15 include the following.


New Features



Languages
-

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.


Compilers
-

* The "Clang" compiler is now supported on "Solaris".


Platforms
-

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-27-g8d2f18a

2019-10-10 Thread Kitware Robot via Cmake-commits

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  8d2f18af3268920412621e98e527830faa763448 (commit)
   via  1529f4a9308a1c808b5ac48083ca0c365c589021 (commit)
  from  afdb354ac77818604dfed8ef416031a12ab49a48 (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=8d2f18af3268920412621e98e527830faa763448
commit 8d2f18af3268920412621e98e527830faa763448
Merge: afdb354a 1529f4a
Author: Brad King 
AuthorDate: Thu Oct 10 18:30:33 2019 +
Commit: Kitware Robot 
CommitDate: Thu Oct 10 14:30:41 2019 -0400

Merge topic 'rel-push'

1529f4a930 Utilities/Release: Teach "push" script to create destination 
subdirectory

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1529f4a9308a1c808b5ac48083ca0c365c589021
commit 1529f4a9308a1c808b5ac48083ca0c365c589021
Author: Brad King 
AuthorDate: Thu Oct 10 14:24:32 2019 -0400
Commit: Brad King 
CommitDate: Thu Oct 10 14:24:32 2019 -0400

Utilities/Release: Teach "push" script to create destination subdirectory

Extend the script added by commit 9bf97363b0 (Utilities/Release: Replace
upload step with a "push" script, 2019-05-24, v3.15.0-rc1~56^2) to
create the destination subdirectory for the CMake version being pushed.

diff --git a/Utilities/Release/push.bash b/Utilities/Release/push.bash
index 1c8efe9..a1c6651 100755
--- a/Utilities/Release/push.bash
+++ b/Utilities/Release/push.bash
@@ -50,6 +50,9 @@ if test -z "$dir"; then
 dir="v${version}"
 fi
 readonly dir
+if ! test -d "${dest}/${dir}"; then
+mkdir "${dest}/${dir}"
+fi
 
 for f in cmake-${version}*; do
 if ! test -f "${f}"; then

---

Summary of changes:
 Utilities/Release/push.bash | 3 +++
 1 file changed, 3 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [cmake-developers] FindThreads module documentation needs some work

2019-10-10 Thread Alan W. Irwin


I have [opened an issue on the 
bugtracker](https://gitlab.kitware.com/cmake/cmake/issues/19823) concerning 
this documentation bug.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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:
https://cmake.org/mailman/listinfo/cmake-developers

[Cmake-commits] CMake annotated tag, v3.16.0-rc1, created. v3.16.0-rc1

2019-10-10 Thread Kitware Robot via Cmake-commits

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 annotated tag, v3.16.0-rc1 has been created
at  b0030385395d25452fd043fff69c603df363b328 (tag)
   tagging  9150c818b7d2afb868575fcb2e0c9ba62b9d7f85 (commit)
  replaces  v3.15.4
 tagged by  Brad King
on  Thu Oct 10 11:14:44 2019 -0400

- Log -
CMake 3.16.0-rc1
-BEGIN PGP SIGNATURE-

iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAl2fSuQWHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhJzrD/4m52KtwFdVtaBh92W2xMjj5FsS
MudR08iDnIolNQ1XvGNHfPBvDhAEYLG/ZYOcTGG0GhaZHkLSUBcrg0VDsOjEiCnJ
tYz0I+QswMZMWfXIP6nSsuAqur8ODAfRrcLn7M9XRT5e4eeZhAtbnu5Cyn/ntgKg
zM7xqRCuWUIzKgqAp5BJQmzhmPsr0wjZMLCWxdgnVG8YuX4ufRbUdo5PUPUeOkj6
BQY+wluhfvoy0TjXYEYhq+kYQKPQwbNQNPBQwIE9SecQ7zgn9iVMPz4BypZ9UDdM
tuS2x4fzhWk3DzyzcTYQih/4+db/j9tkY5OqDAEdjpvuAZRDsGlaSFzaNX9wwiiC
Q9kaXHit3iYhzbOBqC3slq2iGSRkFQNtpNfLYHQFdRyj1xjcvKnjeZMCYrfzF6Gj
Nqc/mB9ZP7wmdE7juhzN4HdsBcTuT7nzs4xutm54qrJ8gviJt1M/ceYZOVVXW5d8
Ti9iXHhGEQYBuu71ZEPCWzLuNzePOhbu2/yEkNzXvOPsU86DCc2BtVD+2OWdnHee
pra1Z5Pz391OP+tFFZRW1X3P6Xjz9IzEgzMkdfbEa0RLFRK9+7NzC6A6yzaCrQo5
JsEvNwpXEZfQYDXkmU/QwpbcIY/UTiDACJ73mHRjBTOpW5ngT5bct+pvd58dJtJq
WdbQOYRG7Efs/LCcdA==
=MFLa
-END PGP SIGNATURE-

Alan W. Irwin (2):
  Add per-lang variants of CMAKE_LINK_LIBRARY_{FILE_FLAG,SUFFIX}
  FindThreads: Do not hard-code '-l' flag on library name

Alex Turbov (22):
  modermize: replace some raw pointers w/ `unique_ptr`
  Refactor: Move CPack internal files to `Internal/CPack/` directory
  Refactor: Optimize some stream output operations
  Refactor: Remove one-time used macros
  Refactor: Use anonymous namespace instead of `static`s
  Refactor: Use anonymous namespace instead of `static`s in `cpack.cxx`
  Refactor: Eliminate `sep` from the loop
  Refactor: Eliminate one-time-used variables
  Refactor: Replace a "magic" number w/ a named constant
  Refactor: Add some `const` to vars
  Refactor: Use initializer lists instead of `push_back` series
  Refactor: Use raw string literals instead of escaping
  project: Keep leading `0` in PROJECT_VERSION components
  message(): Control indentation via CMAKE_MESSAGE_INDENT
  CPack: Introduce CPACK_INSTALL_SCRIPTS variable
  Help: Fix example output in the `CMAKE_MESSAGE_INDENT` documentation
  Help: Fix spelling typo in `CMAKE_MESSAGE_INDENT` docs
  Refactor: Use `unique_ptr` instead of raw pointer
  cpack: Add `CPACK_INSTALL_CMAKE_CONFIGURATIONS` variable
  Style: Remove spaces after command call and `(`
  Refactor: Use `list` commands instead of old-way string ops
  CPackDeb: Use `CPACK_PACKAGE_DESCRIPTION_FILE`

Alexej Harm (2):
  Add compatibility with the cl.exe /permissive- compiler option
  CPackWIX: Allow omitting program menu folder and uninstall shortcut

Antonio Rojas (1):
  GNUInstallDirs: Keep 'lib' as default LIBDIR on Arch Linux based systems

Artalus (1):
  Fix elseif() in place of else()

Asit Dhal (1):
  Refactor: Use cmStrCat to construct error strings

Avraham Shukron (2):
  cmTargetPropCommandBase: Order target type condition by order in enum
  target_*: Allow setting INTERFACE properties of UNKNOWN IMPORTED targets

Ben Boeckel (6):
  cmExportBuildFileGenerator: improve error message
  Tests: add tests for export set error messages
  cmCTestHandlerCommand: fix typo of local variable
  cmInstallExportGenerator: add a method for the file destination
  cmExportInstallFileGenerator: improve error message
  ExternalProject: fix some documentation typos

Benjamin Wozniak (5):
  cuda: Extend toolset argument to accept path
  cuda: Extend vs10 target generator to use custom cuda path
  cuda: Extend cuda compiler detection to work with custom cuda path
  cuda: Added docs for extended cuda toolset
  cuda: Adapted tests to work with modified cuda toolset

Betsy McPhail (11):
  Help: Populate tutorial guide text
  Help: Update tutorial to include text from CMake book
  Tutorial: Improve Step 1
  Tutorial: Improve Step 2
  Tutorial: Improve Step 3
  Tutorial: Improve Step 4
  Tutorial: Improve Step 5
  Tutorial: Improve Step 6
  Tutorial: Improve Step 7
  Tutorial: Improve Step 8
  Tutorial: Improve Step 9

Brad King (592):
  Merge branch 'release-3.15'
  Begin post-3.15 development
  Merge topic 'GetPrerequisites-variable-typo'
  Merge topic 'ctest_xml_tweaks'
  Merge branch 'release-3.15'
  Merge topic 'doc-FindEnvModule-typos'
  Merge branch 'release-3.15'
  Merge topic 'cpack-nuget-case'
  Merge topic 'doc-xlclang-id'
  Merge branch 'release-3.15'
  Merge topic 'cmTarget_cleanups'
  Merge topic 'autogen_header_in_symbolic_path_fix'
  Merge branch

[Cmake-commits] CMake branch, master, updated. v3.15.4-1367-gafdb354a

2019-10-10 Thread Kitware Robot via Cmake-commits

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  afdb354ac77818604dfed8ef416031a12ab49a48 (commit)
   via  9150c818b7d2afb868575fcb2e0c9ba62b9d7f85 (commit)
  from  e3b9d125ef5cd766b05f0354ca817ebfc7b82a42 (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=afdb354ac77818604dfed8ef416031a12ab49a48
commit afdb354ac77818604dfed8ef416031a12ab49a48
Merge: e3b9d12 9150c81
Author: Brad King 
AuthorDate: Thu Oct 10 11:16:14 2019 -0400
Commit: Brad King 
CommitDate: Thu Oct 10 11:16:14 2019 -0400

Merge branch 'release-3.16'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.15.4-1342-g9150c81

2019-10-10 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  9150c818b7d2afb868575fcb2e0c9ba62b9d7f85 (commit)
  from  580e322dcbc3cfe8cbe08491564fe2aeb727b811 (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 -
---

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
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> with patchelf is works with an intriguing warning:
> warning: working around a Linux kernel bug by creating a hole of 2093056
> bytes in ‘/path/to/executable’
>
> which seems to be a resolved issue:
> https://github.com/NixOS/patchelf/issues/92
>
> after that on the modified executable,
> chrpath is printing weird output when asking to read rpath.
> patchelf does properly print modified rpath.
>
> I think the SO article gives enough reference for this:
> https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary
>
> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.
...

Thanks both! Great news - being unable to grow rpath was always really 
irritating.

Mark
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
> Removing rpath is easy; chrpath -d lib_or_exe

You could but, to avoid a maintenance headache, you'd normally end up 
getting the environment module to load any prereq environment modules, 
which would modify LD_LIBRARY_PATH.

In either case, it'd mean unexpectedly polluting the user's environment 
with things they didn't explicitly ask for, which I don't like doing.

...
> Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
> line:
>
> cmake
> -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath
> 
...

Sorry - yes, I'm commenting it out and then specifying the 
CMAKE_INSTALL_RPATH I want on the command line.

Best,

Mark
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, release, updated. v3.15.4-1341-g580e322

2019-10-10 Thread Kitware Robot via Cmake-commits

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, release has been updated
   via  580e322dcbc3cfe8cbe08491564fe2aeb727b811 (commit)
   via  7bbddeb78d46193eda9c2a948040e50012fbe33b (commit)
   via  e5419f4f873d8c233c9903a813866bc0c759dfc9 (commit)
   via  b63dc7c8fc7a9d3487577dedf7dfabc63bc20817 (commit)
   via  5d3b825cbdfe24c97f2f480a05990ad7c2e885d9 (commit)
   via  36ded610af1bf80304a35491eeb66c34c8e9b7a8 (commit)
  from  88fa7b761d3ef2ba1c6326ed4d7069cb0e886a07 (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 -
---

Summary of changes:
 Help/command/message.rst   |  2 +-
 Help/manual/cmake.1.rst|  5 +-
 Help/release/3.16.rst  |  5 ++
 Modules/ExternalProject.cmake  |  4 +-
 Source/cmFileAPICodemodel.cxx  | 26 +++
 Source/cmGeneratorTarget.cxx   | 86 ++
 Source/cmGeneratorTarget.h |  9 +++
 Source/cmGlobalGenerator.cxx   |  1 +
 Source/cmGlobalXCodeGenerator.cxx  |  7 +-
 Source/cmLocalGenerator.cxx| 79 
 Source/cmLocalGenerator.h  |  3 +-
 Source/cmLocalVisualStudio7Generator.cxx   | 18 -
 Source/cmMakefileExecutableTargetGenerator.cxx |  2 -
 Source/cmMakefileLibraryTargetGenerator.cxx|  2 -
 Source/cmMakefileTargetGenerator.cxx   | 35 -
 Source/cmMakefileUtilityTargetGenerator.cxx|  2 -
 Source/cmNinjaNormalTargetGenerator.cxx|  2 -
 Source/cmNinjaTargetGenerator.cxx  | 43 ++-
 Source/cmVisualStudio10TargetGenerator.cxx | 29 ++--
 Source/cmake.cxx   | 11 +++
 Source/cmakemain.cxx   |  5 +-
 Tests/RunCMake/message/RunCMakeTest.cmake  | 82 +++--
 ...derr.txt => message-log-level-debug-stderr.txt} |  0
 ...dout.txt => message-log-level-debug-stdout.txt} |  0
 ...rr.txt => message-log-level-default-stderr.txt} |  0
 ...ut.txt => message-log-level-default-stdout.txt} |  0
 .../message-log-level-invalid-result.txt}  |  0
 .../message/message-log-level-invalid-stderr.txt   |  1 +
 ...err.txt => message-log-level-notice-stderr.txt} |  0
 ...err.txt => message-log-level-status-stderr.txt} |  0
 ...out.txt => message-log-level-status-stdout.txt} |  0
 ...derr.txt => message-log-level-trace-stderr.txt} |  0
 ...dout.txt => message-log-level-trace-stdout.txt} |  0
 ...rr.txt => message-log-level-verbose-stderr.txt} |  0
 ...ut.txt => message-log-level-verbose-stdout.txt} |  0
 ...rr.txt => message-log-level-warning-stderr.txt} |  0
 36 files changed, 324 insertions(+), 135 deletions(-)
 copy Tests/RunCMake/message/{message-loglevel-verbose-stderr.txt => 
message-log-level-debug-stderr.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-debug-stdout.txt => 
message-log-level-debug-stdout.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-verbose-stderr.txt => 
message-log-level-default-stderr.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-status-stdout.txt => 
message-log-level-default-stdout.txt} (100%)
 copy Tests/RunCMake/{while/MissingArgument-result.txt => 
message/message-log-level-invalid-result.txt} (100%)
 create mode 100644 Tests/RunCMake/message/message-log-level-invalid-stderr.txt
 copy Tests/RunCMake/message/{message-loglevel-verbose-stderr.txt => 
message-log-level-notice-stderr.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-verbose-stderr.txt => 
message-log-level-status-stderr.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-status-stdout.txt => 
message-log-level-status-stdout.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-verbose-stderr.txt => 
message-log-level-trace-stderr.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-trace-stdout.txt => 
message-log-level-trace-stdout.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-verbose-stderr.txt => 
message-log-level-verbose-stderr.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-verbose-stdout.txt => 
message-log-level-verbose-stdout.txt} (100%)
 copy Tests/RunCMake/message/{message-loglevel-warning-stderr.txt => 
message-log-level-warning-stderr.txt} (100%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.15.4-1365-ge3b9d12

2019-10-10 Thread Kitware Robot via Cmake-commits

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  e3b9d125ef5cd766b05f0354ca817ebfc7b82a42 (commit)
   via  d00bb419ca5ccbecee892ce1f3e5fdd455c11ff0 (commit)
   via  82501b40a186752184a7bb8602615b03e0ac0965 (commit)
   via  5586648a775544a21ee9171a38700e1d90907e86 (commit)
   via  2faadaae6bad10750e4b834a4a4d20bf5514f7e2 (commit)
   via  bab7ec3c259f31eb696f84c55ac80497e30f13df (commit)
   via  580e322dcbc3cfe8cbe08491564fe2aeb727b811 (commit)
   via  7bbddeb78d46193eda9c2a948040e50012fbe33b (commit)
   via  e5419f4f873d8c233c9903a813866bc0c759dfc9 (commit)
   via  b63dc7c8fc7a9d3487577dedf7dfabc63bc20817 (commit)
   via  5d3b825cbdfe24c97f2f480a05990ad7c2e885d9 (commit)
   via  36ded610af1bf80304a35491eeb66c34c8e9b7a8 (commit)
  from  0d1bf3f660faebd8b73d638d0359db5502e2f3d6 (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=e3b9d125ef5cd766b05f0354ca817ebfc7b82a42
commit e3b9d125ef5cd766b05f0354ca817ebfc7b82a42
Merge: 82501b4 d00bb41
Author: Brad King 
AuthorDate: Thu Oct 10 13:26:58 2019 +
Commit: Kitware Robot 
CommitDate: Thu Oct 10 09:27:06 2019 -0400

Merge topic 'deprecate-policy-old'

d00bb419ca Add deprecation warnings for policies CMP0069 and below

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d00bb419ca5ccbecee892ce1f3e5fdd455c11ff0
commit d00bb419ca5ccbecee892ce1f3e5fdd455c11ff0
Author: Brad King 
AuthorDate: Mon Oct 7 13:26:23 2019 -0400
Commit: Brad King 
CommitDate: Thu Oct 10 09:26:10 2019 -0400

Add deprecation warnings for policies CMP0069 and below

The OLD behaviors of all policies are deprecated, but only by
documentation.  Add an explicit deprecation diagnostic for policies
introduced in CMake 3.9 and below to encourage projects to port away
from setting policies to OLD.

diff --git a/Help/release/dev/deprecate-policy-old.rst 
b/Help/release/dev/deprecate-policy-old.rst
new file mode 100644
index 000..401f4b2
--- /dev/null
+++ b/Help/release/dev/deprecate-policy-old.rst
@@ -0,0 +1,8 @@
+deprecate-policy-old
+
+
+* An explicit deprecation diagnostic was added for policy ``CMP0068``
+  and policy ``CMP0069`` (``CMP0067`` and below were already deprecated).
+  The :manual:`cmake-policies(7)` manual explains that the OLD behaviors
+  of all policies are deprecated and that projects should port to the
+  NEW behaviors.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index f143ef7..bf488b1 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -4487,7 +4487,7 @@ bool cmMakefile::SetPolicy(cmPolicies::PolicyID id,
 
   // Deprecate old policies, especially those that require a lot
   // of code to maintain the old behavior.
-  if (status == cmPolicies::OLD && id <= cmPolicies::CMP0067 &&
+  if (status == cmPolicies::OLD && id <= cmPolicies::CMP0069 &&
   !(this->GetCMakeInstance()->GetIsInTryCompile() &&
 (
   // Policies set by cmCoreTryCompile::TryCompileCode.
diff --git a/Tests/RunCMake/CMP0068/CMP0068-OLD-stderr.txt 
b/Tests/RunCMake/CMP0068/CMP0068-OLD-stderr.txt
new file mode 100644
index 000..a736129
--- /dev/null
+++ b/Tests/RunCMake/CMP0068/CMP0068-OLD-stderr.txt
@@ -0,0 +1,10 @@
+^CMake Deprecation Warning at CMP0068-OLD.cmake:[0-9]+ \(cmake_policy\):
+  The OLD behavior for policy CMP0068 will be removed from a future version
+  of CMake.
+
+  The cmake-policies\(7\) manual explains that the OLD behaviors of all
+  policies are deprecated and that a policy should be set to OLD only under
+  specific short-term circumstances.  Projects should be ported to the NEW
+  behavior and not rely on setting a policy to OLD.
+Call Stack \(most recent call first\):
+  CMakeLists.txt:[0-9]+ \(include\)$
diff --git a/Tests/RunCMake/CMP0069/CMP0069-OLD-stderr.txt 
b/Tests/RunCMake/CMP0069/CMP0069-OLD-stderr.txt
new file mode 100644
index 000..f51a6f4
--- /dev/null
+++ b/Tests/RunCMake/CMP0069/CMP0069-OLD-stderr.txt
@@ -0,0 +1,10 @@
+^CMake Deprecation Warning at CMP0069-OLD.cmake:[0-9]+ \(cmake_policy\):
+  The OLD behavior for policy CMP0069 will be removed from a future version
+  of CMake.
+
+  The cmake-policies\(7\) manual explains that the OLD behaviors of all
+  policies are deprecated and that a policy should be set to OLD only under
+  specific short-term circumstances.  Projects should be ported to the NEW
+  behavior and not rely on setting a policy to OLD.
+Call Stack \(most recent call first\):
+  CMakeLists.txt:[0-9]+ \(include\)$
diff --git

Re: [CMake] HOWTO declare component inter-dependencies in multi-component packages

2019-10-10 Thread stefan


ping ?

On 2019-10-07 12:47 p.m., stefan wrote:


Hi,

can you reproduce my observations ? I'm I doing something wrong or is 
there indeed an issue with CMake ? Should I follow up with a bug report ?


Thanks,

On 2019-10-04 2:20 p.m., stefan wrote:



On 2019-10-03 5:24 p.m., Kyle Edwards wrote:

On Thu, 2019-10-03 at 17:08 -0400, stefan wrote:

Yes, that is exactly what I'm trying to do, but it doesn't seem to
have any effect. That is, `dpkg --info ...` doesn't list the
additional dependency, and correspondingly, running `apt-get install
...` on the component package file will install the package without
first installing the prerequisite component.
Consider this declaration:
   set(CPACK_COMPONENTS_ALL runtime development mstool)
If I now write
   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime)
I will see no effect. That is, the "development" package still does
not depend on the "runtime" package.
So I try this:
   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME)
in case capitalization is required. Now the "runtime" component seems
to get packaged twice (as per the cmake logs), but still no correct
dependencies.
Is it time for a bug report ?

Please send us a minimal CMakeLists.txt that reproduces the issue.


Sure. Here it is. The relevant line part is line 5. Please let me 
know what I'm doing wrong.


Thanks,

Stefan
--

   ...ich hab' noch einen Koffer in Berlin...
 


Stefan
--

   ...ich hab' noch einen Koffer in Berlin...
 


Stefan

--

  ...ich hab' noch einen Koffer in Berlin...


-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Zakrzewski, Jakub

From: Eric Noulard 
Sent: 10 October 2019 14:43
To: Zakrzewski, Jakub
Cc: cmake@cmake.org
Subject: Re: [CMake] cmake end user vs. developer rpath handling

> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.

?No problem, thanks for trying out.
I'd like to think that asking and answering questions (even the seemingly 
stupid ones) makes us learn new things.

--
Have a nice one,
Jakub
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard

Le jeu. 10 oct. 2019 à 14:30, Eric Noulard  a
écrit :

>
>
> Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
> jakub.zakrzew...@scheer-group.com> a écrit :
>
>> --
>> *From:* CMake  on behalf of Eric Noulard <
>> eric.noul...@gmail.com>
>> *Sent:* 10 October 2019 12:05
>> *To:* DIXON, MARK C.
>> *Cc:* cmake@cmake.org
>> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>>
>>
>> > No they can't because the maximum size is burried into the binary ELF
>> file,
>> > that why CMake "reserve" some space with many ";;;" in order to replace
>> BUILD_RPATH with INSTALL_RPATH when doing
>> > 'install'.
>>
>> Interesting.
>> So you're saying that this:
>> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
>> does not really work? (An honest question)
>>
>
> Nope I meant that my manual page forr chrpath says:
>-r  | --replace 
>   Replace current rpath or runpath setting with the path
> given.  The new path must be shorter or the same length as the current path.
>
> patchelf does not seem to have this limitation.
> I remember trying and being hit by that issue, but I did not tried it
> recently.
> I'll try again and come back to you.
>

with chrpath try to replace an rpath with a longer one I get:
new rpath '/../lib:/purposely/too/long/rpath/hdsjds/dshkjhdsk/dsgdjsj' too
large; maximum length 104

with patchelf is works with an intriguing warning:
warning: working around a Linux kernel bug by creating a hole of 2093056
bytes in ‘/path/to/executable’

which seems to be a resolved issue:
https://github.com/NixOS/patchelf/issues/92

after that on the modified executable,
chrpath is printing weird output when asking to read rpath.
patchelf does properly print modified rpath.

I think the SO article gives enough reference for this:
https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary

So I was wrong, thank you for your honest question Jakub.
I learned something usefull thanks to you.


-- 
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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard

Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> a écrit :

> --
> *From:* CMake  on behalf of Eric Noulard <
> eric.noul...@gmail.com>
> *Sent:* 10 October 2019 12:05
> *To:* DIXON, MARK C.
> *Cc:* cmake@cmake.org
> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>
>
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Interesting.
> So you're saying that this:
> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
> does not really work? (An honest question)
>

Nope I meant that my manual page forr chrpath says:
   -r  | --replace 
  Replace current rpath or runpath setting with the path
given.  The new path must be shorter or the same length as the current path.

patchelf does not seem to have this limitation.
I remember trying and being hit by that issue, but I did not tried it
recently.
I'll try again and come back to you.

-- 
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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Zakrzewski, Jakub

From: CMake  on behalf of Eric Noulard 

Sent: 10 October 2019 12:05
To: DIXON, MARK C.
Cc: cmake@cmake.org
Subject: [DKIM] Re: [CMake] cm?ake end user vs. developer rpath handling

> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace 
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.

Interesting.
So you're saying that this: 
https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319?
does not really work? (An honest question)

-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard

Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C.  a
écrit :

> On Thu, 10 Oct 2019, Eric Noulard wrote:
> ...
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> > BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Hi Eric,
>
> Interesting - any ideas on how big the padding is?
>


Not sure, but I bet CMake is reserving as much space as needed for the
forthcoming INSTALL_RPATH
(as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt
I you rebuild the concerned from source try configuring it with a stupidly
long CMAKE_INSTALL_RPATH
i.e.

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath


Then, you can surely have a look using  chrpath -l lib_or_exe.


> > Note however that you should be able to "delete" RPATH: chrpath -d
> > and then rely on LD_LIBRARY_PATH, ld.so.config, etc
> >
> > The thing I don't quite understand why you need to replace/amend RPATH.
> In
> > my (very personal) use case when I have to integrate third-party
> software:
>
> My use case is where:
>
> - I install some software, made available to others via environment
>modules (http://modules.sourceforge.net/).
>
> - The installed software is dynamically linked to other libraries, also
>installed via environment modules.
>
> - I don't want to make people load modules for prerequisite libraries
>(and prerequisites for the prerequisites...) to use the software.
>


ok I see, I did use modules a long time ago on some now oldish supercomputer
in order to play with various compilers of library versions.


>
> A complication is that I end up having to build lots of copies of the same
> software but built with different prerequisites... so it has to be
> automated on top of the upstream project's build system.
>
> For applications using libraries, I've tended to use wrapper scripts as it
> means fewer arguments with build systems. But for libraries using
> libraries, rpath's the only real option.
>

No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
Removing rpath is easy; chrpath -d lib_or_exe


> My rpath can get quite long.
>

Yes now I see why, depending on the number of  prerequisite you have and
how many
modules are loaded.


> ...
> > If the developers of the software you are using have chosen in their
> CMake
> > build-system to define an install RPATH your only safe bet
> > is probably to build & install the software at your favorite location or
> > propose an upstream patch for supporting unspecified RPATH.
> >
> > But may be I miss something in your use case?
>
> I guess I should be proposing upstream patches but, there are so many
> software projects to do this for, it has always been simpler to carry
> forward a small patch or patches. Perhaps I should be a better citizen.
>

It may not be tractable to file dozen of upstream patch and wait for
feedback
but in the case the build system does not offer a way to chose install
rpath content I think you are stucked
(beside remove rpath).


In this case, what feels easiest is to keep a patch commenting out the
> developer's RPATH definition in CMakeLists.txt, identified by Jakub
> earlier.
>

Yes I agree. However I my hypothesis of space reservation in RPATH by cmake
is write
you may want to replace with something that fits your needs and not simply
commenting it out.
Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
line:

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath

https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html

-- 
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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.

Hi Eric,

Interesting - any ideas on how big the padding is?

> Note however that you should be able to "delete" RPATH: chrpath -d
> and then rely on LD_LIBRARY_PATH, ld.so.config, etc
>
> The thing I don't quite understand why you need to replace/amend RPATH. In
> my (very personal) use case when I have to integrate third-party software:

My use case is where:

- I install some software, made available to others via environment
   modules (http://modules.sourceforge.net/).

- The installed software is dynamically linked to other libraries, also
   installed via environment modules.

- I don't want to make people load modules for prerequisite libraries
   (and prerequisites for the prerequisites...) to use the software.

A complication is that I end up having to build lots of copies of the same 
software but built with different prerequisites... so it has to be 
automated on top of the upstream project's build system.

For applications using libraries, I've tended to use wrapper scripts as it 
means fewer arguments with build systems. But for libraries using 
libraries, rpath's the only real option.

My rpath can get quite long.

...
> If the developers of the software you are using have chosen in their CMake
> build-system to define an install RPATH your only safe bet
> is probably to build & install the software at your favorite location or
> propose an upstream patch for supporting unspecified RPATH.
>
> But may be I miss something in your use case?

I guess I should be proposing upstream patches but, there are so many 
software projects to do this for, it has always been simpler to carry 
forward a small patch or patches. Perhaps I should be a better citizen.

In this case, what feels easiest is to keep a patch commenting out the 
developer's RPATH definition in CMakeLists.txt, identified by Jakub 
earlier.

Cheers,

Mark
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] lintian errors when using cpack

2019-10-10 Thread Gillman, Matthew

Hi again

I just tried adding those additional two options, but I am getting the same 
error with lintian.

Is there something wrong in my shlibs or control file?

Thanks

Matthew

From: CMake  on behalf of "Gillman, Matthew" 

Date: Thursday, 10 October 2019 at 10:58
To: Kerstin Keller , "cmake@cmake.org" 

Subject: Re: [CMake] lintian errors when using cpack

Hi Kerstin

Sorry, I forgot to list them. Right now I only have the following set:

SET(CPACK_GENERATOR "DEB")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me mailto:m...@me.com>>")
INCLUDE(CPack)

I will try adding the two you suggest and see how it goes, but I wouldn’t be 
surprised if there were others I need too.

I’ve had a look and I can’t see a file called `postint`.

Thanks for your help

Matthew


From: CMake  on behalf of Kerstin Keller 

Date: Thursday, 10 October 2019 at 10:49
To: "cmake@cmake.org" 
Subject: Re: [CMake] lintian errors when using cpack

Hi,

what CPACK_DEBIAN_* options have you set and to what values have you set them?
I guess you're both using:
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)

When I generate the file for my lib it looks a bit different (e.g. it pins the 
package to a certain version, but not sure if it is required, and I have never 
run the linter on the package):

libfoo 5 foo (= 5.4.0-1)

Also, does CMake generate the `postinst` control file for you? That one should 
trigger the ldconfig execution, but maybe something is not correct there? How 
do other packages trigger the ldconfig execution?

Best,
Kerstin
[Image removed by sender.]

Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew 
mailto:m.gill...@ucl.ac.uk>>:
It's great that cpack can generate different packages - in my case, a .deb file 
for Debian.

But if you then want to submit the generated .deb file to be part of Debian's 
official release, you have to run the lintian tool, and make sure you pass its 
checks. I have managed manually to fix some errors in the .deb file (which 
underneath is just an ar archive), and doubtless other warn ins and errors 
could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt 
file. But I have a couple of errors which I don't know how to fix:

E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for 
usr/lib/libsopt.so.3.0.1
E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1

Probably the shilbs file and control file need correcting, but I can't find 
anything which makes sense to me. Here is the shills file:

libsopt 3 libsopt3.0

And here is the relevant section of the control file:

Package: libsopt3.0
Priority: optional
#Section: devel
Section: libs
#Version: 0.1.1
Version: 3.0

If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* 
options I could use to solve these issues?

Thanks

Matthew


--

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

Re: [CMake] lintian errors when using cpack

2019-10-10 Thread Eric Noulard

Le jeu. 10 oct. 2019 à 11:58, Gillman, Matthew  a
écrit :

> Hi Kerstin
>
>
>
> Sorry, I forgot to list them. Right now I only have the following set:
>
>
>
> SET(CPACK_GENERATOR "DEB")
>
> SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me ")
>
> INCLUDE(CPack)
>
>
>
> I will try adding the two you suggest and see how it goes, but I wouldn’t
> be surprised if there were others I need too.
>

You may review CPack Deb feature in the documentation as well:
https://cmake.org/cmake/help/v3.15/cpack_gen/deb.html

I’ve had a look and I can’t see a file called `postint`.
>
>
>
> Thanks for your help
>
>
>
> Matthew
>


-- 
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:
https://cmake.org/mailman/listinfo/cmake

< 1 2 3 4 5 6 7 8 9 10 >

401 - 500 of 92908 matches

Mail list logo