[CMake] Ninja generator and showIncludes

[Ghyslain Leclerc]

Hello.

I have been searching for a way to prevent the Ninja generator from issuing the 
showIncludes command to cl.

With our update to the latest CMake (3.8.2) on Windows (7 enterprise, at work) 
with the latest MSVC (2017 community), we now have a ton of messages saying

Note: including file: 

which makes it difficult to see the actual compilation warnings and errors.

Turned to Google and found some information about localization potentially 
being a problem, so I uninstalled MSVC 2017 which was in the French version and 
installed the English one. Turns out that only made the include messages 
English. :)

I searched the documentation for a target property that I could use but did not 
find anything. I thought of using target compile flag, but not sure how I would 
remove a flag.

Searched the mailing list for some info, but most of what I have found does not 
answer my question. For instance :

http://cmake.org/pipermail/cmake-developers/2013-November/020782.html

I also looked in the bug tracker and there does not seem to be any issue 
relating to that, so my guess is I am doing something wrong.

So if anyone else has had that problem and/or has a solution for me, I'd 
appreciate any insight.

Thanks.

Ghyslain Leclerc
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] GetPrerequisites with Android?

[Robert Dailey]

Has anyone used GetPrerequisites[1] when cross-compiling a shared
library with Android NDK toolchain? I'd like some way to get dependent
*.so files (located in the NDK itself and specified on the linker
command line when building) so I can copy them to my android java
project dir under "libs" so they get packaged when the APK is built.

[1]: https://cmake.org/cmake/help/v3.9/module/GetPrerequisites.html
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] fortran linking issue

[Juan E. Sanchez]

When I set the linker language of a fortran program to "C", it 
automatically links in -lgfortran, -lquadmath, -lm.


SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C")

Unfortunately, that precludes me linking in static versions of  -lquadmath.

How do I tell CMAKE not to append these libraries when I change the 
LINKER_LANGUAGE to "C"?


Regards,

Juan
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] fortran linking issue

[Juan E. Sanchez]

It turns out these linker flags were being added by cmake.  To disable 
them, I had to:

unset(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)

I was then able to use SET_TARGET_PROPERTIES to link into the static 
versions of the code I wanted.


This also fixed the issue for the case where I had a C++ exe with a 
Fortran library.  In this case, I only needed to use 
TARGET_LINK_LIBRARIES to bring in my static gfortran and quadmath libraries.


It turns out that libgfortran has its own link to libquadmath, so I was 
forced to statically link that as well.


Regards,

Juan



On 7/13/17 2:29 PM, Juan E. Sanchez wrote:
When I set the linker language of a fortran program to "C", it 
automatically links in -lgfortran, -lquadmath, -lm.


SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C")

Unfortunately, that precludes me linking in static versions of  -lquadmath.

How do I tell CMAKE not to append these libraries when I change the 
LINKER_LANGUAGE to "C"?


Regards,

Juan


--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] How to add project files?

[Florian Lindner]

Hello,

our project, which is currently using scons is structured like this

ROOT
  - SConstruct
  - CMakeLists.txt
  - src/
- SConscript
- CMAkeLists.txt
- Module1
  - somesourcefiles.cpp
  - tests/
- testsourcefiles.cpp
  - config/
 - configsourcefile.cpp
 - Module2 (like Module1)
 - ...

Right now the SConstruct calls SConscript

sourcesModule1 = [
Glob('Module1/*.cpp'),
Glob('Module2/config/*.cpp')
]

The test files (Boost Test) are compiled to a standalone executable

sourcesTests = [
Glob('*/tests/*.cpp'),
File("testing/main.cpp")
]

We currently have 4 targets. A static and dynamic lib (comprised of all 
modules), a binary (comprised of all modules +
main.cpp) and the test binary (all modules, tests and test main.cpp).

I was able to replicate that structure with CMake and it builds fine:


src/CMakeLists.txt:

file(GLOB sourcesAllNoMain
  "Module1/*.cpp"
  "Module1/config/*.cpp")

file(GLOB sourcesTests
  "*/tests/*.cpp")

set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE)
set (sourcesTests ${sourcesTests} PARENT_SCOPE)


