[Cmake-commits] CMake branch, master, updated. v3.13.2-742-g3bd8144

[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  3bd814460161f3af682e116aa561efcc30793eff (commit)
  from  50454c96d691871dce0a7f3176ceccdc09419b32 (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=3bd814460161f3af682e116aa561efcc30793eff
commit 3bd814460161f3af682e116aa561efcc30793eff
Author: Kitware Robot 
AuthorDate: Tue Dec 18 00:01:04 2018 -0500
Commit: Kitware Robot 
CommitDate: Tue Dec 18 00:01:04 2018 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index a257cbc..5afaf7b 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20181217)
+set(CMake_VERSION_PATCH 20181218)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Kyle Edwards via cmake-developers]

Eric,
Thanks for the feedback. See comments below.
On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote:
> > This has some common design issue as my proposal:
> > enable_cross_target(...)
> > for which Eike has valuable doubt:
> > https://cmake.org/pipermail/cmake-developers/2018-November/030919.h
> > tml 
If you're talking about the issue of specifying multiple toolchain
files on the command line, I'm imagining a design like this:
add_toolchain(TargetToolchain FILE ${CMAKE_TOOLCHAIN_FILE_TARGET})
and then specify it on the command line with:
cmake ../src -DCMAKE_TOOLCHAIN_FILE=/path/to/host/toolchain.cmake
-DCMAKE_TOOLCHAIN_FILE_TARGET=/path/to/target/toolchain.cmake
> > So if you want to build both for host and cross toolchain you'll have to 
> > explicitely 
> > add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> > add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
> > > > If you follow the previously referred discussion you cannot assume that 
> > > > one lib/exe
> > built for a toolchain is not built for another toolchain as well.
If you want to build the same target with multiple toolchains then I
think you're better off declaring them as different targets, with
different TOOLCHAINs but the same source files, etc.
> > ... sorry wrong key pressed...
> > > > CMake could perfectly automatically create the new "TOOLCHAIN" object 
> > > > by loading the very
> > same toolchain file as we have today. We could simple add a new variable
> > CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name 
> > them as he wants.
> > When there is no CMAKE_TOOLCHAIN_NAME this would be the default
> > toolchain.
> 

My vision for this feature is that the project specifies the names of
the toolchains that it's expecting, and the toolchain file is agnostic
of this - it simply sets the properties of the toolchain named
${CMAKE_SELECTED_TOOLCHAIN}.
If you want to have a variable number of toolchains, you could do
something like this:
set(PROJECT_TARGET_TOOLCHAIN_NAMES "" CACHE STRING "Names of
toolchains")
foreach(i ${PROJECT_TARGET_TOOLCHAIN_NAMES})
  add_toolchain(${i} FILE ${CMAKE_TOOLCHAIN_FILE_${i}})
  add_executable(foo-${i} TOOLCHAIN ${i} ...) # Build a copy of foo for
each target platform
endforeach()
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-developers

Re: [CMake] CMake 3.11.3: set properties on the command line?

[Craig Scott]

On Tue, Dec 18, 2018 at 7:42 AM Paul Smith  wrote:

> Hi all.
>
> I'm using cmake with a cross-compiler environment, but building third
> party packages that are configured with CMake.  So when I invoke cmake
> for those packages I add this options to the command line:
>
>   -DCMAKE_FIND_ROOT_PATH=/my/sysroot
>
> However, this is not working because it's finding 32bit libraries.  For
> example if the package's CMakeLists.txt file contains this:
>
>   find_package(ZLIB REQUIRED)
>
> then my link line ends up containing:
>
>   /my/sysroot/usr/lib/libz.so
>
> which is the 32bit version and the link fails.  The 64bit version DOES
> exist exactly as it should:
>
>   $ ls -1 /my/sysroot/usr/lib*/libz.so*
>   /my/sysroot/tools/usr/lib/libz.so
>   /my/sysroot/tools/usr/lib64/libz.so
>
> and the link works if I do it by hand with the right path.  I don't
> know why it's not automatically looking for lib64; I checked and CMake
> knows I want a 64bit build.  For example I see this after running:
>
>   CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR
> "8")
>
> Actually I wish cmake would just add "-lz" to the command line and let
> the linker figure it all out rather than trying to second-guess things.
> Then it would "just work".
>
> In any event, if I edit the CMakeLists.txt in the package to set the
> global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works
> fine:
>
>   set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)
>
> But I can't see any way to set that property from the command line,
> without editing the package's CMakeLists.txt file which I obviously
> don't want to do.
>
> Help for either (a) figuring out why cmake incorrectly chooses 32bit
> libraries or (b) setting the property without editing third-party
> CMakeLists.txt files would be much appreciated!!
>


