[Cmake-commits] CMake branch, master, updated. v3.13.0-547-g049ca05

[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  049ca05da93ef7f6fced82a88069a382c6008ebf (commit)
  from  f49efe283ed005aac642f5af58ea971d468de88c (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=049ca05da93ef7f6fced82a88069a382c6008ebf
commit 049ca05da93ef7f6fced82a88069a382c6008ebf
Author: Kitware Robot 
AuthorDate: Wed Nov 28 00:01:05 2018 -0500
Commit: Kitware Robot 
CommitDate: Wed Nov 28 00:01:05 2018 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 63a1573..93aad21 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 20181127)
+set(CMake_VERSION_PATCH 20181128)
 #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

[CMake] Subdirectory can't find library made by another subdir

[Manh Nguyen Tien]

Hi everyone, I'm having a bug on CMake 3.12 (version and syntax).

Here is my structure.


RootFolder

    CMakeLists.txt (C1)

    library/

        CMakeLists.txt (C2)

    samples/

        CMakeLists.txt (C3)


In my C1, I add subdir library and samples. C2 builds a library target
(LIB).

My problem is that C3 can't find my LIB or my LIB's configuration is not
visible.

This code in C3 doesn't produce any warnings:

target_link_libraries(sample1
  PRIVATE LIB
)


When building sample1, my compiler couldn't find LIB's headers.

I declared those headers for my LIB using target_sources command (PUBLIC
and INTERFACE).

Here is how I create the LIB:

- Add LIB_OBJ library (object library)

- target_sources for header and source files

- target_include_directories

- target_link_libraries for LIB's dependencies

- add a static library LIB_STATIC

- link LIB_STATIC with LIB_OBJ

- create an alias LIB of LIB_STATIC


My full source code is at:
https://gitlab.com/InnerPieceOSS/Saga3D/tree/android

To reproduce:

- Clone project

- Checkout branch android

- mkdir build && cd build

- cmake .. -DBUILD_SAMPLES=ON

- make -j4


Could you help me to identify the problem?
Thank you!

Manh Nguyen Tien.


-- 

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] Does CMake support the --question option for GNU Makefiles?

[Alex Tzonkov]

Thanks for the quick response it makes more sense now. Looking at our CMake
files, I see now that all our targets are indeed PHONY, because we use
*add_custom_target
*to create those targets. So no matter what they are always considered out
of date. For now I'll have to assume that whoever wrote the CMake files had
a good reason for doing that. Is that considered a recommend way to set up
a project, or perhaps each and every project is unique so it does not make
sense to even have a recommendation?

On Tue, Nov 27, 2018 at 12:06 PM frodak  wrote:

> I think this is just a misunderstanding and not related to CMake.
>
> Make --question mode always returns a 1 if the target is PHONY because
> these targets are always out of date.
> The Makefiles generated by CMake use a top level PHONY target (and other
> PHONY targets as well)
>
> zzz@i7-lab:~/temp/bldlibvnc$ make -q
> CMakeFiles/vncserver.dir/libvncserver/zrleoutstream.c.o
> zzz@i7-lab:~/temp/bldlibvnc$ echo $?
> 0
> zzz@i7-lab:~/temp/bldlibvnc$ make -q
> zzz@i7-lab:~/temp/bldlibvnc$ echo $?
> 1
>
> OR
>
> zzz@i7-lab:~/temp/bldlibvnc$ make -q vncclient
> zzz@i7-lab:~/temp/bldlibvnc$ echo $?
> 1
> zzz@i7-lab:~/temp/bldlibvnc$ make -q libvncclient.so
> zzz@i7-lab:~/temp/bldlibvnc$ echo $?
> 0
>
> So you'll need to discern the actual target you want to check.
>
> Best regards...
>
> On Tue, Nov 27, 2018 at 11:51 AM Alex Tzonkov 
> wrote:
>
>> We are using cmake for our project and recently discovered that the
>> generated Makefiles do not seem to work correctly with the '--question' or
>> '-q' option. The return code is always '1' even if there are no changes
>> which would require rebuilding/recompiling anything. I am not sure if this
>> is an issue with our CmakeLists.txt files or *.cmake files or a general
>> issue with cmake. Any pointers would be greatly appreciated.
>>
>> I apologize if this is an answered question, I tried really hard to
>> search the archives, but searching for "--question" is futile, as the
>> searches return pretty much every 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
>>
>
-- 

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] Can an option enforce a default, even if cache is present?

[frodak]

On Tue, Nov 27, 2018 at 3:15 PM Mario Emmenlauer  wrote:
>
> On 27.11.18 17:13, Eric Noulard wrote:
> > Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer  > > a écrit :
> > Dear all,
> >
> > I've just discovered that option() behaves differently than I 
> > anticipated.
> > After reading the docs and searching with google I'm still confused how 
> > to
> > achieve my desired behaviour.
> >
> > What I've just learned is that unspecified options take their cached 
> > value
> > and do *not* go back to their default value, if a cache exists. I 
> > assumed
> > that options take their default when not explicitly specified.
> >
> >
> > The behavior of option() gained new behavior in CMake 3.13.
> > May be it could help in your particular case:
> > https://cmake.org/cmake/help/v3.13/policy/CMP0077.html#policy:CMP0077
> >
> > you'll depend on latest CMake though.
> >
> >
> > Now my problem: I could not find a way to get the behaviour I'd like. 
> > Is it
> > possible to enforce the default for an option when its not specified by 
> > the
> > user, even if a cache exists?
> >
> >
> > You mean you did not manage to force the cache value?
> > You can:
> > set(VAR "default_value" CACHE FORCE)
> >
> > or the problem is you cannot know whether if a value has been user-provided?
>
> Sorry, I was not very precise! Your last point is the problem. I fail to know
> when the option was user-provided and when it was cache-provided.
>
> So here is what I'd like:
>
> #> grep MYOPT CMakeLists.txt
> option(MYOPT "Description" OFF)
> #> cmake  # I want the option disabled, this works fine.
> #> cmake -DMYOPT=ON   # I want the option enabled, this works fine.
> #> cmake  # I want the option disabled (back to default),
># but I observe the option taken from cache, enabled.
>
> Is there some way to achieve my desired behaviour? I tried without success
> unset(MYOPT), unset(MYOPT CACHE), and set(MYOPT OFF) before option(), but
> they all lead to different behaviour.
>

I've always used 'cmake -UMYOPT'  to remove specific items from the
cache (or edit the cache file directly).
I don't think the notion of user-provided or cache-provided entries
exist because all user defined variables go into the cache.
Then you can test to see if MYOPT is set and then use the default
value when recreating the cache entry.
Also cmake cache variables are persistent between invocations so the
user doesn't need to keep specifying them at the command line every
time cmake needs to run.