ROOT/CMakeLists.txt:

add_subdirectory("src")

add_library(solib ${sourcesAllNoMain})
set_target_properties(solib
  PROPERTIES OUTPUT_NAME libprecice)
target_link_libraries(solib ${PYTHON_LIBRARIES})
target_link_libraries(solib ${MPI_LIBRARIES})
target_link_libraries(solib ${Boost_LIBRARIES})
target_link_libraries(solib ${petsc})


Now, in the docs I everywhere read not to add the files using GLOB. However, I 
have found no definitive guide how to add
project files in a large project with subdirs like that.

How would you do it in cmakeish fashion?

I know this might be a FAQ, but googled for days and found no suitable answer.

Thanks a lot,
Florian
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[Eric Noulard]

2017-07-13 2:04 GMT+02:00 René J. V. Bertin :

> Andreas Naumann wrote:
>
> > cmake instrospects your compiler and asks for system directories.
>
> Just stumbled across this documentation tidbit:
>

Thanks you for digging this.
I totally ignored that "feature".



>
> >>>
> CMAKE__IMPLICIT_LINK_DIRECTORIES
> --
>
> Implicit linker search path detected for language .
>
> Compilers typically pass directories containing language runtime
> libraries and default library search paths when they invoke a linker.
> These paths are implicit linker search directories for the compiler's
> language.  CMake automatically detects these directories for each
> language and reports the results in this variable.
>
> When a library in one of these directories is given by full path to
> :command:`target_link_libraries` CMake will generate the ``-l``
> form on
> link lines to ensure the linker searches its implicit directories for the
> library.  Note that some toolchains read implicit directories from an
> environment variable such as ``LIBRARY_PATH`` so keep its value consistent
> when operating in a given build tree.
> <<<
>
> Note the
> > CMake will generate the ``-l`` form on link lines to ensure the
> linker
> > searches its implicit directories
>
> What's the point in doing that when a full path is given? Full path means
> searching isn't required. Full path (probably) means that the operator
> wants to
> ensure that a specific library is linked. Full path thus means that
> searching
> can even have counterproductive effects


>
I you have a look at file:
https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx

you may discovered (as I just did) that not all CMake supported systems
kindly accept full path to library for linking...
so may be the implicit system link dir was introduced for them in the first
place.
I guess the author/contributor to this part of CMake may certainly explain
that better than me.

Looking the code is interesting because apparently what you need is to set
 CMP0060 to NEW:

$ cmake --help-policy CMP0060
CMP0060
---

Link libraries by full path even in implicit directories.


The OLD behavior for this policy is to ask the linker to search for
libraries whose full paths are known to be in implicit link directories.
The NEW behavior for this policy is to link libraries by full path even
if they are in implicit link directories.

This policy was introduced in CMake version 3.3.  Unlike most policies,
CMake version 3.7.2 does *not* warn by default when this policy
is not set and simply uses OLD behavior.  See documentation of the
``CMAKE_POLICY_WARNING_CMP0060``
variable to control the warning.


The thing I don't understand is that you use CMake 3.8.2 so you should get
the new behavior.
However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may
set the CMP0060 to old.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[Eric Noulard]

2017-07-13 12:07 GMT+02:00 René J. V. Bertin :
[...]

>
> >
> > The thing I don't understand is that you use CMake 3.8.2 so you should
> get
> > the new behavior.
>
> Are you sure? I read from the description above that you have to set the
> policy
> explicitly.
>

You are right,
 it depends on the cmake_minimum_required statement you gave.


>
> Do you know if one can set policies like this from the commandline rather
> than
> through patching each toplevel CMakeLists.txt file? Or can it be set for
> just a
> subdirectory?
>

>From the command line I doubt it.
However CMake handles a policy stack:

 https://cmake.org/cmake/help/v3.7/command/cmake_policy.html

so that you can enable the NEW behavior of a policy locally in a particular
CMakeLists.txt or function etc...