If you are setting your own sysroot, are you using a toolchain file? You
could put your set_property() command in your toolchain file if you're
using one.

If you're not using a toolchain file and don't want to go that route, you
could potentially inject the commands you want using the
CMAKE_PROJECT__INCLUDE

feature. It allows you to effectively include a file immediately after a
project() command without having to actually edit the CMakeLists.txt that
contains that project() command.

Those techniques aside, it's interesting that you need to add this manual
workaround at all. I suspect this code

might be why it is being turned off for you, but without more detail about
your build setup, it's hard to say. If you use a toolchain file and set
CMAKE_SYSTEM_NAME to anything (even the same as the
CMAKE_HOST_SYSTEM_NAME), CMAKE_CROSSCOMPILING will be TRUE, which I suspect
would prevent the problem you're seeing.

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

New book released: Professional CMake: A Practical Guide

-- 

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-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

Le lun. 17 déc. 2018 à 22:04, Eric Noulard  a
écrit :

> Hi Kyle,
>
> Is your proposal a follow-up on the initial bunch of ideas launched in
> this thread launch by Eike in November
> https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
> with follow-up ideas in in december:
> https://cmake.org/pipermail/cmake-developers/2018-December/030920.html
>
> or is it somehow unrelated?
>
>
> Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
> cmake-developers@cmake.org> a écrit :
>
>> Hello everyone,
>>
>> One of the things that's long been requested of CMake is the ability to
>> have multiple toolchains - for instance, one host toolchain and one
>> cross toolchain, so that "utilities" needed for build can be built with
>> the host toolchain and then the "real" software can be built with the
>> cross toolchain.
>>
>> To solve this problem, I would like to propose the creation of a new
>> first-class object type, the "toolchain" type, which would replace the
>> current variable-based system, similar to how imported targets replaced
>> variable-based usage requirements.
>>
>> Every project would automatically receive one toolchain, the "DEFAULT"
>> toolchain, which would be either automatically configured or configured
>> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
>> toolchains could be added with the add_toolchain() command:
>>
>> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>>
>
> This has some common design issue as my proposal:
> enable_cross_target(...)
> for which Eike has valuable doubt:
> https://cmake.org/pipermail/cmake-developers/2018-November/030919.html
>
>
>> Then, executables and libraries could have a toolchain specified:
>>
>> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Note that the TOOLCHAIN argument is optional, and if omitted, the
>> DEFAULT toolchain is used.
>>
>
> So if you want to build both for host and cross toolchain you'll have to
> explicitely
> add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
>
> If you follow the previously referred discussion you cannot assume that
> one lib/exe
> built for a toolchain is not built for another toolchain as well.
>
> How do you envision the cross-toolchain target dependency which was
> a question raised several time.
>
>
>> If a project uses multiple toolchains, we could have the option to
>> rename the default toolchain with an alternative add_toolchain()
>> syntax:
>>
>> add_toolchain(HostToolchain DEFAULT)
>>
>> Rather than adding a new toolchain, this would simply rename the
>> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
>> specification for each target could look like this:
>>
>> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
>> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>>
>> Two new global read-only properties would be added: TOOLCHAINS and
>> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
>> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
>> the DEFAULT toolchain (which could be changed with the alternative
>> add_toolchain() syntax.)
>>
>> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
>> setting variables:
>>
>> set(CMAKE_C_COMPILER /usr/bin/gcc)
>> set(CMAKE_C_COMPILER_ID gnu)
>> # etc.
>>
>> it would instead set properties on the selected toolchain:
>>
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
>> /usr/bin/gcc)
>> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
>> C_COMPILER_ID gnu)
>> # etc.
>>
>
> I don't see why we should change the syntax of current toolchain file, I
> don't see the benefit.
> CMake already knows when (and which) toolchain file is loaded and it could
> perfectly automatically
>

