Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

On 15-Mar-16 02:42, Tamás Kenéz wrote:
I also doubt this belongs to upstream. But you could write a single, 
generic script which forwards its arguments to cmake and also accepts 
and processes the additional parameters along the way. I don't think 
we'd lose anything:


cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. 
But if there would be a mature, versatile, community-tested script I'd 
be willing to use it and contribute to it.
As you can see I'm already using script `build.py` and there is not 
enough power for now (even if it extends CMake basic functionality a 
lot) so I was thinking to introduce global/local ini-configuration file 
anyway. Then I realize that most of the `build.py` functions can be 
implemented in such ini-configuration. So why not use CMake? Why for 
example not extend CMake GUI with this feature support? Why do users 
need to install some extra tools instead of just one?


Global/local configuration files in not something special. Git for 
example has same system, yes it increase complexity but literally every 
user store setting there.

Just imagine you have to write something like this every commit + push:

> git commit --author="John Doe" --email="john@example.com" 
--branch="master"

> git push --remote="git://awesome.example.com"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even if it 
will not accepted to upstream.


Ruslo



Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers 
> wrote:


On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually hold
some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands doesn't
change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I personally
use a Python one).

Sorry, I don't think something like this belongs upstream.  It
can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that family
of custom scripts (+ a lot of environment variables in .bashrc) 
is an "easy shell scripting", example:

*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake command
line interface further.

To be clear this feature required only one new CMake option. The
rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of my
point that can be provided here is a users experience. Since I
don't see any feedback here I'm out of arguments...

Ruslo

-- 


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




-- 

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] [CMake 0016020]: FindBoost "Automatically add missing component dependencies" fails with header-only libraries

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16020 
== 
Reported By:Tom Jakubowski
Assigned To:
== 
Project:CMake
Issue ID:   16020
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-14 22:00 EDT
Last Modified:  2016-03-14 22:00 EDT
== 
Summary:FindBoost "Automatically add missing component
dependencies" fails with header-only libraries
Description: 
If only some separately-compiled Boost libraries are installed, so that Boost
components like Boost.Atomic and Boost.DateTime are used header-only,
find_package(Boost REQUIRED COMPONENTS thread) will fail with:

:1647 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.56.0

  Boost include path: /opt/foo/deps-64-10/include

  Could not find the following Boost libraries:

  boost_atomic
  boost_chrono
  boost_date_time

If a full installation of Boost 1.56, with all optional separately-compiled
libraries, is used instead, then the FindBoost() call succeeds.

This is a regression from CMake 3.4. It seems like
https://github.com/Kitware/CMake/commit/01c80acdbdadf3811bc0a6cab0c28469a4e9f5b7
is probably responsible.

Also related to bug 15767.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-14 22:00 Tom Jakubowski New Issue
==

-- 

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] [PATCH] Ninja: Optionally skip library dependencies for object targets

[Matthias Männich]

Hi,

this is a patch that we use since some time for a quite large in-house
project. The idea behind is to increase build parallelism by omitting
dependencies of object file targets to the libraries they will be linked
with in a later step. As this is not always the desired behaviour the
default remains untouched and the setting can be changed globally and per
target.

We found this functionality quite useful, especially in combination with
build clusters like icecream or distcc.
I recently got asked by another project to bring this upstream.

Thanks for consideration!

Best regards,

Matthias
From da66b26a8c04132ef5f65854c1261af573e00cbe Mon Sep 17 00:00:00 2001
From: Matthias Maennich 
Date: Tue, 15 Mar 2016 00:17:21 +0100
Subject: [PATCH] Ninja: Optionally skip library dependencies for object
 targets

This change introduces a new target property COMPILE_DEPENDS_NO_LIB.
If the property is set, all object file targets belonging to the target
omit their dependencies to link libraries of type MODULE, OBJECT, STATIC
and SHARED.