> > However since digikam does a cmake_minimum_required(VERSION 3.0.0) which
> may
> > set the CMP0060 to old.
>
> Quite possible, I've run into naggles with that with another policy on Mac
> (25).
> It's annoying that this happens with digikam which is a really cumbersome
> project (it takes ages just to run make just to confirm that everything
> has been
> built).
>

Did you try to use ninja generator instead of make ?
The no-op build is really faster with ninja.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Eric Noulard wrote:

> Thanks you for digging this.
> I totally ignored that "feature".

I guess most of us did, it's one of those things that usually works just fine 
but that when it breaks sends you on a nasty quest to figure out WTF is going 
on 
(IOW, makes you doubt yourself until you realise you just discovered a hidden 
feature).

I found this only because I searched the CMake source tree for LIBRARY_PATH to 
see where it does the rewriting. I would never have guessed to find the feature 
biting me under the concept "implicit directories".

> I you have a look at file:
> 
https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx
> 
> you may discovered (as I just did) that not all CMake supported systems
> kindly accept full path to library for linking...

CMake being a system that allows to describe how to build a project in a 
platform-agnostic way it could easily have handled those systems individually.

> I guess the author/contributor to this part of CMake may certainly explain
> that better than me.

Presumably, and I guess s/he might admit not having thought of (or tested) the 
kind of situation where rewriting breaks things.

Something you said in a mail that apparently didn't go to the list:

> OK, but I don't think CMake should "fight" the underlying compiler.

No. Clang may have a reason for the different way of handling LIBRARY_PATH 
which 
means you'd have to leave a possibility for it to work that way - maybe even by 
default. But in this case we're not fighting the compiler, we're trying to let 
it work another way that is just as supported.

> Looking the code is interesting because apparently what you need is to set
>  CMP0060 to NEW:
> 
> $ cmake --help-policy CMP0060
> CMP0060

Ah, great. I would probably have found that by myself, eventually.

> ---
> 
> Link libraries by full path even in implicit directories.
> 
> 
> The OLD behavior for this policy is to ask the linker to search for
> libraries whose full paths are known to be in implicit link directories.
> The NEW behavior for this policy is to link libraries by full path even
> if they are in implicit link directories.
> 
> This policy was introduced in CMake version 3.3.  Unlike most policies,
> CMake version 3.7.2 does *not* warn by default when this policy
> is not set and simply uses OLD behavior.  See documentation of the
> ``CMAKE_POLICY_WARNING_CMP0060``
> variable to control the warning.
> 
> 
> The thing I don't understand is that you use CMake 3.8.2 so you should get
> the new behavior.

Are you sure? I read from the description above that you have to set the policy 
explicitly.

Do you know if one can set policies like this from the commandline rather than 
through patching each toplevel CMakeLists.txt file? Or can it be set for just a 
subdirectory?

> However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may
> set the CMP0060 to old.

Quite possible, I've run into naggles with that with another policy on Mac (25).
It's annoying that this happens with digikam which is a really cumbersome 
project (it takes ages just to run make just to confirm that everything has 
been 
built).

R.

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Eric Noulard wrote:

> From the command line I doubt it.

Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works.

But whatever the reason, using PNG::PNG works too. Apparently policy 60 doesn't 
affect the IMPORTED_LOCATION target property...


> Did you try to use ninja generator instead of make ?
> The no-op build is really faster with ninja.

I compared single full builds with ninja and make yesterday; with ninja it was 
actually (a bit) slower and required more resources (including a larger build 
directory). My main gripe with it is that you cannot simply launch a partial 
build from a subdirectory.

R

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[Eric Noulard]

2017-07-13 13:01 GMT+02:00 René J. V. Bertin :

> Eric Noulard wrote:
>
> > From the command line I doubt it.
>
> Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works.
>

Good to know.


>
> But whatever the reason, using PNG::PNG works too. Apparently policy 60
> doesn't
> affect the IMPORTED_LOCATION target property...
>

I guess this is expected and this is one advantage of imported library vs
plain path to lib.


> Did you try to use ninja generator instead of make ?
> > The no-op build is really faster with ninja.
>
> I compared single full builds with ninja and make yesterday; with ninja it
> was
> actually (a bit) slower and required more resources (including a larger
> build
> directory).