... sorry wrong key pressed...

CMake could perfectly automatically create the new "TOOLCHAIN" object by
loading the very
same toolchain file as we have today. We could simple add a new variable
CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name
them as he wants.
When there is no CMAKE_TOOLCHAIN_NAME this would be the default toolchain.


-- 
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-developers

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Eric Noulard]

Hi Kyle,

Is your proposal a follow-up on the initial bunch of ideas launched in this
thread launch by Eike in November
https://cmake.org/pipermail/cmake-developers/2018-November/030913.html
with follow-up ideas in in december:
https://cmake.org/pipermail/cmake-developers/2018-December/030920.html

or is it somehow unrelated?


Le lun. 17 déc. 2018 à 21:18, Kyle Edwards via cmake-developers <
cmake-developers@cmake.org> a écrit :

> Hello everyone,
>
> One of the things that's long been requested of CMake is the ability to
> have multiple toolchains - for instance, one host toolchain and one
> cross toolchain, so that "utilities" needed for build can be built with
> the host toolchain and then the "real" software can be built with the
> cross toolchain.
>
> To solve this problem, I would like to propose the creation of a new
> first-class object type, the "toolchain" type, which would replace the
> current variable-based system, similar to how imported targets replaced
> variable-based usage requirements.
>
> Every project would automatically receive one toolchain, the "DEFAULT"
> toolchain, which would be either automatically configured or configured
> based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
> toolchains could be added with the add_toolchain() command:
>
> add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
>

This has some common design issue as my proposal:
enable_cross_target(...)
for which Eike has valuable doubt:
https://cmake.org/pipermail/cmake-developers/2018-November/030919.html


> Then, executables and libraries could have a toolchain specified:
>
> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Note that the TOOLCHAIN argument is optional, and if omitted, the
> DEFAULT toolchain is used.
>

So if you want to build both for host and cross toolchain you'll have to
explicitely
add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)

If you follow the previously referred discussion you cannot assume that one
lib/exe
built for a toolchain is not built for another toolchain as well.

How do you envision the cross-toolchain target dependency which was
a question raised several time.


> If a project uses multiple toolchains, we could have the option to
> rename the default toolchain with an alternative add_toolchain()
> syntax:
>
> add_toolchain(HostToolchain DEFAULT)
>
> Rather than adding a new toolchain, this would simply rename the
> "DEFAULT" toolchain to "HostToolchain". Then the toolchain
> specification for each target could look like this:
>
> add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
>
> Two new global read-only properties would be added: TOOLCHAINS and
> DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
> all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
> the DEFAULT toolchain (which could be changed with the alternative
> add_toolchain() syntax.)
>
> The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
> setting variables:
>
> set(CMAKE_C_COMPILER /usr/bin/gcc)
> set(CMAKE_C_COMPILER_ID gnu)
> # etc.
>
> it would instead set properties on the selected toolchain:
>
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
> /usr/bin/gcc)
> set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
> C_COMPILER_ID gnu)
> # etc.
>

I don't see why we should change the syntax of current toolchain file, I
don't see the benefit.
CMake already knows when (and which) toolchain file is loaded and it could
perfectly automatically


>
> where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
> file either at the root or by the add_toolchain() command.
>
> If you want to read the value of C_COMPILER, etc. then just use
> get_property():
>
> get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)
>
> Obviously this system would scale well to more than just two toolchains
> - just use as many add_toolchain() commands as you need.
>
> Backwards compatibility is going to be a challenge. Both the toolchain
> file and the project have to be aware of the new toolchain system,
> which means we have to handle four permutations:
>
> 1) old toolchain + old project
> 2) old toolchain + new project
> 3) new toolchain + old project
> 4) new toolchain + new project
>
> I propose adding a policy that both the toolchain file and the project
> can set separately, and which would have a slightly different meaning
> in each one. If the toolchain is OLD and the project is NEW, then the
> variables set by the toolchain file would be converted into properties
> on the toolchain for the project. If the toolchain is NEW and the
> project is OLD, then the properties on the toolchain would be converted
> into variables in the project. If both the toolchain and project have
> the same value, then no special 