Best regards...
-- 

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] Can an option enforce a default, even if cache is present?

[Mario Emmenlauer]

On 27.11.18 17:13, Eric Noulard wrote:
Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer > a écrit :

Dear all,

I've just discovered that option() behaves differently than I anticipated.
After reading the docs and searching with google I'm still confused how to
achieve my desired behaviour.

What I've just learned is that unspecified options take their cached value
and do *not* go back to their default value, if a cache exists. I assumed
that options take their default when not explicitly specified.


The behavior of option() gained new behavior in CMake 3.13.
May be it could help in your particular case: 
https://cmake.org/cmake/help/v3.13/policy/CMP0077.html#policy:CMP0077


you'll depend on latest CMake though.


Now my problem: I could not find a way to get the behaviour I'd like. Is it
possible to enforce the default for an option when its not specified by the
user, even if a cache exists?


You mean you did not manage to force the cache value?
You can:
set(VAR "default_value" CACHE FORCE)

or the problem is you cannot know whether if a value has been user-provided?


Sorry, I was not very precise! Your last point is the problem. I fail to know
when the option was user-provided and when it was cache-provided.

So here is what I'd like:

#> grep MYOPT CMakeLists.txt
option(MYOPT "Description" OFF)
#> cmake  # I want the option disabled, this works fine.
#> cmake -DMYOPT=ON   # I want the option enabled, this works fine.
#> cmake  # I want the option disabled (back to default),
  # but I observe the option taken from cache, enabled.

Is there some way to achieve my desired behaviour? I tried without success
unset(MYOPT), unset(MYOPT CACHE), and set(MYOPT OFF) before option(), but
they all lead to different behaviour.

All the best,

Mario

--

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] Does CMake support the --question option for GNU Makefiles?

[frodak]

I think this is just a misunderstanding and not related to CMake.

Make --question mode always returns a 1 if the target is PHONY because
these targets are always out of date.
The Makefiles generated by CMake use a top level PHONY target (and other
PHONY targets as well)

zzz@i7-lab:~/temp/bldlibvnc$ make -q
CMakeFiles/vncserver.dir/libvncserver/zrleoutstream.c.o
zzz@i7-lab:~/temp/bldlibvnc$ echo $?
0
zzz@i7-lab:~/temp/bldlibvnc$ make -q
zzz@i7-lab:~/temp/bldlibvnc$ echo $?
1

OR

zzz@i7-lab:~/temp/bldlibvnc$ make -q vncclient
zzz@i7-lab:~/temp/bldlibvnc$ echo $?
1
zzz@i7-lab:~/temp/bldlibvnc$ make -q libvncclient.so
zzz@i7-lab:~/temp/bldlibvnc$ echo $?
0

So you'll need to discern the actual target you want to check.

Best regards...

On Tue, Nov 27, 2018 at 11:51 AM Alex Tzonkov 
wrote:

> We are using cmake for our project and recently discovered that the
> generated Makefiles do not seem to work correctly with the '--question' or
> '-q' option. The return code is always '1' even if there are no changes
> which would require rebuilding/recompiling anything. I am not sure if this
> is an issue with our CmakeLists.txt files or *.cmake files or a general
> issue with cmake. Any pointers would be greatly appreciated.
>
> I apologize if this is an answered question, I tried really hard to search
> the archives, but searching for "--question" is futile, as the searches
> return pretty much every 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
>
-- 

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] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

Re: [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 27 nov. 2018 à 11:28, Rolf Eike Beer  a écrit :

> Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
>
I do agree with that quote I was quite surprised (a long time ago) that
CMake did not support cross-compiling.
Back then I was using recursive hand-written makefiles for cross-compiling.
When I wanted to build
the whole thing I only had to hit "make" and wait.

Moreover I think CMake cross-compiling support was biased by the fact CMake
wasn't designed for that initially.
Please don't take my remark as bare criticism I am using CMake for a long
time now, I do like CMake very much
and I was pleased to see the cross-compiling support coming.

However from my point of view and my cross-compiling experience when you
cross-compile you have:

1) the host compiler which is used to compile "host tools"
2) the target compiler (may be several of them) to "cross-compile"

My assumption are:
 a) when you cross-compile your build is a "whole" and you shouldn't have
to setup some superbuild
   structure for building host tools ht_exe and another for target1 tool
t1t_exe and another one for target2 tool t2t_exe.

 b) what you want is to build:
 ht_exe for the host
 possibly use ht_exe during the build to generate some [source] file
 t1t_exe for the [cross]target1
 t2t_exe for the [cross]target2

 c)  you seldomly compile the same source for the host AND the target, but
it may happen.

And you want to build all that stuff with a single configure+build command
AND take advantage
of fast and efficient parallel build for the **whole build**. I don't want
to

cd /build/for/host
ninja
cd /build/for/target1
ninja
etc...



>  Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>

I get your point but I think we may try a more declarative way.

add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)

set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1")
set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1")

after that we know that `magic` is to be built both for "host" and
"cross_target1" whereas
`foo` is only for "cross_target1".

before that we may have to "declaratively" define what is cross_target1
(and may be cross_target2) with something like:

enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target1-toolchain.cmake)
enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE
_DIR}/cmake/target2-toolchain.cmake)
and assume "host" builtin target is the one coming from the command line.

each define_cross_target(..) will create a separate subdir in the build
tree (much like CMAKE_CFG_INTDIR is working for multi-config 

[CMake] Does CMake support the --question option for GNU Makefiles?

[Alex Tzonkov]

We are using cmake for our project and recently discovered that the
generated Makefiles do not seem to work correctly with the '--question' or
'-q' option. The return code is always '1' even if there are no changes
which would require rebuilding/recompiling anything. I am not sure if this
is an issue with our CmakeLists.txt files or *.cmake files or a general
issue with cmake. Any pointers would be greatly appreciated.

I apologize if this is an answered question, I tried really hard to search
the archives, but searching for "--question" is futile, as the searches
return pretty much every 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] dependencies of cross compiliations

[Miller Henry]

I like the idea, some tweaks that I think you need

add_host_build - executables built here need to be available not as targets, 
but as variables as if FIND_EXECUTABLE was called on them. This is probably 
what you meant, but it didn't come across that way.

In the case where you are cross compiling for more than one target it would be 
useful if you could build the host tools once and then use that build in 
multiple target builds. There are two different workflows for this: building 
locally where the host build directory just needs to be shared (how?); building 
on a CI system where you want to build/package the host tools and then send the 
package to downstream jobs.  In my opinion this second workflow is the more 
important one to have work. 