Specifying COMPILE_DEPENDS_NO_LIB enables this behaviour for a target. The
variable CMAKE_COMPILE_DEPENDS_NO_LIB can be used to enable this behaviour
for all targets defined afterwards as it defines the default for new
targets.
---
 Help/manual/cmake-properties.7.rst |  1 +
 Help/manual/cmake-variables.7.rst  |  1 +
 Help/prop_tgt/COMPILE_DEPENDS_NO_LIB.rst   | 45 ++
 Help/variable/CMAKE_COMPILE_DEPENDS_NO_LIB.rst |  8 
 Source/cmGlobalNinjaGenerator.cxx  | 17 +++-
 Source/cmGlobalNinjaGenerator.h|  3 +-
 Source/cmLocalNinjaGenerator.cxx   |  6 ++-
 Source/cmLocalNinjaGenerator.h |  3 +-
 Source/cmNinjaTargetGenerator.cxx  |  2 +-
 Source/cmTarget.cxx|  1 +
 Tests/RunCMake/CMakeLists.txt  |  1 +
 .../RunCMake/compile_depends_no_lib/CMakeLists.txt |  3 ++
 .../compile_depends_no_lib/RunCMakeTest.cmake  | 16 
 .../compile_depends_no_lib/Test-dep1-stdout.txt|  3 ++
 .../compile_depends_no_lib/Test-dep2-stdout.txt|  1 +
 .../compile_depends_no_lib/Test-dep3-stdout.txt|  1 +
 .../compile_depends_no_lib/Test-dep4-stdout.txt|  3 ++
 Tests/RunCMake/compile_depends_no_lib/Test.cmake   | 29 ++
 18 files changed, 137 insertions(+), 7 deletions(-)
 create mode 100644 Help/prop_tgt/COMPILE_DEPENDS_NO_LIB.rst
 create mode 100644 Help/variable/CMAKE_COMPILE_DEPENDS_NO_LIB.rst
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/CMakeLists.txt
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/RunCMakeTest.cmake
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/Test-dep1-stdout.txt
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/Test-dep2-stdout.txt
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/Test-dep3-stdout.txt
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/Test-dep4-stdout.txt
 create mode 100644 Tests/RunCMake/compile_depends_no_lib/Test.cmake

diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst
index d6618fe..b9cfc10 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -126,6 +126,7 @@ Properties on Targets
/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN
/prop_tgt/COMPATIBLE_INTERFACE_STRING
/prop_tgt/COMPILE_DEFINITIONS
+   /prop_tgt/COMPILE_DEPENDS_NO_LIB
/prop_tgt/COMPILE_FEATURES
/prop_tgt/COMPILE_FLAGS
/prop_tgt/COMPILE_OPTIONS
diff --git a/Help/manual/cmake-variables.7.rst b/Help/manual/cmake-variables.7.rst
index cb50051..c15f618 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -242,6 +242,7 @@ Variables that Control the Build
/variable/CMAKE_AUTOUIC
/variable/CMAKE_AUTOUIC_OPTIONS
/variable/CMAKE_BUILD_WITH_INSTALL_RPATH
+   /variable/CMAKE_COMPILE_DEPENDS_NO_LIB
/variable/CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY
/variable/CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY_CONFIG
/variable/CMAKE_CONFIG_POSTFIX
diff --git a/Help/prop_tgt/COMPILE_DEPENDS_NO_LIB.rst b/Help/prop_tgt/COMPILE_DEPENDS_NO_LIB.rst
new file mode 100644
index 000..2ab8019
--- /dev/null
+++ b/Help/prop_tgt/COMPILE_DEPENDS_NO_LIB.rst
@@ -0,0 +1,45 @@
+COMPILE_DEPENDS_NO_LIB
+--
+
+Ninja only: Whether object files skip dependencies on their target's link libraries.
+
+When set for a target the object file targets will not specify a dependency on
+the target's link libraries. This way the object files can already be built even
+though the target link libraries are not yet available.
+
+As an example consider the following snippet:
+
+.. code-block:: cmake
+
+ADD_LIBRARY(mylib lib.c)
+
+ADD_EXECUTABLE(myexe exe.c)
+TARGET_LINK_LIBRARIES(myexe lib)
+
+As the target ``mylib`` might specify some more outputs (e.g. via

[cmake-developers] [CMake 0016019]: cmake-mode.el: cmake-help: one help item is missing for each 'type'

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=16019 
== 
Reported By:Julian Schmidt
Assigned To:
== 
Project:CMake
Issue ID:   16019
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   low
Status: new
== 
Date Submitted: 2016-03-14 19:28 EDT
Last Modified:  2016-03-14 19:28 EDT
== 
Summary:cmake-mode.el: cmake-help: one help item is missing
for each 'type'
Description: 
In the Emacs mode cmake-mode.el, the available help items for
cmake-help-command, cmake-help-module, ... are missing the first item each as
printed, respectively, by "cmake --help-TYPE".


Steps to Reproduce: 
In Emacs 24.5.1, with cmake-model.el from git tag v3.5.0-rc3, do

M-x cmake-help

Then in the auto-completion, e.g. 'add_compile_options' will not be available.

This seems to be an off-by-one error which can be fixed like so:

==
diff --git a/Auxiliary/cmake-mode.el b/Auxiliary/cmake-mode.el
index 08ac490..321177a 100644
--- a/Auxiliary/cmake-mode.el
+++ b/Auxiliary/cmake-mode.el
@@ -304,7 +304,7 @@ and store the result as a list in LISTVAR."
   (save-window-excursion
 (cmake-command-run (concat "--help-" listname "-list") nil
temp-buffer-name)
 (with-current-buffer temp-buffer-name
-  (set listvar (cdr (split-string (buffer-substring-no-properties
(point-min) (point-max)) "\n" t))
+  (set listvar (split-string (buffer-substring-no-properties
(point-min) (point-max)) "\n" t)
   (symbol-value listvar)
   ))
   )
==
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-14 19:28 Julian Schmidt New Issue
==

-- 

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] BUG: ALL_BUILD not added to the PREDEFINED_TARGETS_FOLDER

[Taylor Braun-Jones]

For the Visual Studio generator, the ALL_BUILD is not added to the
PREDEFINED_TARGETS_FOLDER ("CMakePredefinedTargets").

Tested on Windows 10 with Visual Studio 2013 using the following
minimal CMakeLists.txt:

cmake_minimum_required(VERSION 3.5)
project(foobar)
set_property(GLOBAL PROPERTY USE_FOLDERS ON)

Targets like ZERO_CHECK, INSTALL, and RUN_TESTS work for me; just not ALL_BUILD.

Thanks,
Taylor
-- 

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

Re: [cmake-developers] CMake aliasing system

[Tamás Kenéz]

I also doubt this belongs to upstream. But you could write a single,
generic script which forwards its arguments to cmake and also accepts and
processes the additional parameters along the way. I don't think we'd lose
anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. But if
there would be a mature, versatile, community-tested script I'd be willing
to use it and contribute to it.

Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
cmake-developers@cmake.org> wrote:

> On 14-Mar-16 21:59, Brad King wrote:
>
>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>
>>> I guess it is a well known fact that cmake command is almost never
>>> executed alone and for non-trivial examples usually hold some extra
>>> arguments (home directory, build directory, verbosity level, toolchains,
>>> options, ...). Also I guess that such commands doesn't change from
>>> day-to-day development process and an obvious way to reduce typing is to
>>> create wrapper build scripts (.bat or .sh, I personally use a Python
>>> one).
>>>
>> Sorry, I don't think something like this belongs upstream.  It can easily
>> be done with shell aliases or other custom scripts.
>>
> I've got quite opposite experience. It's hard to say that family of custom
> scripts (+ a lot of environment variables in .bashrc)  is an "easy shell
> scripting", example:
> *
> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>
>We shouldn't increase the complexity of the CMake command line
>> interface further.
>>
> To be clear this feature required only one new CMake option. The rest is
> responsibility of some pre-build parsing module.
>
> In general I feel sad that CMake will not became more user-friendly in
> this exact part. Though the only proves of my point that can be provided
> here is a users experience. Since I don't see any feedback here I'm out of
> arguments...
>
> Ruslo
>
> --
>
> 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
>
-- 

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] [CMake 0016018]: macros CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS don't work

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16018 
== 
Reported By:abductor
Assigned To:
== 
Project:CMake
Issue ID:   16018
Category:   CMake
Reproducibility:always
Severity:   block
Priority:   immediate
Status: new
== 
Date Submitted: 2016-03-14 13:41 EDT
Last Modified:  2016-03-14 13:41 EDT
== 
Summary:macros CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS don't work
Description: 
class consist static member and method.