[CMake] Using ninja with imported libraries not working (Windows)

[Brendan Heinonen]

I've been struggling to use ninja-generator with imported libraries in
CMake on Windows.  The issue started when I moved some third-party code in
the project to an external project using find_package.  I have since
reduced the issue to a minimally reproducible example:

add_library(foo STATIC IMPORTED)
set_property(TARGET foo PROPERTY IMPORTED_LOCATION E:/path/to/foo.lib)
target_link_libraries(bar foo)

This produces a Ninja error:

ninja : error : 'E:/path/to/foo.lib', needed by 'bar', missing and no known
rule to make it

I should note that the path to the lib exists, and in fact, this config
works on other generators, such as NMake and Unix Makefiles.

The issue is "fixed" upon manually editing build.ninja and removing this
from the bar link target:

E$:/path/to/foo.lib

What's the deal?  Am I missing something?  Any help would be appreciated.

-- 
*Brendan Heinonen*
-- 

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.11.3: set properties on the command line?

[Paul Smith]

Hi all.

I'm using cmake with a cross-compiler environment, but building third
party packages that are configured with CMake.  So when I invoke cmake
for those packages I add this options to the command line:

  -DCMAKE_FIND_ROOT_PATH=/my/sysroot

However, this is not working because it's finding 32bit libraries.  For
example if the package's CMakeLists.txt file contains this:

  find_package(ZLIB REQUIRED)

then my link line ends up containing:

  /my/sysroot/usr/lib/libz.so

which is the 32bit version and the link fails.  The 64bit version DOES
exist exactly as it should:

  $ ls -1 /my/sysroot/usr/lib*/libz.so*
  /my/sysroot/tools/usr/lib/libz.so
  /my/sysroot/tools/usr/lib64/libz.so

and the link works if I do it by hand with the right path.  I don't
know why it's not automatically looking for lib64; I checked and CMake
knows I want a 64bit build.  For example I see this after running:

  CMakeFiles/3.11.3/CMakeCXXCompiler.cmake:set(CMAKE_CXX_SIZEOF_DATA_PTR "8")

Actually I wish cmake would just add "-lz" to the command line and let
the linker figure it all out rather than trying to second-guess things.
Then it would "just work".

In any event, if I edit the CMakeLists.txt in the package to set the
global property FIND_LIBRARY_USE_LIB64_PATHS to ON, then it all works
fine:

  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)

But I can't see any way to set that property from the command line,
without editing the package's CMakeLists.txt file which I obviously
don't want to do.

Help for either (a) figuring out why cmake incorrectly chooses 32bit
libraries or (b) setting the property without editing third-party
CMakeLists.txt files would be much appreciated!!

-- 

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] Modern cmake advise for transitive library dependencies

[Mario Emmenlauer]

Dear cmake team and user community,

I'd kindly like to ask for advice on how to handle transitive
dependencies cleanly with "modern" cmake. I'm often plagued by this
problem: I have a library X that optionally depends on library A.
When I build library Y that depends on X, how do I (cleanly) handle
the optional dependency A?
Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core.
But when I import X into Y, then Y will complain about unknown target
Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since
Qt is optional in X, I would need to track somehow if Qt was enabled
before.

But what good is the public transitive dependency when I manually need
to track it, to find the libraries again? Am I missing something?
Can the dependency be automatically resolved, or can I query some
variable if X was linking A?

How to do this cleanly?

Thanks a lot and all the best,

Mario Emmenlauer
--

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] Idea for Multi-Toolchain Support

[Kyle Edwards via cmake-developers]

Hello everyone,

One of the things that's long been requested of CMake is the ability to
have multiple toolchains - for instance, one host toolchain and one
cross toolchain, so that "utilities" needed for build can be built with
the host toolchain and then the "real" software can be built with the
cross toolchain.

