Re: [cmake-developers] Properly Documenting a CMake Module

2019-02-13 Thread Torsten Robitzki


> Am 13.02.2019 um 13:42 schrieb Brad King via cmake-developers 
> :
> 
> The online docs, like those at https://cmake.org/cmake/help/v3.14
> do publish a `/objects.inv` to support intersphinx:
> 
>  http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html
> 
> This was done on request of some users so I haven't looked into how
> that works, but one should be able to use sphinx to generate one's
> own documentation and still cross-reference CMake’s online docs.

I can confirm that this works as expected. Used it by myself.


signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

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

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

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

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

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


[cmake-developers] Support for list length expression in if()-command?

2019-01-14 Thread Torsten Robitzki
Hi,
I have a customer that requires quite often to check, whether a list contains 
at least a given number of elements. As we do not have functions with return 
values, this requires him to inquire the length of a list before taking special 
actions.

To simplify that task (and without larger changes in CMake [like introducing 
*real* functions]), he came up with the idea to extend the if()-command with a 
LENGTH operator:

set(list)

…

if (LENGTH list GREATER 1)
…
endif()

Would such an extension be accepted as pull request, if we would provide it?

regards,

Torsten



signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

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

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

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

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

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


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

2018-12-22 Thread Torsten Robitzki
Hi,

> Am 17.12.2018 um 21:18 schrieb Kyle Edwards via cmake-developers 
> :
> 
> Then, executables and libraries could have a toolchain specified:
> 
> add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
> add_library(MyLibrary TOOLCHAIN CrossToolchain …)

or even toolchains:

add_library(feature1 TOOLCHAINS CrossToolChain HostToolChain)

add_executable(Firmware TOOLCHAIN CrossToolChain)
target_link_libraries(Firmware feature1)

add_executable(Test_Feature1 TOOLCHAIN HostToolChain)
target_link_libraries(Test_Feature1 feature1)

A nice feature would be to let toolchain propagate along the dependency graph 
defined by `target_link_libraries`. So in the example above, the TOOLCHAINS 
option to `add_library` would be optional, because the target Firmware requires 
feature1 to be build with CrossToolChain and Test_Feature1 to be build with 
HostToolChain. Which requires the build to have different binary directories 
for every toolchain. (Which for me is an indication that having 
multidimensional build types would be the more natural way to go)

What I’m still missing is support to define dependencies between different 
targets (build by different toolchains), so that I can describe that I require 
a tool that is build with the HostToolChain, to generate a file that is 
required by the part of the build, that is using the CrossToolChain. And, of 
cause, if the source of that tool changes, that tool have to be rebuild and the 
generated file from the CrossToolChain part of the build have to be rebuild.

best regards,

Torsten


signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

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

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

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

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

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


[cmake-developers] Test for list size

2018-12-12 Thread Torsten Robitzki
Hi,
we have often the need to test for a minimum list size

  list(LENGTH list list_size)
  if (list_size GREATER 1)
  …

This happens so much, that we though it might be helpful to extend the 
if-syntax to allow this to be written in a more compact way. For example:

  if (LENGTH list GREATER 1)
  …

Or maybe by introducing functions that can return values (length being a 
„function“ here):

  if (length[list] GREATER 1)
  …

What do you think? Are we the only ones that could make good use out of this 
extension?

best regards,

Torsten




signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

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

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

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

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

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


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

2018-12-03 Thread Torsten Robitzki
> Am 27.11.2018 um 19:55 schrieb Eric Noulard :
> 
> 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.

In case, you are doing unit tests, it’s normal to have the same code running in 
a test on the host platform and in the final binary on the target.

I think, having more than 1 target platform becomes more and more normal as it 
becomes more usual to have multiple microcontrollers in a project.

Previously, I have encoded this in the build type. So instead of just having 
Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug, NRF51_Release, 
STM8_Debug, STM8_Release and so on. It doesn’t annoy me very much, that I have 
to run CMake 3 times to get all the binaries for a release build. The problem 
that I have, are dependencies between this builds. If I write a tool that (for 
example) generates source files for one of the target platforms, the build for 
the host platform must run before the build for that target platform. And when 
I make changes to that tool, I want the build to regenerate the generated 
source files.

Keeping track of this dependencies to solve this kind of ordering issues and to 
allow minimum rebuilds, is the main purpose of any build system. To solve this 
with CMake, I think we need a way to define the dependencies between build 
types (in the example above, from the generator from the host build to the 
generated source file in one of the target builds) and CMake needs to know the 
build directory for all build types (not only the current).

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

How about ``add_dependencies()`` allowing me to define dependencies between 
different build types? :-)

best regards,
Torsten


signature.asc
Description: Message signed with OpenPGP
-- 

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