macros CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS don't export this method and member out
dll/lib
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-14 13:41 abductor   New Issue
==

-- 

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

Re: [cmake-developers] CTest custom HTML

[Charles Huet]

Yeah, makes sense.

Thanks so much for your time

Le lun. 14 mars 2016 à 15:58, Brad King  a écrit :

> On 03/14/2016 05:13 AM, Charles Huet wrote:
> > If the CTest parser parsed the output as XML and not simple text, it
> should be
> > able to recognize CDATA from actual markup.
> [snip]
> > If you don't think this is doable (or you don't want to integrate this
> kind
> > of behavior into CTest) we'll customize CDash and I'll stop badgering
> you about this.
> >
> > But I'd rather do this as a last resort.
>
> I'm sorry but I don't want to introduce any special interpretation of test
> output beyond the hooks that are already present.  In principle the test
> output is just plain text and the fact that it could be interpreted as
> XML or JSON or some other markup is not CTest's business.  It is encoded
> in Test.xml for submission to CDash or some other similar system with
> all escaping needed to communicate the real test output to that system.
>
> -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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:

I guess it is a well known fact that cmake command is almost never
executed alone and for non-trivial examples usually hold some extra
arguments (home directory, build directory, verbosity level, toolchains,
options, ...). Also I guess that such commands doesn't change from
day-to-day development process and an obvious way to reduce typing is to
create wrapper build scripts (.bat or .sh, I personally use a Python one).