To solve this problem, I would like to propose the creation of a new
first-class object type, the "toolchain" type, which would replace the
current variable-based system, similar to how imported targets replaced
variable-based usage requirements.

Every project would automatically receive one toolchain, the "DEFAULT"
toolchain, which would be either automatically configured or configured
based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
toolchains could be added with the add_toolchain() command:

add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)

Then, executables and libraries could have a toolchain specified:

add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)

Note that the TOOLCHAIN argument is optional, and if omitted, the
DEFAULT toolchain is used.

If a project uses multiple toolchains, we could have the option to
rename the default toolchain with an alternative add_toolchain()
syntax:

add_toolchain(HostToolchain DEFAULT)

Rather than adding a new toolchain, this would simply rename the
"DEFAULT" toolchain to "HostToolchain". Then the toolchain
specification for each target could look like this:

add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)

Two new global read-only properties would be added: TOOLCHAINS and
DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
the DEFAULT toolchain (which could be changed with the alternative
add_toolchain() syntax.)

The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
setting variables:

set(CMAKE_C_COMPILER /usr/bin/gcc)
set(CMAKE_C_COMPILER_ID gnu)
# etc.

it would instead set properties on the selected toolchain:

set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
/usr/bin/gcc)
set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
C_COMPILER_ID gnu)
# etc.

where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
file either at the root or by the add_toolchain() command.

If you want to read the value of C_COMPILER, etc. then just use
get_property():

get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)

Obviously this system would scale well to more than just two toolchains
- just use as many add_toolchain() commands as you need.

Backwards compatibility is going to be a challenge. Both the toolchain
file and the project have to be aware of the new toolchain system,
which means we have to handle four permutations:

1) old toolchain + old project
2) old toolchain + new project
3) new toolchain + old project
4) new toolchain + new project

I propose adding a policy that both the toolchain file and the project
can set separately, and which would have a slightly different meaning
in each one. If the toolchain is OLD and the project is NEW, then the
variables set by the toolchain file would be converted into properties
on the toolchain for the project. If the toolchain is NEW and the
project is OLD, then the properties on the toolchain would be converted
into variables in the project. If both the toolchain and project have
the same value, then no special conversion is required.

I would welcome everyone's feedback on this proposal. Obviously this is
a big change to how CMake handles toolchains, and would require a lot
of very deep refactoring.

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-developers

Re: [CMake] Tracking progress of CMake TAR

[Eric Noulard]

Le lun. 17 déc. 2018 à 18:00, Person Withhats  a
écrit :

> I guess for now, anything that'll get it to work on Windows? That's the
> primary platform for this.
>

If you give up on portability then replace cmake -E tar with an external
program which has progress capability on Windows.
It looks like 7-zip can do that:
see: https://sevenzip.osdn.jp/chm/cmdline/switches/bs.htm
or: https://sourceforge.net/p/sevenzip/discussion/45797/thread/d10225f7/

I don't work on Windows those day so I won't be able to try it out.

Eric