I would suggest that it work something like this: A new option 
-DCMAKE_HOST_TOOLS_BUILD_DIR which if set will specify the directory to find 
host tools in - if this directory already has a built use, the tools already 
built there (of course re-run that build as required on source changes); 
otherwise configure and build host tools in that directory.  If this options is 
NOT specified first run find_package to see if a cmake config file can be found 
for the correct version of host tools - if so use them (I think we only want to 
support cmake config files not the other options find_package looks for), it is 
the users responsibility to update the installed tools if the source changes.  
If all of the above fails fall back to some directory under the build directory 
(as you proposed?).

The above also solves the problem of what if you want to pass a ton of options 
to the host build.  Adding overrides to cmake options for host vs target (ie 
-DHOST_CMAKE_BUILD_TYPE) gets out of hand quickly, both from the developer that 
has to write all the cmake options and also the user who has to maintain long 
command lines.  

Keep in mind there are some projects where the above cannot work.  I know of 
one program where the host tool creates data packed for the specific CPU 
(endian and bits in an int) and so you cannot share then host build. This 
project doesn't support cross compiling the host tool so I run it under QEMU, 
but you can imagine it being properly supported in the future and so 
add_host_build may need to have something to indicate the target to build the 
host tool for.

Just some thoughts. Since I'm not doing the work I don't get to tell you how to 
do it.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer
Sent: Tuesday, November 27, 2018 4:28 AM
To: cmake@cmake.org
Cc: cmake-develop...@cmake.org
Subject: Re: [CMake] dependencies of cross compiliations

Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> Hi,
> I hope this question was not asked before. I work in the embedded 
> field and there it is usually to have at least two different build 
> platforms. The Host platform, where unit tests are build (and where 
> CMake is running) and an embedded Target platform, where targets are 
> build with a cross compiler. Sometimes such a system comes with 
> self-written tools that are build and run on the Host platform to 
> build a target for the embedded Target platform (adding meta data to a 
> binary to be used by a bootloader for example).
> 
> Usually I have two different build folders, one for the Host platform 
> and one for the Target platform, using different calls to cmake to 
> choose from a set of tools and targets. But when using this approach, 
> it is necessary that the Host platform build ran before the Target 
> platform build, so that tools that are required for the Target 
> platform are build during the Host target build.
> 
> One solution I’ve came up with, is to build the required tools during 
> the Target platform build, using an add_custom_target() to invoke the 
> Target compiler directly. This works fine, as long as the tools are 
> basically build just out of a couple of files.
> 
> What would be the „CMake-Way“ to add the tools (that have to be build 
> on the Target platform) as dependency to targets that have to be build 
> for the Target (cross compile) platform?

TL;DR: there is not "good" way yet. But there should be one.

I'm hijacking this and move it to the developers list, because that is 
something "big", and we need to think about how to do that. I find it important 
to correctly solve this as it would simplify a lot of things. 
Especially given that Qt is thinking to use CMake to build Qt itself, which I 
bet all of us would love to see. But they will be after us if we don't offer a 
solution for this. And given the increasing amount of cross-setups these days 
I'm sure that a lot of other people would benefit.

My first idea was to have something like add_host_executable(), which would 
only be called when this is not CMAKE_CROSSCOMPILING, but at the end I think 
this clutters things too much.

Then I came up with:

   add_host_build("relative source dir" "build 

Re: [CMake] Can an option enforce a default, even if cache is present?

[Eric Noulard]

Le mar. 27 nov. 2018 à 14:50, Mario Emmenlauer  a
écrit :

>
> Dear all,
>
> I've just discovered that option() behaves differently than I anticipated.
> After reading the docs and searching with google I'm still confused how to
> achieve my desired behaviour.
>
> What I've just learned is that unspecified options take their cached value
> and do *not* go back to their default value, if a cache exists. I assumed
> that options take their default when not explicitly specified.
>

The behavior of option() gained new behavior in CMake 3.13.
May be it could help in your particular case:
https://cmake.org/cmake/help/v3.13/policy/CMP0077.html#policy:CMP0077

you'll depend on latest CMake though.


>
> Now my problem: I could not find a way to get the behaviour I'd like. Is it
> possible to enforce the default for an option when its not specified by the
> user, even if a cache exists?
>

You mean you did not manage to force the cache value?
You can:
set(VAR "default_value" CACHE FORCE)

or the problem is you cannot know whether if a value has been user-provided?


> I tried to unset() the option from the cache but that does not do what I'd
> like.
>
> 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
>


-- 
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] Can an option enforce a default, even if cache is present?

[Roger Leigh]

On 27/11/2018 13:49, Mario Emmenlauer wrote:


I've just discovered that option() behaves differently than I anticipated.
After reading the docs and searching with google I'm still confused how to
achieve my desired behaviour.

What I've just learned is that unspecified options take their cached value
and do *not* go back to their default value, if a cache exists. I assumed
that options take their default when not explicitly specified.


I think this is exactly what happens.  For example, an example I quickly 
dug out is this:


# Doxygen documentation
find_package(Doxygen)
set(DOXYGEN_DEFAULT OFF)
if (DOXYGEN_FOUND AND DOXYGEN_DOT_FOUND)
  set (DOXYGEN_DEFAULT ON)
endif (DOXYGEN_FOUND AND DOXYGEN_DOT_FOUND)
option(doxygen "Enable doxygen documentation" ${DOXYGEN_DEFAULT})
set(BUILD_DOXYGEN ${doxygen})

which causes this to be set in the cache:

//Enable doxygen documentation
doxygen:BOOL=ON

In this case, doxygen and dot were installed.  But if one was missing, 
it would default to "OFF" and this would be set in the cache.  If the 
user noticed it was missing, installed it, then re-ran cmake, the cached 
value would not be changed even though the default set with option() 
changed in the meantime.


From the look of things, there's no metadata in the cache to say "this 
was defaulted; the user did not specify it explicitly".  If such 
metadata did exist, the option() call could check it and overwrite the 
cached value if the user had not explicitly set the option.  This would 
make cmake much more conveniently adaptable.


The cache already stored extra properties for ADVANCED.  Could we add a 
similar extra property for DEFAULTED?  I.e.


//DEFAULTED property for variable: doxygen
doxygen-DEFAULTED:INTERNAL=1

Perhaps with a mark_as_defaulted() function to mirror 
mark_as_advanced().  Or a DEFAULT option for set_property() and/or a 
DEFAULT option as the opposite of FORCE for set().  This would only set 
the cache value if unset, plus add the DEFAULTED property.  The 
difference in behaviour would that if DEFAULT is used AND DEFAULTED=ON 
then the value would be overwritten if changed.



Regards,
Roger
--

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] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

[Eric Noulard]

Le mar. 27 nov. 2018 à 14:56, Mario Emmenlauer  a
écrit :

>
> Dear Eric,
>
> just to let you know, your suggestion of using a post-install-script
> for all system-wide links and files was indeed the solution to a working
> RPM package. Now my files are completely encapsulated in /opt/PKGNAME/
> and install works fine.
>