Sorry, I don't think something like this belongs upstream.  It can easily
be done with shell aliases or other custom scripts.
I've got quite opposite experience. It's hard to say that family of 
custom scripts (+ a lot of environment variables in .bashrc)  is an 
"easy shell scripting", example:
* 
https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py



   We shouldn't increase the complexity of the CMake command line interface 
further.
To be clear this feature required only one new CMake option. The rest is 
responsibility of some pre-build parsing module.


In general I feel sad that CMake will not became more user-friendly in 
this exact part. Though the only proves of my point that can be provided 
here is a users experience. Since I don't see any feedback here I'm out 
of arguments...


Ruslo
--

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

Re: [cmake-developers] CTest custom HTML

[Brad King]

On 03/14/2016 05:13 AM, Charles Huet wrote:
> If the CTest parser parsed the output as XML and not simple text, it should be
> able to recognize CDATA from actual markup.
[snip]
> If you don't think this is doable (or you don't want to integrate this kind
> of behavior into CTest) we'll customize CDash and I'll stop badgering you 
> about this.
> 
> But I'd rather do this as a last resort.

I'm sorry but I don't want to introduce any special interpretation of test
output beyond the hooks that are already present.  In principle the test
output is just plain text and the fact that it could be interpreted as
XML or JSON or some other markup is not CTest's business.  It is encoded
in Test.xml for submission to CDash or some other similar system with
all escaping needed to communicate the real test output to that system.

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindGTest modification

[Brad King]

On 03/11/2016 12:00 PM, Zak Eckert wrote:
> + configure_file(${source} ${source}.out COPYONLY)

Thanks.  Please try using CMAKE_CONFIGURE_DEPENDS instead:

  https://cmake.org/cmake/help/v3.5/prop_dir/CMAKE_CONFIGURE_DEPENDS.html

It should be something like:

  set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${source})

Thanks,
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake aliasing system

[Brad King]

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
> I guess it is a well known fact that cmake command is almost never 
> executed alone and for non-trivial examples usually hold some extra 
> arguments (home directory, build directory, verbosity level, toolchains, 
> options, ...). Also I guess that such commands doesn't change from 
> day-to-day development process and an obvious way to reduce typing is to 
> create wrapper build scripts (.bat or .sh, I personally use a Python one).

Sorry, I don't think something like this belongs upstream.  It can easily
be done with shell aliases or other custom scripts.  We shouldn't increase
the complexity of the CMake command line interface further.

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CPack includes WINTRUST.DLL

[Brad King]

On 03/12/2016 05:19 PM, Roman Wüger wrote:
> Yes, i use fixup_bundle.
> Is there a better alternative?

No, but you'll have to trace through its execution to see where it
picks up the dependency on wintrust.dll.

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Duplicated linking flags are removed when linking final executable

[Brad King]

On 03/14/2016 09:33 AM, Sergio Checa wrote:
> target_link_libraries(L
> -Wl,-whole-archive A -Wl,-no-whole-archive
> -Wl,-whole-archive B -Wl,-no-whole-archive
> )
> 
> add_executable(main main.cpp)
> target_link_libraries(main L)

Specifying flags anywhere except the final executable's target_link_libraries
is not very well defined.  I'd rather not try to define behavior different
than has been there for a long time.

It looks like you're trying to achieve what OBJECT libraries are for:

  https://cmake.org/cmake/help/v3.5/command/add_library.html#object-libraries

Please try that approach instead.

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindBoost.cmake Clang support

[Brad King]

On 03/12/2016 12:42 PM, Manu Sánchez wrote:
> I'm reaching you to ask about Clang support in the FindBoost.cmake script.
[snip]
> if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
> execute_process(COMMAND ${CMAKE_CXX_COMPILER} --version 
> OUTPUT_VARIABLE out)

Thanks.  Rather than running the compiler you should be able to get the
version from CMAKE_CXX_COMPILER_VERSION.  Please revise the logic
accordingly.

Actually it looks like current uses of _Boost_COMPILER_DUMPVERSION
could be refactored to use CMAKE_CXX_COMPILER_VERSION too.

Thanks,
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [RFC] FindAndroidNDK and UseAndroidNDK

[Brad King]

On 03/12/2016 04:05 AM, Xiaolei Yu wrote:
> my team decided to ditch ndk-build and migrate to cmake. And I would 
> like to upstream these two modules, which are currently used in my hobby 
> projects.

Thanks.  Yes, code to search for the Android NDK or a standalone toolchain
belongs in CMake upstream rather than in the toolchain file.  However, it
should not have to be a separate find_package(AndroidNDK) step.  The right
place is likely in a Modules/Platform/Android-Initialize.cmake file similar
to the Modules/Platform/Darwin-Initialize.cmake file already used to find
the OS X SDK.  The Android-Initialize file will be loaded automatically
when a toolchain file sets CMAKE_SYSTEM_NAME to Android.