Do run make with parallel build?

I was speaking of a no-op build but for full build it may depends on your
main memory amount.
Ninja is parallel by default and in some case if you have many core (like 8
or more) but
not so much memory, ninja will generate as many compile/link job as you
have core (+2 I think)
which may be too much makes your system swap.

In that case you can control it yourself using
ninja -j 
or
ninja -l 

My main gripe with it is that you cannot simply launch a partial
> build from a subdirectory.
>

Ninja generator is different is it not directory-based because you have a
single build.ninja file.
However you can easily build any (sub)directory of your project using:

ninja Path/To/Dir/all

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-284-g4b460a5

[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  4b460a5ba8cdb36e05c1517237c8ef15562e4490 (commit)
   via  489a7706c25b604fa06644ab5044a9f5954b7953 (commit)
   via  d11c48e0e344e6758a5575330b3f0e267d820e02 (commit)
   via  4bafa3922e3773e5bcc6741994379455c7d1c0fc (commit)
  from  aa97170f2b25a99d2cc69fd6b2a059e52872f341 (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=4b460a5ba8cdb36e05c1517237c8ef15562e4490
commit 4b460a5ba8cdb36e05c1517237c8ef15562e4490
Merge: 489a770 d11c48e
Author: Brad King 
AuthorDate: Thu Jul 13 10:08:27 2017 -0400
Commit: Brad King 
CommitDate: Thu Jul 13 10:08:27 2017 -0400

Merge branch 'release-3.9'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=489a7706c25b604fa06644ab5044a9f5954b7953
commit 489a7706c25b604fa06644ab5044a9f5954b7953
Merge: aa97170 4bafa39
Author: Brad King 
AuthorDate: Thu Jul 13 14:07:32 2017 +
Commit: Kitware Robot 
CommitDate: Thu Jul 13 10:07:36 2017 -0400

Merge topic 'android-system-include-last'

4bafa392 Android: Always add standard include directories last

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


---

Summary of changes:
 Modules/Platform/Android-Common.cmake |1 -
 Source/cmGeneratorTarget.cxx  |   12 
 Source/cmLocalGenerator.cxx   |   14 ++
 Tests/RunCMake/Android/android_sysinc.c   |7 +++
 Tests/RunCMake/Android/android_sysinc.cxx |7 +++
 Tests/RunCMake/Android/common.cmake   |   16 
 Tests/RunCMake/Android/sysinc/dlfcn.h |1 +
 7 files changed, 45 insertions(+), 13 deletions(-)
 create mode 100644 Tests/RunCMake/Android/android_sysinc.c
 create mode 100644 Tests/RunCMake/Android/android_sysinc.cxx
 create mode 100644 Tests/RunCMake/Android/sysinc/dlfcn.h


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

[Cmake-commits] CMake branch, release, updated. v3.9.0-rc6-2-gd11c48e

[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  d11c48e0e344e6758a5575330b3f0e267d820e02 (commit)
   via  4bafa3922e3773e5bcc6741994379455c7d1c0fc (commit)
  from  25b72e9097260d1faf254155a1199886c808a58f (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/Platform/Android-Common.cmake |1 -
 Source/cmGeneratorTarget.cxx  |   12 
 Source/cmLocalGenerator.cxx   |   14 ++
 Tests/RunCMake/Android/android_sysinc.c   |7 +++
 Tests/RunCMake/Android/android_sysinc.cxx |7 +++
 Tests/RunCMake/Android/common.cmake   |   16 
 Tests/RunCMake/Android/sysinc/dlfcn.h |1 +
 7 files changed, 45 insertions(+), 13 deletions(-)
 create mode 100644 Tests/RunCMake/Android/android_sysinc.c
 create mode 100644 Tests/RunCMake/Android/android_sysinc.cxx
 create mode 100644 Tests/RunCMake/Android/sysinc/dlfcn.h


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

Re: [cmake-developers] Using USES_TERMINAL in ExternalProject.cmake

[Nils Gladitz]

On 13.07.2017 22:19, Robert Dailey wrote:

I noticed that ExternalProject_Add() has this same issue when run from
Ninja. I do not see real-time output of the progress. Would it work to
set USES_TERMINAL for most (if not all) custom commands and targets in
ExternalProject.cmake?


See the USES_TERMINAL_* options in 
https://cmake.org/cmake/help/latest/module/ExternalProject.html (since 
3.4) but beware that there can be only one job in the console pool at a 
time so this might also reduce parallelization.


Nils
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Using USES_TERMINAL in ExternalProject.cmake

[Robert Dailey]

In my own personal usage of add_custom_target() and
add_custom_command(), I use USES_TERMINAL so that stdout and stderr
from commands that are actively running get output in more real-time.
I've only tested this using the Ninja generator, and seems to improve
output behavior.

Without it, I notice that commands that take a long time to complete
result in a large window of silence. When the command completes, all
of its output (sometimes thousands of lines) gets spit out all at
once. This makes things weird, especially for things like download
progress.

I noticed that ExternalProject_Add() has this same issue when run from
Ninja. I do not see real-time output of the progress. Would it work to
set USES_TERMINAL for most (if not all) custom commands and targets in
ExternalProject.cmake?
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-285-g52db8d5

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

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6a45aec..1772ae5 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 9)
-set(CMake_VERSION_PATCH 20170713)
+set(CMake_VERSION_PATCH 20170714)
 #set(CMake_VERSION_RC 1)

---

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


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

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-263-ge5c762d

[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  e5c762d32d8a1329aac66a66eaf634a009cb288b (commit)
   via  c8f4cf0821d86e705d255dcd03fa28e9558df83d (commit)
   via  0c5723821542a43fa211c73abc08e59e2fd395e2 (commit)
   via  2c82d9c81f869303d3202501665acd91311d7714 (commit)
   via  4db32275149e2a68c74d2abf5158ee29976b7300 (commit)
  from  3d209acc1fdb96a213fba0442af7c2719e4d2a36 (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=e5c762d32d8a1329aac66a66eaf634a009cb288b
commit e5c762d32d8a1329aac66a66eaf634a009cb288b
Merge: c8f4cf0 0c57238
Author: Brad King 
AuthorDate: Thu Jul 13 11:42:56 2017 +
Commit: Kitware Robot 
CommitDate: Thu Jul 13 07:44:11 2017 -0400

Merge topic 'server-target-backtraces'

0c572382 server: Report backtraces in codemodel response
4db32275 server: Rename cmServerProtocol1_0 to cmServerProtocol1

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8f4cf0821d86e705d255dcd03fa28e9558df83d
commit c8f4cf0821d86e705d255dcd03fa28e9558df83d
Merge: 3d209ac 2c82d9c
Author: Brad King 
AuthorDate: Thu Jul 13 11:42:31 2017 +
Commit: Kitware Robot 
CommitDate: Thu Jul 13 07:42:42 2017 -0400

Merge topic 'source-group-regex-tweaks'

2c82d9c8 Add more extensions to Resources source group by default

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c5723821542a43fa211c73abc08e59e2fd395e2
commit 0c5723821542a43fa211c73abc08e59e2fd395e2
Author: Ivan Shcherbakov 
AuthorDate: Tue Jun 20 14:13:01 2017 -0700
Commit: Brad King 
CommitDate: Tue Jul 11 07:50:22 2017 -0400

server: Report backtraces in codemodel response

Report the source locations (e.g. in `CMakeLists.txt`) for all targets
and target-related statements.  This allows IDEs to locate the
statements and automatically edit them when the user adds or removes
files or changes target properties via GUI.

Increment the protocol minor version number to tell clients that the new
information is available.

diff --git a/Help/manual/cmake-server.7.rst b/Help/manual/cmake-server.7.rst
index 9520cc1..211ebe4 100644
--- a/Help/manual/cmake-server.7.rst
+++ b/Help/manual/cmake-server.7.rst
@@ -496,6 +496,9 @@ Each target object can have the following keys:
   with the sysroot path.
 "fileGroups"
   contains the source files making up the target.
+"crossReferences"
+  contains the location of the target in the corresponding CMakeLists.txt
+  file and the locations of the related statements like "target_link_libraries"
 
 FileGroups are used to group sources using similar settings together.
 
@@ -521,6 +524,16 @@ Each fileGroup object may contain the following keys:
 All file paths in the fileGroup are either absolute or relative to the
 sourceDirectory of the target.
 
+CrossReferences object is used to report the location of the target (including
+the entire call stack if the target is defined in a function) and the related
+"target_link_libraries", "target_include_directories", 
"target_compile_definitions"
+and "target_compile_options" statements.
+
+See the example below for details on the internal format of the 
"crossReferences" object.
+Line numbers stated in the "backtrace" entries are 1-based. The last entry of 
a backtrace
+is a special entry with missing "line" and "name" fields that specifies the 
initial
+CMakeLists.txt file.
+
 Example::
 
   [== "CMake Server" ==[
@@ -557,7 +570,34 @@ CMake will reply::
 "linkerLanguage": "C",
 "name": "cmForm",
 "sourceDirectory": 
"/home/code/src/cmake/Source/CursesDialog/form",
-"type": "STATIC_LIBRARY"
+"type": "STATIC_LIBRARY",
+"crossReferences": {
+   "backtrace": [
+  {
+ "line": 7,
+ "name": "add_executable",
+ "path": "C:/full/path/CMakeLists.txt"
+  },
+  {
+ "path": "c:/full/path/CMakeLists.txt"
+  }
+   ],
+   "relatedStatements": [
+  {
+ "backtrace": [
+{
+   "line": 8,
+

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-280-gaa97170

[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  aa97170f2b25a99d2cc69fd6b2a059e52872f341 (commit)
   via  80f59ee60289019e3d1eac0c018039a7f22a (commit)
  from  a4a39a46c34c1227be999eb10dd39ddeb70ada7b (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=aa97170f2b25a99d2cc69fd6b2a059e52872f341
commit aa97170f2b25a99d2cc69fd6b2a059e52872f341
Merge: a4a39a4 80f59ee
Author: Brad King 
AuthorDate: Thu Jul 13 12:23:52 2017 +
Commit: Kitware Robot 
CommitDate: Thu Jul 13 08:23:56 2017 -0400

Merge topic 'win10-sdk-request-mismatch'

80f59ee6 cmGlobalVisualStudio14Generator: notify when the SDK version 
doesn't match

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=80f59ee60289019e3d1eac0c018039a7f22a
commit 80f59ee60289019e3d1eac0c018039a7f22a
Author: Ben Boeckel 
AuthorDate: Wed May 17 14:23:53 2017 -0400
Commit: Ben Boeckel 
CommitDate: Thu Jul 13 08:10:57 2017 -0400

cmGlobalVisualStudio14Generator: notify when the SDK version doesn't match

When requesting an SDK version which is not suitable (e.g., missing
`windows.h`), CMake will use the next-best SDK version. Output a message
when CMake chooses something different than the requested SDK version.

See #16895.

diff --git a/Source/cmGlobalVisualStudio14Generator.cxx 
b/Source/cmGlobalVisualStudio14Generator.cxx
index c8cf02c..e2120b8 100644
--- a/Source/cmGlobalVisualStudio14Generator.cxx
+++ b/Source/cmGlobalVisualStudio14Generator.cxx
@@ -151,6 +151,13 @@ bool 
cmGlobalVisualStudio14Generator::SelectWindows10SDK(cmMakefile* mf,
 mf->IssueMessage(cmake::FATAL_ERROR, e.str());
 return false;
   }
+  if (!cmSystemTools::VersionCompareEqual(this->WindowsTargetPlatformVersion,
+  this->SystemVersion)) {
+std::ostringstream e;
+e << "Selecting Windows SDK version " << this->WindowsTargetPlatformVersion
+  << " to target Windows " << this->SystemVersion << ".";
+mf->DisplayStatus(e.str().c_str(), -1);
+  }
   mf->AddDefinition("CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION",
 this->WindowsTargetPlatformVersion.c_str());
   return true;

---

Summary of changes:
 Source/cmGlobalVisualStudio14Generator.cxx |7 +++
 1 file changed, 7 insertions(+)


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