Thank you very much for the *positive* feedback, we don't always get those
:-)

This is nice to me and probably useful to others knowing it finally works.

Cheers,
Eric

Cheers and Thanks,
>
>Mario
>
>
>
> On 23.11.18 15:37, Mario Emmenlauer wrote:
> >
> > Dear Eric,
> >
> > thanks a lot for this help! I think I have the pointers to move forward!
> > One more detail below:
> >
> > On 23.11.18 11:36, Eric Noulard wrote:
> >> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer  > a écrit :
> >> Dear Eric, thanks for the help! Below more:
> >>
> >> On 22.11.18 18:20, Eric Noulard wrote:
> >> > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <
> ma...@emmenlauer.de   ma...@emmenlauer.de
> >> >> a écri
> >> > I'm trying to build an RPM with CPack, and everything seems
> to work,
> >> > but the resulting package can not be installed. I get
> Transaction check
> >> > error:
> >> >   file / from install of  conflicts with file from
> package filesystem-3.2-25.el7.x86_64
> >> >   file /opt from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr/bin from install of  conflicts with
> file from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr/share from install of  conflicts with
> file from package filesystem-3.2-25.el7.x86_64
> >> >   file /usr from install of  conflicts with file
> from package filesystem-3.2-25.el7.x86_64
> >> >
> >> > I've read in the CPackRPM source code about how to add
> excludes and
> >> > CPackRPM says that my "Final list of path to OMIT in RPM"
> would be
> >> >
>  
> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
> >> >
> >> >
> >> > You can read the doc too:
> >> >
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
> >>
> >> Haha, done that! I've read everything I could find, including the
> >> docs and the excellent but hard-to-find community wiki at
> >> https://gitlab.kitware.com/cmake/community/wikis/home
> >>
> >>
> >> OK then you are up-to-doc then.
> >>
> >> > Could someone shed some light? I believe that the problem may
> be
> >> > my install command: I call install only once for the full tree
> >> > of files that I'd like to package:
> >> >   install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/"
> USE_SOURCE_PERMISSIONS)
> >> >
> >> > Yep this is looking for trouble.
> >> > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
> >> >
> >> > Can't you use relative path install DESTINATION ? For all
> files/target you build?
> >>
> >> I'm not sure if I can use a relative path. I want to build a system
> package
> >> that installs to /opt// with symlinks in /usr/bin/ and
> desktop
> >> files in /usr/share/applications/. Since files go into different
> paths below
> >> system root (/opt, /usr, maybe /var) I assume I need to install
> into root?
> >> Maybe I misunderstand?
> >>
> >>
> >> Not really. Usually you install in relative bin/ share/ man/ whatever
> other subdir you need.
> >> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see
> https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
> )
> >> to set up your "main" install prefix for your package. Every CPack
> generator has a default **packaging install prefix** (not to be confused
> with
> >> CMAKE_INSTALL_PREFIX).
> >> In your case:
> >> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt")
> >> which should even be (AFAIR) the default value for RPM and DEB.
> >>
> >> Concerning the symlink in /usr/bin (or other places /usr/share etc...)
> this usually done using post-install script
> >>
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
> >>
> >> the script itself may call standard symlink creation like
> https://linux.die.net/man/8/update-alternatives
> >
> > Aha, now I see the recommended approach! Makes perfect sense! So I will
> > continue to bundle up everything, but try to avoid files outside my
> > man package directory (for me /opt/${PROJECT_NAME}). Then I will make
> > the system integration (to /usr/bin, /usr/share, etc) via symlinks
> > and update-alternatives in post-install scripts. This makes perfect
> > sense, I'm sorry I did not think of it myself!
> >
> > All the best,
> >
> > Mario
> >
> >
> >
> >> Sometimes you *really* need absolute 

Re: [CMake] CPack RPM: file XXX conflicts with file from package filesystem-yyy...

[Mario Emmenlauer]

Dear Eric,

just to let you know, your suggestion of using a post-install-script
for all system-wide links and files was indeed the solution to a working
RPM package. Now my files are completely encapsulated in /opt/PKGNAME/
and install works fine.

Cheers and Thanks,

   Mario



On 23.11.18 15:37, Mario Emmenlauer wrote:
> 
> Dear Eric,
> 
> thanks a lot for this help! I think I have the pointers to move forward!
> One more detail below:
> 
> On 23.11.18 11:36, Eric Noulard wrote:
>> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer > > a écrit :
>> Dear Eric, thanks for the help! Below more:
>>
>> On 22.11.18 18:20, Eric Noulard wrote:
>> > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer >  > >> a écri
>> >     I'm trying to build an RPM with CPack, and everything seems to 
>> work,
>> >     but the resulting package can not be installed. I get Transaction 
>> check
>> >     error:
>> >       file / from install of  conflicts with file from 
>> package filesystem-3.2-25.el7.x86_64
>> >       file /opt from install of  conflicts with file from 
>> package filesystem-3.2-25.el7.x86_64
>> >       file /usr/bin from install of  conflicts with file 
>> from package filesystem-3.2-25.el7.x86_64
>> >       file /usr/share from install of  conflicts with file 
>> from package filesystem-3.2-25.el7.x86_64
>> >       file /usr from install of  conflicts with file from 
>> package filesystem-3.2-25.el7.x86_64
>> >
>> >     I've read in the CPackRPM source code about how to add excludes and
>> >     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>> >     
>> /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>> >
>> >
>> > You can read the doc too:
>> > 
>> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
>>
>> Haha, done that! I've read everything I could find, including the
>> docs and the excellent but hard-to-find community wiki at
>> https://gitlab.kitware.com/cmake/community/wikis/home
>>
>>
>> OK then you are up-to-doc then.
>>
>> >     Could someone shed some light? I believe that the problem may be
>> >     my install command: I call install only once for the full tree
>> >     of files that I'd like to package:
>> >       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" 
>> USE_SOURCE_PERMISSIONS)
>> >
>> > Yep this is looking for trouble.
>> > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
>> >
>> > Can't you use relative path install DESTINATION ? For all files/target 
>> you build?
>>
>> I'm not sure if I can use a relative path. I want to build a system 
>> package
>> that installs to /opt// with symlinks in /usr/bin/ and desktop
>> files in /usr/share/applications/. Since files go into different paths 
>> below
>> system root (/opt, /usr, maybe /var) I assume I need to install into 
>> root?
>> Maybe I misunderstand?
>>
>>
>> Not really. Usually you install in relative bin/ share/ man/ whatever other 
>> subdir you need.
>> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see 
>> https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html)
>> to set up your "main" install prefix for your package. Every CPack generator 
>> has a default **packaging install prefix** (not to be confused with
>> CMAKE_INSTALL_PREFIX).
>> In your case: 
>> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") 
>> which should even be (AFAIR) the default value for RPM and DEB.
>>
>> Concerning the symlink in /usr/bin (or other places /usr/share etc...) this 
>> usually done using post-install script
>> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
>>
>> the script itself may call standard symlink creation like 
>> https://linux.die.net/man/8/update-alternatives
> 
> Aha, now I see the recommended approach! Makes perfect sense! So I will
> continue to bundle up everything, but try to avoid files outside my
> man package directory (for me /opt/${PROJECT_NAME}). Then I will make
> the system integration (to /usr/bin, /usr/share, etc) via symlinks
> and update-alternatives in post-install scripts. This makes perfect
> sense, I'm sorry I did not think of it myself!
> 
> All the best,
> 
> Mario
> 
> 
> 
>> Sometimes you *really* need absolute prefix like when you install in 
>> /etc/init...
>> then for those (generally system) specific file you install them with 
>> absolute destination.
>> CPackRPM is able to handle those as "config" file automatically.
>>
>> >     I have a wild guess that this install somehow includes the
>> >     directories, and probably it would be better to just call install
>> >     on the 