I've long wished to see work along these lines done, but it is not trivial.
The selection of STL, ARCH, etc. all need to be presented cleanly as options
to the user as cache entries with reasonable defaults.  It all needs to be
done as part of the Android platform information modules and not activated
by any explicit code in the project.  I'm not sure how it should properly
mix with selection of the actual toolchain (compiler).

In particular, selecting the STL may need some additional changes on the
C++ side of the CMake implementation.  Instead of code like

>   include_directories ( SYSTEM
> ${_gnustl}/libs/${CMAKE_LIBRARY_ARCHITECTURE}/include
> ${_gnustl}/include
>   )

we need an equivalent to CMAKE_CXX_STANDARD_LIBRARIES for system include
directories that come from the SDK.

> 1. using CMAKE_LIBRARY_ARCHITECTURE to represent android 
> TARGET_ARCH_ABI.

CMAKE_LIBRARY_ARCHITECTURE affects the find_* logic and I do not think it
should be overloaded with additional meanings.  A simple CMAKE_ANDROID_ARCH
cache entry in the Android-Initialize module discussed above may be sufficient.

Thanks,
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0016017]: Setting OPTION to ON results in FALSE

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16017 
== 
Reported By:Abai
Assigned To:
== 
Project:CMake
Issue ID:   16017
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-03-14 10:37 EDT
Last Modified:  2016-03-14 10:37 EDT
== 
Summary:Setting OPTION to ON results in FALSE
Description: 
It seems that setting an arbitrary option to ON results in variable to be set to
OFF instead. I am certain that the variable is not cached too. See the example
below to reproduce.

Here is the output from the attached CMakeLists.txt:

-- The C compiler identification is AppleClang 7.0.2.7000181
-- The CXX compiler identification is AppleClang 7.0.2.7000181
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- WAX is not defined.
-- Setting WAX=ON.
-- Results in WAX=OFF
-- Configuring done
-- Generating done

The only workaround I found around is (FORCE is required even with empty cache):

SET(WAX ON CACHE BOOL "" FORCE)

Steps to Reproduce: 
PROJECT(OPTION_BUG)

CMAKE_MINIMUM_REQUIRED(VERSION 3.5.0 FATAL_ERROR)

IF(NOT DEFINED WAX)
MESSAGE(STATUS "WAX is not defined.")
ENDIF()
MESSAGE(STATUS "Setting WAX=ON.")
OPTION(WAX ON)
MESSAGE(STATUS "Results in WAX=${WAX}")

Additional Information: 
CMake version 3.5.0 installed with home-brew on OSX 10.11.3
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-14 10:37 Abai   New Issue
2016-03-14 10:37 Abai   File Added: CMakeLists.txt
==

-- 

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] Duplicated linking flags are removed when linking final executable

[Sergio Checa]

Hello,

This is my first email to this list, so please tell me if I'm not following the 
contribution process properly.

Here is the scenario that I am working on:


  .--->  -flags  A
  |
main > L -|
  |
  '--->  -flags  B

If "-flags" are the same text, only one occurrence appears in the resulting 
linking line in the target's generated link.txt.

This is a simple CMakeLists.txt that reproduces the above (doesn't build 
anything):

cmake_minimum_required(VERSION 3.5)

file(WRITE a.cpp "")
file(WRITE b.cpp "")
file(WRITE lib.cpp "")
file(WRITE main.cpp "")

add_library(A STATIC a.cpp)
add_library(B STATIC b.cpp)

add_library(L STATIC lib.cpp)

target_link_libraries(L
-Wl,-whole-archive A -Wl,-no-whole-archive
-Wl,-whole-archive B -Wl,-no-whole-archive
)

add_executable(main main.cpp)
target_link_libraries(main L)

When linking, only one occurrence of "-Wl,-whole-archive" and one of 
"-Wl,-no-whole-archive" are kept. The others are filtered out.

All the best,
Sergio
From 155d039bedfd0cd517866ea131882360700f82a5 Mon Sep 17 00:00:00 2001
From: Sergio Checa Blanco 
Date: Mon, 14 Mar 2016 13:34:43 +0100
Subject: [PATCH] Duplicated linking flags are removed

Duplicated flags are not allowed when linking library targets
into a final executable target.

The following CMakeLists.txt can be used to test the
effect of the patch, by checking the content of the
generated file CMakeFiles/main.dir/link.txt.

  cmake_minimum_required(VERSION 3.5)

  file(WRITE a.cpp "")
  file(WRITE b.cpp "")
  file(WRITE lib.cpp "")
  file(WRITE main.cpp "")

  add_library(A STATIC a.cpp)
  add_library(B STATIC b.cpp)

  add_library(L STATIC lib.cpp)

  target_link_libraries(L
  -Wl,-whole-archive A -Wl,-no-whole-archive
  -Wl,-whole-archive B -Wl,-no-whole-archive
  )

  add_executable(main main.cpp)
  target_link_libraries(main L)