>
> On Mon, Dec 17, 2018 at 8:53 AM Eric Noulard 
> wrote:
>
>>
>> Le lun. 17 déc. 2018 à 17:17, Person Withhats 
>> a écrit :
>>
>>> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of
>>> files is going to help.
>>>
>>
>> Yes right.
>> You need some "size extraction progress" not number of files progress.
>>
>> I'm not sure classical un-archive program do have the feature.
>>
>> I'm pretty sure that "working progress bar" is most of the time very
>> difficult to implement:
>>
>> https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful
>>
>> I was hoping for some sort of progress bar or the like,
>>>
>>
>> I'm pretty sure cmake -E tar does not have this feature.
>> Genuine unix tar command does not have such feature and some people uses
>> 'pv' (http://www.ivarch.com/programs/pv.shtml)
>> for that very same purpose
>> e.g.
>> https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file
>>
>> I guess the issue is the same for other archive tool including zip:
>> https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress
>>
>> CMake is using libarchive for handling various archive files (including
>> tar) libarchive seems to have
>> some feature for progress display (
>> https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3)
>> but CMake code is not using it in any way.
>>
>>
>>> and yes I'm using cmake -E tar .-.
>>>
>>> Any ideas?
>>>
>>
>> Beside non-portable way no.
>>
>>
>>>
>>> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard 
>>> wrote:
>>>
 I guess he is using

 cmake -E tar

 may be using 'v' verbose option from tar  should be enough.

 i.e.
 cmake -E tar xvz your-archive.tar.gz

 It should display file names as they come out of the archive.
 So unless your very big archive only contains relatively big files, the
 output should evolve quite often.

 Eric


 Le lun. 17 déc. 2018 à 15:46, Ian Cullen 
 a écrit :

> Are you calling tar via a custom command?  tar itself looks to have a
> few options to print progress:
>
> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>
> Although none of the options seem to know the archive's size, so
> aren't able to print a completion percentage.
>
>
> On 16/12/2018 21:31, Person Withhats wrote:
>
> When running tar via CMake (in order to use cross-platform
> work-ability and what not) it'd be great to have a progress bar of any
> sort.
>
> It's awkward to wait 30-60 minutes for file untarring with absolutely
> 0 information. I'm not aware of any way to do this through CMake directly,
> only alternative is e.g. python script that does the untar for me.
>
> Any suggestions? (sorry if this is reposted, can't remember if acc was
> approved before or after sending one time)
>
>
> --
>
> 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
>


 --
 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

>>>
>>
>> --
>> Eric
>>
>

-- 
Eric
-- 

Powered by www.kitware.com

Re: [CMake] Tracking progress of CMake TAR

[Eric Noulard]

Le lun. 17 déc. 2018 à 17:17, Person Withhats  a
écrit :

> It's untarring around 1.5GB of SDK's, I don't think listing 1000's of
> files is going to help.
>

Yes right.
You need some "size extraction progress" not number of files progress.

I'm not sure classical un-archive program do have the feature.

I'm pretty sure that "working progress bar" is most of the time very
difficult to implement:
https://ux.stackexchange.com/questions/11881/progress-bars-why-are-they-never-useful

I was hoping for some sort of progress bar or the like,
>

I'm pretty sure cmake -E tar does not have this feature.
Genuine unix tar command does not have such feature and some people uses
'pv' (http://www.ivarch.com/programs/pv.shtml)
for that very same purpose
e.g.
https://superuser.com/questions/168749/is-there-a-way-to-see-any-tar-progress-per-file

I guess the issue is the same for other archive tool including zip:
https://askubuntu.com/questions/909918/q-how-to-show-unzip-progress

CMake is using libarchive for handling various archive files (including
tar) libarchive seems to have
some feature for progress display (
https://github.com/libarchive/libarchive/wiki/ManPageArchiveReadExtract3)
but CMake code is not using it in any way.


> and yes I'm using cmake -E tar .-.
>
> Any ideas?
>

Beside non-portable way no.


>
> On Mon, Dec 17, 2018 at 7:16 AM Eric Noulard 
> wrote:
>
>> I guess he is using
>>
>> cmake -E tar
>>
>> may be using 'v' verbose option from tar  should be enough.
>>
>> i.e.
>> cmake -E tar xvz your-archive.tar.gz
>>
>> It should display file names as they come out of the archive.
>> So unless your very big archive only contains relatively big files, the
>> output should evolve quite often.
>>
>> Eric
>>
>>
>> Le lun. 17 déc. 2018 à 15:46, Ian Cullen  a
>> écrit :
>>
>>> Are you calling tar via a custom command?  tar itself looks to have a
>>> few options to print progress:
>>>
>>> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>>>
>>> Although none of the options seem to know the archive's size, so aren't
>>> able to print a completion percentage.
>>>
>>>
>>> On 16/12/2018 21:31, Person Withhats wrote:
>>>
>>> When running tar via CMake (in order to use cross-platform work-ability
>>> and what not) it'd be great to have a progress bar of any sort.
>>>
>>> It's awkward to wait 30-60 minutes for file untarring with absolutely 0
>>> information. I'm not aware of any way to do this through CMake directly,
>>> only alternative is e.g. python script that does the untar for me.
>>>
>>> Any suggestions? (sorry if this is reposted, can't remember if acc was
>>> approved before or after sending one time)
>>>
>>>
>>> --
>>>
>>> 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
>>>
>>
>>
>> --
>> 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
>>
>

-- 
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] DEPFILE usage in add_custom_command(...)

[Ed Branch]

The target name in the depfile does not match the target name on the 
ninja build line due to absolute vs relative path mismatch. Even though 
they refer to the same file, the target names must match exactly.

--

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] dependencies on system include files

[David Blaikie]

If you're willing to run a different command or flag when rebuilding after
upgrading system libraries, I would guess the thing to do would be to do a
clean and rebuild, perhaps?

On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans  Hi all
>
>
>
> I’ve just had a problem caused by an upgrade of my system files (in this
> particular case: boost). Rebuilding our software didn’t correctly rebuild
> those files that depend on the updated boost files. (I’m using CMake 3.9
> with make on Ubuntu 16.04)
>
>
>
> Checking a bit more carefully it appears that the system .h files are not
> included in depend.make. I guess this is done to save some time checking
> all those dependencies as system files are supposed to be relatively
> stable, but if they’re not, it creates trouble of course.
>
>
>
> Is there any way to change this behaviour? (ideally something like for one
> time only, check if dependent system include files are more recent then
> what was compiled, but that’s a stretch of course).
>
>
>
> Thanks
>
>
>
> Kris
>
>
>
>
>
>
> --
>
> 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] Tracking progress of CMake TAR