[Cmake-commits] CMake branch, master, updated. v3.13.0-546-gf49efe2

[Kitware Robot]

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

The branch, master has been updated
   via  f49efe283ed005aac642f5af58ea971d468de88c (commit)
   via  e3ec57483464b4c509e9f8b24e4ac8c6990f823b (commit)
   via  bae71966fb35649dda8fc4f962316e3dbea8f787 (commit)
   via  2a6e8644dd9650c7c749990410a5c50f12a786cb (commit)
   via  4833d2ef45cccb8f3e6b5a48f9747386fd9193ac (commit)
   via  43deb8e004bcf143df8757c65ea5b5fa33bda893 (commit)
   via  4aad340ec446e3def2bda4f2d474ab0cf86e902e (commit)
   via  85a035bf00d53d33251f30f850be7be169cbcde8 (commit)
   via  2cf836fa5ee71417145ec93e8f962d08c4a7d565 (commit)
   via  f54d28a838ca7d4efbbd0155c4f61c287ae2b9cb (commit)
   via  1f531e0428d0aa5804fd8f4d1b58fe69edc30eed (commit)
   via  0369362132b3deae30828299131647cc3754abeb (commit)
   via  d9195ab081b9c23a96d5a9c1b8e8be4da4f6e976 (commit)
   via  0d80977af4bbd1c76448307f577a7f22db792e65 (commit)
   via  c259912b14fc63db0441c30c33b79ebbef058e06 (commit)
   via  1ca53f5ef1335561d952603d48c48da549d41271 (commit)
   via  15ac4aae0e3199fe8ac7f46cf4eb064cbeb1660d (commit)
   via  3125c47d27d4d57cb31e10c4bd658fc1e352299d (commit)
   via  36bbd07a765820ddbcaef3db4e2a78d95910f5e1 (commit)
   via  e1dfe8cee619be2db2dcccfae5381376d336c6a3 (commit)
   via  d5f691be0b78a48e836dc42b97d000ba151c44d6 (commit)
   via  8b63265ea53dbd2e035a6b616ba0e82bfc0decc0 (commit)
   via  ede1715c1d4f35e806e3dabddd09c39eeed9a628 (commit)
   via  03879b11af0b2179d879358df3cce3c2b7acb047 (commit)
   via  b4edf7b5d2b2ba8eccfa0230dad98d0815a17d5d (commit)
   via  fc149a72f7e9128c0ad54014d745500fd31eea36 (commit)
   via  f0d52f55f155ac3f3e2bafa072a4e0d7f1431d76 (commit)
  from  cee843475d82150cc56d12badd04eb737bff6551 (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=f49efe283ed005aac642f5af58ea971d468de88c
commit f49efe283ed005aac642f5af58ea971d468de88c
Merge: e3ec574 0d80977
Author: Brad King 
AuthorDate: Tue Nov 27 13:51:18 2018 +
Commit: Kitware Robot 
CommitDate: Tue Nov 27 08:51:27 2018 -0500

Merge topic 'autogen_target_docs'

0d80977af4 Autogen: Documentation updates

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3ec57483464b4c509e9f8b24e4ac8c6990f823b
commit e3ec57483464b4c509e9f8b24e4ac8c6990f823b
Merge: bae7196 85a035b
Author: Brad King 
AuthorDate: Tue Nov 27 13:50:00 2018 +
Commit: Kitware Robot 
CommitDate: Tue Nov 27 08:50:07 2018 -0500

Merge topic 'FindDoxygen-win-glob'

85a035bf00 FindDoxygen: Avoid Windows-specific GLOB on other platforms

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bae71966fb35649dda8fc4f962316e3dbea8f787
commit bae71966fb35649dda8fc4f962316e3dbea8f787
Merge: 2a6e864 d9195ab
Author: Brad King 
AuthorDate: Tue Nov 27 13:48:33 2018 +
Commit: Kitware Robot 
CommitDate: Tue Nov 27 08:48:49 2018 -0500

Merge topic 'ctest-updates'

d9195ab081 Tests: Teach run_ctest to handle removal of CTestConfig.cmake
1ca53f5ef1 Remove unnecessary CTEST_PROJECT_NAME variables
15ac4aae0e Remove warning when no CTestConfig.cmake file exists
3125c47d27 ctest_build: Do not require unnecessary [CTEST_]PROJECT_NAME 
value
36bbd07a76 CDashUpload: Use the query part of the submit url as field
e1dfe8cee6 CTest: Don't require 'submit.php?' in submit location

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a6e8644dd9650c7c749990410a5c50f12a786cb
commit 2a6e8644dd9650c7c749990410a5c50f12a786cb
Merge: 4833d2e c259912
Author: Brad King 
AuthorDate: Tue Nov 27 13:48:00 2018 +
Commit: Kitware Robot 
CommitDate: Tue Nov 27 08:48:08 2018 -0500

Merge topic 'blaslapack_mkl_gfortran'

c259912b14 FindBLAS: Do not look for BLAS once BLAS95 has been found
d5f691be0b FindLAPACK: Additional libraries for MKL+gfortran combination
8b63265ea5 FindLAPACK: Unify internal variables related to MKL
ede1715c1d FindLAPACK: Remove MKL components already provided by MKL BLAS
03879b11af FindLAPACK: Prioritize Intel MKL
b4edf7b5d2 FindBLAS: Support 32bit Intel MKL 10.3+
fc149a72f7 FindBLAS: Support combination of gfortran and Intel MKL
f0d52f55f1 FindBLAS: Consolidate duplicated code related to MKL on Windows

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4833d2ef45cccb8f3e6b5a48f9747386fd9193ac
commit 

[Cmake-commits] CMake branch, release, updated. v3.13.0-6-g2cf836f

[Kitware Robot]

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

The branch, release has been updated
   via  2cf836fa5ee71417145ec93e8f962d08c4a7d565 (commit)
   via  f54d28a838ca7d4efbbd0155c4f61c287ae2b9cb (commit)
   via  1f531e0428d0aa5804fd8f4d1b58fe69edc30eed (commit)
   via  0369362132b3deae30828299131647cc3754abeb (commit)
  from  8068850fcc1575210c968365e71cb7ece6771022 (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/FindBoost.cmake|  9 ++---
 Source/cmGlobalVisualStudio14Generator.cxx | 38 --
 .../NoCXX-stderr.txt}  |  0
 Tests/RunCMake/FindBoost/NoCXX.cmake   |  1 +
 Tests/RunCMake/FindBoost/RunCMakeTest.cmake|  1 +
 5 files changed, 26 insertions(+), 23 deletions(-)
 copy Tests/RunCMake/{target_link_options/LINK_OPTIONS-shared-result.txt => 
FindBoost/NoCXX-stderr.txt} (100%)
 create mode 100644 Tests/RunCMake/FindBoost/NoCXX.cmake


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

[CMake] Can an option enforce a default, even if cache is present?

[Mario Emmenlauer]

Dear all,

I've just discovered that option() behaves differently than I anticipated.
After reading the docs and searching with google I'm still confused how to
achieve my desired behaviour.

What I've just learned is that unspecified options take their cached value
and do *not* go back to their default value, if a cache exists. I assumed
that options take their default when not explicitly specified.

Now my problem: I could not find a way to get the behaviour I'd like. Is it
possible to enforce the default for an option when its not specified by the
user, even if a cache exists?

I tried to unset() the option from the cache but that does not do what I'd
like.

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

Re: [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations)

[Brad King]

On 11/27/18 5:28 AM, Rolf Eike Beer wrote:
> Then I came up with:
> 
>add_host_build("relative source dir" "build dir" [VARS])
> 
> This would create an entirely new CMake scope (with it's own 
> CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
> and would not take the CMAKE_TOOLCHAIN_FILE into account.
[snip]
> My idea would be that things added by add_executable() inside such a
> sub-build are visible as targets from the outer build.

For reference, some projects are already using the ExternalProject
module to approximate that approach and bring in the host tools as
imported executable targets.  The actual host build is viewed as
a custom target from the cross-compiled project.

-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

Re: [cmake-developers] [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations)

[Brad King]

On 11/27/18 5:28 AM, Rolf Eike Beer wrote:
> Then I came up with:
> 
>add_host_build("relative source dir" "build dir" [VARS])
> 
> This would create an entirely new CMake scope (with it's own 
> CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
> and would not take the CMAKE_TOOLCHAIN_FILE into account.
[snip]
> My idea would be that things added by add_executable() inside such a
> sub-build are visible as targets from the outer build.

For reference, some projects are already using the ExternalProject
module to approximate that approach and bring in the host tools as
imported executable targets.  The actual host build is viewed as
a custom target from the cross-compiled project.

-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

Re: [CMake] dependencies of cross compiliations

[Ray Donnelly]

> which I bet all of us would love to see.

This is not correct. I would strongly prefer they continue with QBS
instead. Cmake is defacto, but very suboptional.

On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer  Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
> I'm hijacking this and move it to the developers list, because that is
> something "big", and we need to think about how to do that. I find it
> important to correctly solve this as it would simplify a lot of things.
> Especially given that Qt is thinking to use CMake to build Qt itself,
> which I bet all of us would love to see. But they will be after us if we
> don't offer a solution for this. And given the increasing amount of
> cross-setups these days I'm sure that a lot of other people would
> benefit.
>
> My first idea was to have something like add_host_executable(), which
> would only be called when this is not CMAKE_CROSSCOMPILING, but at the
> end I think this clutters things too much.
>
> Then I came up with:
>
>add_host_build("relative source dir" "build dir" [VARS])
>
> This would create an entirely new CMake scope (with it's own
> CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir",
> and would not take the CMAKE_TOOLCHAIN_FILE into account. People are
> free to pass "." as relative source dir in case they want to start at
> top level, but they may as well pass "tools", "generators" or whatever
> they call it. This is not intended to be called multiple times from the
> same project as it would scan for compiler and environment once for
> every call, but doing so does no harm beyond being slow(er) and the
> targets of one such sub-build not being visible to the others.
>
> My idea would be that things added by add_executable() inside such a
> sub-build are visible as targets from the outer build. Other things like
> libraries and the like need not to be, they can't be linked in the outer
> world. The user is free to build with shared libs inside, and running
> the things from the build tree would result in the correct freshly build
> libs being picked up because of RPATH or whatever. There is no install
> of those targets possible from the outer build, this can entirely be
> managed from the host build. Of course one must be possible to set
> variables on the host build, that's where VARS comes into play. This
> holds a list of variable names that will be passed to the hostbuild. No
> values, to avoid all sorts of quoting issues. Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>
> This should end up in a layout like this:
>
> /tmp/install/prefix/tools/bin/magic.exe # Windows host
> /tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
> /tmp/install/prefix/sysroot/usr/bin/foo
>
> The toolchain file would look somehow like this:
>
> set(CMAKE_HOST_PREFIX prefix
> set(CMAKE_SYSROOT 

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Ray Donnelly]

> which I bet all of us would love to see.

This is not correct. I would strongly prefer they continue with QBS
instead. Cmake is defacto, but very suboptional.

On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer  Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> > Hi,
> > I hope this question was not asked before. I work in the embedded
> > field and there it is usually to have at least two different build
> > platforms. The Host platform, where unit tests are build (and where
> > CMake is running) and an embedded Target platform, where targets are
> > build with a cross compiler. Sometimes such a system comes with
> > self-written tools that are build and run on the Host platform to
> > build a target for the embedded Target platform (adding meta data to a
> > binary to be used by a bootloader for example).
> >
> > Usually I have two different build folders, one for the Host platform
> > and one for the Target platform, using different calls to cmake to
> > choose from a set of tools and targets. But when using this approach,
> > it is necessary that the Host platform build ran before the Target
> > platform build, so that tools that are required for the Target
> > platform are build during the Host target build.
> >
> > One solution I’ve came up with, is to build the required tools during
> > the Target platform build, using an add_custom_target() to invoke the
> > Target compiler directly. This works fine, as long as the tools are
> > basically build just out of a couple of files.
> >
> > What would be the „CMake-Way“ to add the tools (that have to be build
> > on the Target platform) as dependency to targets that have to be build
> > for the Target (cross compile) platform?
>
> TL;DR: there is not "good" way yet. But there should be one.
>
> I'm hijacking this and move it to the developers list, because that is
> something "big", and we need to think about how to do that. I find it
> important to correctly solve this as it would simplify a lot of things.
> Especially given that Qt is thinking to use CMake to build Qt itself,
> which I bet all of us would love to see. But they will be after us if we
> don't offer a solution for this. And given the increasing amount of
> cross-setups these days I'm sure that a lot of other people would
> benefit.
>
> My first idea was to have something like add_host_executable(), which
> would only be called when this is not CMAKE_CROSSCOMPILING, but at the
> end I think this clutters things too much.
>
> Then I came up with:
>
>add_host_build("relative source dir" "build dir" [VARS])
>
> This would create an entirely new CMake scope (with it's own
> CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir",
> and would not take the CMAKE_TOOLCHAIN_FILE into account. People are
> free to pass "." as relative source dir in case they want to start at
> top level, but they may as well pass "tools", "generators" or whatever
> they call it. This is not intended to be called multiple times from the
> same project as it would scan for compiler and environment once for
> every call, but doing so does no harm beyond being slow(er) and the
> targets of one such sub-build not being visible to the others.
>
> My idea would be that things added by add_executable() inside such a
> sub-build are visible as targets from the outer build. Other things like
> libraries and the like need not to be, they can't be linked in the outer
> world. The user is free to build with shared libs inside, and running
> the things from the build tree would result in the correct freshly build
> libs being picked up because of RPATH or whatever. There is no install
> of those targets possible from the outer build, this can entirely be
> managed from the host build. Of course one must be possible to set
> variables on the host build, that's where VARS comes into play. This
> holds a list of variable names that will be passed to the hostbuild. No
> values, to avoid all sorts of quoting issues. Helpful would be a special
> variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and
> a non-sysroot thing prefix in the toolchain file). Confused? Granted,
> here is an example:
>
> if (CMAKE_CROSSCOMPILING)
>  set(HOST_INSTALL_DIR "/some/where")
>  add_host_build(. host HOST_INSTALL_DIR)
> endif ()
> add_executable(magic magic.cpp)
> install(TARGETS magic DESTINATION bin) # installs both the host and the
> target tool!
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND
> magic) # will call the host build
> if (NOT CMAKE_HOST_BUILD)
>  add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
>  install(TARGETS foo DESTINATION bin)
> endif ()
>
> This should end up in a layout like this:
>
> /tmp/install/prefix/tools/bin/magic.exe # Windows host
> /tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
> /tmp/install/prefix/sysroot/usr/bin/foo
>
> The toolchain file would look somehow like this:
>
> set(CMAKE_HOST_PREFIX prefix
> set(CMAKE_SYSROOT 

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Rolf Eike Beer]

Am 2018-11-09 10:04, schrieb Torsten Robitzki:

Hi,
I hope this question was not asked before. I work in the embedded
field and there it is usually to have at least two different build
platforms. The Host platform, where unit tests are build (and where
CMake is running) and an embedded Target platform, where targets are
build with a cross compiler. Sometimes such a system comes with
self-written tools that are build and run on the Host platform to
build a target for the embedded Target platform (adding meta data to a
binary to be used by a bootloader for example).

Usually I have two different build folders, one for the Host platform
and one for the Target platform, using different calls to cmake to
choose from a set of tools and targets. But when using this approach,
it is necessary that the Host platform build ran before the Target
platform build, so that tools that are required for the Target
platform are build during the Host target build.

One solution I’ve came up with, is to build the required tools during
the Target platform build, using an add_custom_target() to invoke the
Target compiler directly. This works fine, as long as the tools are
basically build just out of a couple of files.

What would be the „CMake-Way“ to add the tools (that have to be build
on the Target platform) as dependency to targets that have to be build
for the Target (cross compile) platform?


TL;DR: there is not "good" way yet. But there should be one.

I'm hijacking this and move it to the developers list, because that is 
something "big", and we need to think about how to do that. I find it 
important to correctly solve this as it would simplify a lot of things. 
Especially given that Qt is thinking to use CMake to build Qt itself, 
which I bet all of us would love to see. But they will be after us if we 
don't offer a solution for this. And given the increasing amount of 
cross-setups these days I'm sure that a lot of other people would 
benefit.


My first idea was to have something like add_host_executable(), which 
would only be called when this is not CMAKE_CROSSCOMPILING, but at the 
end I think this clutters things too much.


Then I came up with:

  add_host_build("relative source dir" "build dir" [VARS])

This would create an entirely new CMake scope (with it's own 
CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
and would not take the CMAKE_TOOLCHAIN_FILE into account. People are 
free to pass "." as relative source dir in case they want to start at 
top level, but they may as well pass "tools", "generators" or whatever 
they call it. This is not intended to be called multiple times from the 
same project as it would scan for compiler and environment once for 
every call, but doing so does no harm beyond being slow(er) and the 
targets of one such sub-build not being visible to the others.


My idea would be that things added by add_executable() inside such a 
sub-build are visible as targets from the outer build. Other things like 
libraries and the like need not to be, they can't be linked in the outer 
world. The user is free to build with shared libs inside, and running 
the things from the build tree would result in the correct freshly build 
libs being picked up because of RPATH or whatever. There is no install 
of those targets possible from the outer build, this can entirely be 
managed from the host build. Of course one must be possible to set 
variables on the host build, that's where VARS comes into play. This 
holds a list of variable names that will be passed to the hostbuild. No 
values, to avoid all sorts of quoting issues. Helpful would be a special 
variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and 
a non-sysroot thing prefix in the toolchain file). Confused? Granted, 
here is an example:


if (CMAKE_CROSSCOMPILING)
set(HOST_INSTALL_DIR "/some/where")
add_host_build(. host HOST_INSTALL_DIR)
endif ()
add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin) # installs both the host and the 
target tool!
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND 
magic) # will call the host build

if (NOT CMAKE_HOST_BUILD)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)
endif ()

This should end up in a layout like this:

/tmp/install/prefix/tools/bin/magic.exe # Windows host
/tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
/tmp/install/prefix/sysroot/usr/bin/foo

The toolchain file would look somehow like this:

set(CMAKE_HOST_PREFIX prefix
set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot)

and the CMake command would look like this:

cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D 
CMAKE_HOST_INSTALL_PREFIX=tools ...


The wish-season is coming up, so that's sort of what I would like to 
have. Now it's your turn. No bikeshedding please, only deliveries ;)


Eike
--
--

Powered by www.kitware.com

Please keep messages on-topic and check 

Re: [CMake] dependencies of cross compiliations

[Rolf Eike Beer]

Am 2018-11-09 10:04, schrieb Torsten Robitzki:

Hi,
I hope this question was not asked before. I work in the embedded
field and there it is usually to have at least two different build
platforms. The Host platform, where unit tests are build (and where
CMake is running) and an embedded Target platform, where targets are
build with a cross compiler. Sometimes such a system comes with
self-written tools that are build and run on the Host platform to
build a target for the embedded Target platform (adding meta data to a
binary to be used by a bootloader for example).

Usually I have two different build folders, one for the Host platform
and one for the Target platform, using different calls to cmake to
choose from a set of tools and targets. But when using this approach,
it is necessary that the Host platform build ran before the Target
platform build, so that tools that are required for the Target
platform are build during the Host target build.

One solution I’ve came up with, is to build the required tools during
the Target platform build, using an add_custom_target() to invoke the
Target compiler directly. This works fine, as long as the tools are
basically build just out of a couple of files.

What would be the „CMake-Way“ to add the tools (that have to be build
on the Target platform) as dependency to targets that have to be build
for the Target (cross compile) platform?


TL;DR: there is not "good" way yet. But there should be one.

I'm hijacking this and move it to the developers list, because that is 
something "big", and we need to think about how to do that. I find it 
important to correctly solve this as it would simplify a lot of things. 
Especially given that Qt is thinking to use CMake to build Qt itself, 
which I bet all of us would love to see. But they will be after us if we 
don't offer a solution for this. And given the increasing amount of 
cross-setups these days I'm sure that a lot of other people would 
benefit.


My first idea was to have something like add_host_executable(), which 
would only be called when this is not CMAKE_CROSSCOMPILING, but at the 
end I think this clutters things too much.


Then I came up with:

  add_host_build("relative source dir" "build dir" [VARS])

This would create an entirely new CMake scope (with it's own 
CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
and would not take the CMAKE_TOOLCHAIN_FILE into account. People are 
free to pass "." as relative source dir in case they want to start at 
top level, but they may as well pass "tools", "generators" or whatever 
they call it. This is not intended to be called multiple times from the 
same project as it would scan for compiler and environment once for 
every call, but doing so does no harm beyond being slow(er) and the 
targets of one such sub-build not being visible to the others.


My idea would be that things added by add_executable() inside such a 
sub-build are visible as targets from the outer build. Other things like 
libraries and the like need not to be, they can't be linked in the outer 
world. The user is free to build with shared libs inside, and running 
the things from the build tree would result in the correct freshly build 
libs being picked up because of RPATH or whatever. There is no install 
of those targets possible from the outer build, this can entirely be 
managed from the host build. Of course one must be possible to set 
variables on the host build, that's where VARS comes into play. This 
holds a list of variable names that will be passed to the hostbuild. No 
values, to avoid all sorts of quoting issues. Helpful would be a special 
variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and 
a non-sysroot thing prefix in the toolchain file). Confused? Granted, 
here is an example:


if (CMAKE_CROSSCOMPILING)
set(HOST_INSTALL_DIR "/some/where")
add_host_build(. host HOST_INSTALL_DIR)
endif ()
add_executable(magic magic.cpp)
install(TARGETS magic DESTINATION bin) # installs both the host and the 
target tool!
add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND 
magic) # will call the host build

if (NOT CMAKE_HOST_BUILD)
add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp)
install(TARGETS foo DESTINATION bin)
endif ()