---
 Source/cmComputeLinkDepends.cxx | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Source/cmComputeLinkDepends.cxx b/Source/cmComputeLinkDepends.cxx
index 2796fdf..08df390 100644
--- a/Source/cmComputeLinkDepends.cxx
+++ b/Source/cmComputeLinkDepends.cxx
@@ -298,6 +298,7 @@ cmComputeLinkDepends::AllocateLinkEntry(std::string const& item)
 index_entry(item, static_cast(this->EntryList.size()));
   std::map::iterator
 lei = this->LinkEntryIndex.insert(index_entry).first;
+  lei->second = this->EntryList.size();
   this->EntryList.push_back(LinkEntry());
   this->InferredDependSets.push_back(0);
   this->EntryConstraintGraph.push_back(EdgeList());
@@ -307,9 +308,12 @@ cmComputeLinkDepends::AllocateLinkEntry(std::string const& item)
 //
 int cmComputeLinkDepends::AddLinkEntry(cmLinkItem const& item)
 {
+  bool itemIsFlag = (!item.Target && item[0] == '-' && item[1] != 'l' &&
+ item.substr(0, 10) != "-framework");
+
   // Check if the item entry has already been added.
   std::map::iterator lei = this->LinkEntryIndex.find(item);
-  if(lei != this->LinkEntryIndex.end())
+  if(lei != this->LinkEntryIndex.end() && !itemIsFlag)
 {
 // Yes.  We do not need to follow the item's dependencies again.
 return lei->second;
@@ -323,8 +327,7 @@ int cmComputeLinkDepends::AddLinkEntry(cmLinkItem const& item)
   LinkEntry& entry = this->EntryList[index];
   entry.Item = item;
   entry.Target = item.Target;
-  entry.IsFlag = (!entry.Target && item[0] == '-' && item[1] != 'l' &&
-  item.substr(0, 10) != "-framework");
+  entry.IsFlag = itemIsFlag;
 
   // If the item has dependencies queue it to follow them.
   if(entry.Target)
-- 
2.1.3

-- 

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] Support CMAKE_IOS_INSTALL_COMBINED for single architecture targets

[Ruslan Baratov via cmake-developers]

Hi,

Though user can explicitly set CMAKE_IOS_INSTALL_COMBINED=OFF for 
targets with empty list of supported architectures for given SDK (say 
simulator) I think it make sense to handle this case correctly in CMake 
module too. Patch with fix and test attached.


Thanks, Ruslo
>From 1fb0986da2b6ec0df8c0785ead984a1171c16c04 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Mon, 14 Mar 2016 17:27:53 +0700
Subject: [PATCH] Fix iOS combined feature for single architecture targets

If list of valid target architectures is empty for given SDK then there will
be no VALID_ARCHS build setting returned by Xcode. Return "" (empty string)
explicitly in this case. This may happens if CMAKE_IOS_INSTALL_COMBINED is ON
but only one architecture used in target.
---
 Modules/CMakeIOSInstallCombined.cmake  | 12 ++-
 Tests/RunCMake/XcodeProject/RunCMakeTest.cmake | 20 +
 ...OSInstallCombinedSingleArch-install-check.cmake | 25 ++
 .../XcodeIOSInstallCombinedSingleArch.cmake| 19 
 4 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
 create mode 100644 Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch.cmake

diff --git a/Modules/CMakeIOSInstallCombined.cmake b/Modules/CMakeIOSInstallCombined.cmake
index f052a3b..1256f56 100644
--- a/Modules/CMakeIOSInstallCombined.cmake
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -52,7 +52,14 @@ function(_ios_install_combined_get_build_setting sdk variable resultvar)
   endif()
 
   if(NOT output MATCHES " ${variable} = ([^\n]*)")
-message(FATAL_ERROR "${variable} not found.")
+if("${variable}" STREQUAL "VALID_ARCHS")
+  # VALID_ARCHS may be unset by user for given SDK
+  # (e.g. for build without simulator).
+  set("${resultvar}" "" PARENT_SCOPE)
+  return()
+else()
+  message(FATAL_ERROR "${variable} not found.")
+endif()
   endif()
 
   set("${resultvar}" "${CMAKE_MATCH_1}" PARENT_SCOPE)
@@ -72,6 +79,9 @@ function(_ios_install_combined_get_valid_archs sdk resultvar)
   list(REMOVE_ITEM valid_archs "") # remove empty elements
   list(REMOVE_DUPLICATES valid_archs)
 
+  string(REPLACE ";" " " printable "${valid_archs}")
+  _ios_install_combined_message("Architectures (${sdk}): ${printable}")
+
   set("${resultvar}" "${valid_archs}" PARENT_SCOPE)
 endfunction()
 
diff --git a/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake b/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
index 395c74b..b77d5d4 100644
--- a/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
+++ b/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
@@ -97,6 +97,7 @@ if(NOT XCODE_VERSION VERSION_LESS 7)
 endif()
 
 if(NOT XCODE_VERSION VERSION_LESS 6)
+  # XcodeIOSInstallCombined
   set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/XcodeIOSInstallCombined-build)
   set(RunCMake_TEST_NO_CLEAN 1)
   set(RunCMake_TEST_OPTIONS
@@ -114,6 +115,7 @@ if(NOT XCODE_VERSION VERSION_LESS 6)
   unset(RunCMake_TEST_NO_CLEAN)
   unset(RunCMake_TEST_OPTIONS)
 
+  # XcodeIOSInstallCombinedPrune
   set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/XcodeIOSInstallCombinedPrune-build)
   set(RunCMake_TEST_NO_CLEAN 1)
   set(RunCMake_TEST_OPTIONS
@@ -130,4 +132,22 @@ if(NOT XCODE_VERSION VERSION_LESS 6)
   unset(RunCMake_TEST_BINARY_DIR)
   unset(RunCMake_TEST_NO_CLEAN)
   unset(RunCMake_TEST_OPTIONS)
+
+  # XcodeIOSInstallCombinedSingleArch
+  set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/XcodeIOSInstallCombinedSingleArch-build)
+  set(RunCMake_TEST_NO_CLEAN 1)
+  set(RunCMake_TEST_OPTIONS
+"-DCMAKE_INSTALL_PREFIX:PATH=${RunCMake_TEST_BINARY_DIR}/_install"
+"-DCMAKE_IOS_INSTALL_COMBINED=YES")
+
+  file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
+  file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
+
+  run_cmake(XcodeIOSInstallCombinedSingleArch)
+  run_cmake_command(XcodeIOSInstallCombinedSingleArch-build ${CMAKE_COMMAND} --build .)
+  run_cmake_command(XcodeIOSInstallCombinedSingleArch-install ${CMAKE_COMMAND} --build . --target install)
+
+  unset(RunCMake_TEST_BINARY_DIR)
+  unset(RunCMake_TEST_NO_CLEAN)
+  unset(RunCMake_TEST_OPTIONS)
 endif()