[Eric Noulard]

I guess he is using

cmake -E tar

may be using 'v' verbose option from tar  should be enough.

i.e.
cmake -E tar xvz your-archive.tar.gz

It should display file names as they come out of the archive.
So unless your very big archive only contains relatively big files, the
output should evolve quite often.

Eric


Le lun. 17 déc. 2018 à 15:46, Ian Cullen  a
écrit :

> Are you calling tar via a custom command?  tar itself looks to have a few
> options to print progress:
>
> https://www.gnu.org/software/tar/manual/html_section/tar_25.html
>
> Although none of the options seem to know the archive's size, so aren't
> able to print a completion percentage.
>
>
> On 16/12/2018 21:31, Person Withhats wrote:
>
> When running tar via CMake (in order to use cross-platform work-ability
> and what not) it'd be great to have a progress bar of any sort.
>
> It's awkward to wait 30-60 minutes for file untarring with absolutely 0
> information. I'm not aware of any way to do this through CMake directly,
> only alternative is e.g. python script that does the untar for me.
>
> Any suggestions? (sorry if this is reposted, can't remember if acc was
> approved before or after sending one time)
>
>
> --
>
> 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
>


-- 
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] Tracking progress of CMake TAR

[Ian Cullen]

Are you calling tar via a custom command?  tar itself looks to have a 
few options to print progress:


https://www.gnu.org/software/tar/manual/html_section/tar_25.html

Although none of the options seem to know the archive's size, so aren't 
able to print a completion percentage.



On 16/12/2018 21:31, Person Withhats wrote:
When running tar via CMake (in order to use cross-platform 
work-ability and what not) it'd be great to have a progress bar of any 
sort.


It's awkward to wait 30-60 minutes for file untarring with absolutely 
0 information. I'm not aware of any way to do this through CMake 
directly, only alternative is e.g. python script that does the untar 
for me.


Any suggestions? (sorry if this is reposted, can't remember if acc was 
approved before or after sending one time)




-- 

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] dependencies on system include files

[Simon Richter]

Hi Kris,

On 17.12.18 01:24, Kris Thielemans wrote:

> Checking a bit more carefully it appears that the system .h files are
> not included in depend.make. I guess this is done to save some time
> checking all those dependencies as system files are supposed to be
> relatively stable, but if they’re not, it creates trouble of course.

> Is there any way to change this behaviour? (ideally something like for
> one time only, check if dependent system include files are more recent
> then what was compiled, but that’s a stretch of course).

The problem is: that wouldn't help, as most package managers install
files with timestamps from packages rather than their installation time.

   Simon



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