This should end up in a layout like this:

/tmp/install/prefix/tools/bin/magic.exe # Windows host
/tmp/install/prefix/sysroot/usr/bin/magic # Unix guest
/tmp/install/prefix/sysroot/usr/bin/foo

The toolchain file would look somehow like this:

set(CMAKE_HOST_PREFIX prefix
set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot)

and the CMake command would look like this:

cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D 
CMAKE_HOST_INSTALL_PREFIX=tools ...


The wish-season is coming up, so that's sort of what I would like to 
have. Now it's your turn. No bikeshedding please, only deliveries ;)


Eike
--
--

Powered by www.kitware.com

Please keep messages on-topic and check 

[CMake] Cmake Boost::boost target PRIVATE link, forcing dependency on client

[rmawatson rmawatson]

I am having a problem with make 3.12 (windows) and cmake version 3.13.0-rc2 
(linux). I am attempting to link boost headers privately to a static library, 
which is then linked by a client executable, that I do not want to depend on 
boost.

According to the docs, the find_package(Boost) provides a target for the header 
only portion of the boost library, Boost::boost. this is the target I am using, 
and I am linking the target privately, ie

target_link_libraries(testlib PRIVATE Boost::boost)

However a the client testexe which uses testlib from the install dir with 
find_package(testlib)and links it with target_link_libraries(testexe 
testlib::testlib) is causing cmake to search for a Boost dependency for the 
testexe. As this is linked privately, it shouldn't as far as I can see.