diff --git a/Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake b/Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
new file mode 100644
index 000..3c11ae0
--- /dev/null
+++ b/Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
@@ -0,0 +1,25 @@
+function(verify_architecture file)
+  execute_process(
+COMMAND xcrun lipo -info ${RunCMake_TEST_BINARY_DIR}/_install/${file}
+OUTPUT_VARIABLE lipo_out
+ERROR_VARIABLE lipo_err
+RESULT_VARIABLE lipo_result)
+  if(NOT lipo_result EQUAL "0")
+message(SEND_ERROR "lipo -info failed: ${lipo_err}")
+return()
+  endif()
+
+  string(REGEX MATCHALL "is architecture: [^ \n\t]+" 

Re: [cmake-developers] CTest custom HTML

[Charles Huet]

>You could use DartMeasurementFile to upload arbitrary
files with the CTest submission, and then teach CDash what to do with
them.

Hmm, this sounds to me like too much custom logic would be in CDash, which
would never make it upstream, and we have bad experiences maintaining this
kind of patch sets.

>I'd prefer not to add yet another dependency (on xslt).
Yeah, I guessed this would be your answer, it makes sense.

I have had another, simpler (?) idea that would fit everybody's
requirements.
If the CTest parser parsed the output as XML and not simple text, it should
be able to recognize CDATA from actual markup.
Thus replacing the special chars could be done when reading, and the
cmCtestTestHandler::GenerateDartOutput() function could be adapted
easily(?) to write the read XML.

I'm not sure how feasible this would be, but this sounds like the best way
to integrate custom XML in a CTest report.

If you don't think this is doable (or you don't want to integrate this kind
of behavior into CTest) we'll customize CDash and I'll stop badgering you
about this.

But I'd rather do this as a last resort.

Thanks


Le jeu. 10 mars 2016 à 15:29, Brad King  a écrit :

> On 03/10/2016 03:29 AM, Charles Huet wrote:
> > Now the big difficulty in this would be to integrate XSLT2 capabilities
> into CMake.
> [snip]
> > Do you think this coule be viable ?
>
> I'd prefer not to add yet another dependency (on xslt).  CTest defines
> nothing about the format of the test output, besides DartMeasurement hooks.
> It isn't guaranteed to even be displayed on a web page where having
> custom HTML even makes sense.  This really should be done on the
> CDash side.  You could use DartMeasurementFile to upload arbitrary
> files with the CTest submission, and then teach CDash what to do with
> them.
>
> -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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL

[Charles Huet]

Hi,

I modified my patch a bit to use C++98 only, and try to stick to the coding
conventions.

This now adds a target per folder, which contains all the targets in the
folder and all its children folders.

These targets are prefixed with "path/" in order to set them apart of
normal CMake targets.

Please tell me if more modifications are required.
Best.

Le ven. 11 mars 2016 à 16:58, Brad King  a écrit :

> On 03/11/2016 10:48 AM, Charles Huet wrote:
> > Here is a prototype that adds a target for each folder the
> > has the EXCLUDE_FROM_ALL property set.
>
> Is there any reason to limit this to EXCLUDE_FROM_ALL?  Why not
> have a target for every directory with a CMakeLists.txt file?
>
> > I am not satisfied with the way I exclude some build targets,
> > but I could not find the correct way to do it (Install target and such).
>
> See cmGlobalUnixMakefileGenerator3::WriteDirectoryRule2 and
> its call sites for how the Makefile generator decides which
> targets are part of "all" for each directory.  These targets
> in build.ninja should be equivalent to "cd dir; make" in the
> Makefile generator.
>
> > I used C++11, but I don't know if this is OK in CMake, I'll refactor if
> not.
>
> Please use C++98.
>
> Thanks!
> -Brad
>
>
From f3417b48ed8b676b10c06ede83e38fce6703f29a Mon Sep 17 00:00:00 2001
From: Charles Huet 
Date: Fri, 11 Mar 2016 16:26:29 +0100
Subject: [PATCH] Added a target for each EXCLUDED_FROM_ALL folder that holds
 all the targets in said folder

---
 Source/cmGlobalNinjaGenerator.cxx | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 0f06e43..050bc0e 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -1040,6 +1040,62 @@ void cmGlobalNinjaGenerator::WriteTargetAliases(std::ostream& os)
   cmNinjaDeps(1, i->first),
   deps);
   }
+
+  cmGlobalNinjaGenerator::WriteDivider(os);
+  os << "# Folder targets.\n\n";
+
+  std::map targetsPerFolder;
+
+  for ( std::vector::const_iterator generatorIt = this->LocalGenerators.begin();
+generatorIt != this->LocalGenerators.end();
+++generatorIt)
+{
+const cmLocalGenerator* localGenerator = *generatorIt;
+const std::string currentSourceFolder( localGenerator->GetStateSnapshot().GetDirectory().GetCurrentSource() );
+targetsPerFolder[currentSourceFolder] = cmNinjaDeps();
+for ( std::vector::const_iterator targetIt = localGenerator->GetGeneratorTargets().begin();
+  targetIt != localGenerator->GetGeneratorTargets().end();
+  ++targetIt)
+  {
+  const cmGeneratorTarget* generatorTarget = *targetIt;
+
+  const int type = generatorTarget->GetType();
+  if((type == cmState::EXECUTABLE) ||
+ (type == cmState::STATIC_LIBRARY) ||
+ (type == cmState::SHARED_LIBRARY) ||
+ (type == cmState::MODULE_LIBRARY) ||
+ (type == cmState::OBJECT_LIBRARY) ||
+ (type == cmState::UTILITY))
+{
+
+// insert the current target in every folder whose name contains the current target's folder
+for ( std::map::iterator it = targetsPerFolder.begin(); it != targetsPerFolder.end(); ++it )
+  {
+  if( currentSourceFolder.find( it->first ) != std::string::npos )
+{
+it->second.push_back( generatorTarget->GetName() );
+}
+  }
+}
+  }
+}
+
+  for ( std::map::const_iterator it = targetsPerFolder.begin(); it != targetsPerFolder.end(); ++it )
+{
+if ( it->second.empty() )
+  continue;
+
+cmGlobalNinjaGenerator::WriteDivider( os );
+
+cmLocalGenerator* firstLocalGenerator = this->LocalGenerators[0];
+const std::string rootSourceDir = firstLocalGenerator->GetSourceDirectory();
+const std::string folderRelativeToSource = "path/" +  std::string(it->first).replace( 0, rootSourceDir.size() + 1, "" );
+const std::string comment = "Folder: " + std::string(it->first);
+cmNinjaDeps output(1);
+output.push_back( folderRelativeToSource );
+
+this->WritePhonyBuild(os, comment, output, it->second);
+}
 }
 
 void cmGlobalNinjaGenerator::WriteUnknownExplicitDependencies(std::ostream& os)
-- 
1.8.3.1

-- 

Powered by www.kitware.com

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

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

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

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