Interestingly adding an INTERFACE IMPORTED target in testlib and using this to 
link, and the client no longer needs boost.

find_package(Boost REQUIRED)

add_library(boost INTERFACE IMPORTED)

set_property(TARGET boost PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR})
target_link_libraries(testlib
PRIVATE
#using the imported target instead
boost
#Boost::boost)

this is almost identical to the lines in the Find boost source 
here.
 The only difference being the target the properties are set on.

I have a workaround but I would like to know what is going on.

The complete source for the two test projects are availabe 
here.

This is the output from cmake with using the Boost::boost target and the 
INTERFACE IMPORTEDtarget, which works

###using to the provided Boost::boost target

C:\Temp\cmake_boost\testlib\build>cmake ../ 
-DBOOST_ROOT=d:\sdk\boost\boost_1_68_0
-- Boost version: 1.68.0-- Configuring done
-- Generating done
-- Build files have been written to: C:/Temp/cmake_boost/testlib/build

C:\Temp\cmake_boost\testexe\build>cmake ../ 
-DCMAKE_PREFIX_PATH="C:\Temp\cmake_boost\testlib\build"-- Configuring done
CMake Error at CMakeLists.txt:6 (add_executable):
  Target "test" links to target "Boost::boost" but the target was not found.
  Perhaps a find_package() call is missing for an IMPORTED target, or an
  ALIAS target is missing?-- Generating done
-- Build files have been written to: C:/Temp/cmake_boost/testexe/build



#When using the imported library target.

C:\Temp\cmake_boost\testlib\build>cmake ../ 
-DBOOST_ROOT=d:\sdk\boost\boost_1_68_0
-- Boost version: 1.68.0-- Configuring done
-- Generating done
-- Build files have been written to: C:/Temp/cmake_boost/testlib/build


C:\Temp\cmake_boost\testexe\build>cmake ../ 
-DCMAKE_PREFIX_PATH="C:\Temp\cmake_boost\testlib\build"-- Configuring done
-- Generating done
-- Build files have been written to: C:/Temp/cmake_boost/testexe/build

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