Re: [cmake-developers] CTest load balancing

[Wouter Klouwen]

On 16/10/2019 15:10, Brad King wrote:
> On 10/16/19 10:05 AM, Wouter Klouwen wrote:
>> Is the intent for CTest to specifically manage CPU load or system load
>> overall?
>
> I don't think a careful distinction was made at the time.
>
> If Linux needs some updates to be consistent with other platforms
> then that would be fine with me.

Unfortunately this may be easier said than done.

Most of the data relevant to this lives in /proc. Indeed the
getloadavg() implementation of glibc merely reads /proc/loadavg*.

For load average the scheduler keeps track of the running 1, 5, 15
minute running averages.

There's /proc/stat which keeps a running total of the CPU usage - the
first lines beginning with `cpu` - but for the purposes of this it is in
the format of usage since boot. In order to replicate a CPU utilisation
only load, you'd effectively have to pick a point in time to start and
then measure since the reference point, which makes things a bit
complicated.

>From the same file you could also take the lines `procs_running` and
`procs_blocked`, sum them and present them as a pseudo load. It would be
a fairly robust calculation. I don't know if this would be quite correct
though.

I might just create an issue for this.

   W


*:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getloadavg.c;hb=HEAD
th

>
> -Brad
>
>
> [External email. Treat hyperlinks and attachments with caution]
>
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
-- 

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] CTest load balancing

[Wouter Klouwen]

Hi all,

CTest has a very useful feature that performs load balancing. This works
by comparing the current system load to a target load.

The current implementation defers to
SystemInformationImplementation::GetLoadAverage() to return a value.
This is implemented on the platforms that have getloadavg() by returning
the first value of that.

While this function is present on many UNIX platforms, on Linux it means
something slightly different than on say Solaris and *BSD. Namely on the
former it is representing a "system load" and on the latter it is "CPU
load", which is a subtle but rather important distinction.

The system load includes processes which are in the uninterruptable
state on purpose, a rather interesting blog post by Brendan Gregg has
some juicy details:
http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

Now, this has recently become a problem for us, as on some of our
systems there are some kernel level processes active that by design are
in the uninterruptable state, therefore contributing to the system load
average, even if they do not affect the CPU load of the system. The
number of processes in this state can easily outnumber the number of
cores (i.e. 11 uninterruptable processes vs 4 CPU threads). So an idle
system can have a load of > 10, for instance.

At present we are working around this by setting a higher load to manage
the tests, this as you might imagine is not a perfect solution as the
number of uninterruptable processes does vary over time.

The implementation of this feature specifically mentions checking for
CPU load, which to be consistent on all platforms would require checking
slightly different details on Linux.

Is the intent for CTest to specifically manage CPU load or system load
overall? The original commit message and comments point more towards the
former. The Windows implementation of GetLoadAverage() also points
towards merely CPU load.

A Linux specific implementation would have to, most likely, investigate
/proc/stat and derive a CPU load from that.

Any ideas/suggestions?

Thanks,
W

This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
-- 

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

[Wouter Klouwen]

Hello,

just chiming in here. I work for a company that works with embedded
devices, so cross compiling is our bread and butter.

We have a super build system - in a combination of CMake and Makefile -
that first builds a certain set of projects for the host platform and
second builds for the actual target platform.
For testing purposes we can also build all projects for the host
platform to run tests.
All of the projects are compiled through ExternalProject, as it's a mix
of open source packages which can use arbitrary build systems and our
own projects, which use CMake.

Within our own projects we already have a set of functions that wrap
add_executable() and add_library() to make our lives easier and enforce
common idioms so adding some multiple toolchains there would be easy.
The open source packages would be a bit trickier as we'd have to ensure
that with the ExternalProject calls it would use the correct toolchain
given a CMake toolchain definition that would then have to apply to a
non CMake build system such as automake.

However, we don't just have one target platform, we have more than 5
combined ARM and MIPS platforms all with different gcc versions, etc,
along with the host build. Each different platform may have a different
set of projects enabled. This depends on a great number of variables,
like hardware support, etc., as well as non technical reasons.

If there was multiple toolchain support, we could squash the super build
system away which gives a bit more of an integrated system - great - but
the complexity of selecting the correct projects to build given a
certain platform would then have to be put somewhere else - not so great.

While I dislike the super build system concept, it does provide for an
abstraction of that complexity for some of these problems.

As we have adopted CMake wider and wider over the past few months, some
of the limitations have become clearer too, mainly the fact it runs on a
single thread.
We have over 400 individual projects with nearly 1000 CMakeLists.txt
files with a total of 27k lines of CMake.
I have performed some experiments to partially convert the super build
system to be purely CMake for the single stages, which was an
interesting exercise.
I found that the process from parsing the CMake files to generating the
50MB worth of build.ninja file took over 30 seconds on an i7 CPU with
SATA SSDs.
If this was further extended to include both host and target that would
result in an even slower build file generation.

The super build system concept helps us here too as by splitting the
parsing of CMakeLists.txt up with ExternalProject the overall generation
of the build.ninja file takes a "mere" ~7 seconds.

This limitation alone means that doing any of this could be really
detrimental to the iterative build cycle and would severely limit the
usability of this feature for us.

W

On 19/12/2018 05:05, Peter Mitrano wrote:
> [External email]
>
> Hey all, just thought I would chime in and note that I very often write
> code that I expect to run both on my robots hardware and on my
> development machine in a simulator. In this case, I want the same target
> names and everything -- I simply use two cmake build directories, and
> now there is even support for this workflow in CLion so my life is very
> easy. Doing all of those as two targets with distinct names would be
> cumbersome, and the current system works very well for me.
>
> On Tue, Dec 18, 2018 at 8:54 PM frodak17  > wrote:
>
>
>
> On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards
> mailto:kyle.edwa...@kitware.com>> wrote:
>
> On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
>> What about conflicting build types when building a host tool
>> target vs the cross compiler target?
>> For instance the host tool may (should?) be built as a release
>> project (default optimization levels) but the cross compiler
>> project could be built as a debug project (so you can debug it
>> with no optimizations)?
>> I guess it would then be CMAKE__BUILD_TYPE and then
>> targets using that toolchain would be built with that build type.
>
> I think that both host and cross targets would be built with the
> same build type. If you're using a multi-config generator like
> VS or Xcode, how do you specify which combination of configs you
> want? It's simpler if every target is built as the same type,
> whether it's host or cross. Think about it - the current system
> already expects that every target in the project is built as the
> same build type. There's no way to specify "foo is built as
> debug, bar is built as release." Why would this assumption
> change just because we add a multi-toolchain mechanic?
>
>
> I have thought about it which is why I asked.  The original
> assumption of one toolchain per CMake project is being extended. So
>   

[cmake-developers] Unit testing CMake modules

[Wouter Klouwen]

Hi all,

We have a rather large amount of CMake code (4k+ lines) in various
modules/functions. They contain the common logic for many of our
projects. This makes it quite an important base for everything our team
does.

Rather shamefully at present these modules are rather poorly tested. I'd
like to improve this, but the current way of testing CMake code
is typically to run a trimmed project, and to verify whether certain
invocations produce a certain output or file hierarchy.
This involves a bit of infrastructure and can be a bit cumbersome
maintain, to diagnose when tests fail, and it requires a separate run of
the tests.
The overall cumbersomeness of the setup in turn discourages in our team,
including myself, from adding tests.

I'd like a more integrated approach that makes running at least some
basic tests part of the build progress, and a more direct way of
reporting failures.

In other programming environments, testing often involves some kind of
mocking environment, and CMake helpfully allows the overriding of CMake
built in functions, though this is typically discouraged.

In my ideal world it would be possible to save the state of the current
function set up, then call a function with a certain given number of
parameters, and expect a certain sequence of events, such as functions
to be called, environment variables to be set, etc.
Something akin to CMakePushCheckState, except for built in functions.

Then a module could provide for some functions that would set up
expectations and verify them, within a run of cmake, or possibly some
other commands could be added, to give some syntactic glossy coat to it.

As it wouldn't actually trigger any of the expensive generating
functions, it would be lightweight, quick to run and give pretty direct
errors in terms of failed expectations, reducing debug time.

If it was done with CMake commands, I might imagine it to look something
like:

function(foobar)
   # function to test, does something non trivial
   if ("FOO" IN_LIST ARGV)
  install(FILES foo DESTINATION foo_dir)
   else("BAR" IN_LIST ARGV)
  message(FATAL_ERROR "Some error")
   else("BAZ" IN_LIST ARGV)
  set(BAZ True PARENT_SCOPE)
   endif()
endfunction()

test(foobar)
   expect(WITH "FOO" CALL install FILES foo DESTINATION foo_dir)
   expect(WITH "BAR" CALL message FATAL_ERROR "Some error")
   expect(WITH "BAZ" ENVIRONMENT BAZ True)
endtest(foobar)

What do people think? Is this crazy? Is there a quicker way to get
somewhere close? Should I put some effort into making this into an
actual proposal/working code?

Thanks in advance,
W


This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
-- 

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] Source file dependencies

[Wouter Klouwen]

Hi Craig,

thanks for the tip.

My use case is specifically with external projects producing files that I don't 
know about in advance, so I thought OBJECT_DEPENDS wouldn't really work. But 
then I realised that if I can extract the name of the "done" stamp, this would 
do the trick.

So I end up with an external project declaration something like this:

ExternalProject_Add(foo URL foo.tgz
BUILD_COMMAND make -C  all
INSTALL_COMMAND make -C  install
)

_ep_get_step_stampfile(foo "done" foo_done_stamp_file)
add_library(libfoo INTERFACE IMPORTED)
add_dependencies(libfoo foo)
set_target_properties(libfoo PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_INSTALL_PREFIX}/include)

And then simply a project declaration like this:

project(bar)

set_source_files_properties(bar.c OBJECT_DEPENDS ${foo_done_stamp_file})
add_executable(bar bar.c)
target_link_libraries(bar libfoo)

And very happily, it doesn't try to compile bar.c until the "foo" external 
project has been installed. It's unfortunate to have to use an internal 
ExternalProject function but AFAICT this is the best way without repeating 
logic to get the complete filepath of the stamp.

Thanks again,
W

From: Craig Scott [craig.sc...@crascit.com]
Sent: 07 December 2017 19:50
To: Wouter Klouwen
Cc: CMake Developers
Subject: Re: [cmake-developers] Source file dependencies

[External email]

Have a look at the documentation for the OBJECT_DEPENDS source 
property<https://cmake.org/cmake/help/latest/prop_sf/OBJECT_DEPENDS.html>, 
which explains some options that may be relevant for your question.

On Fri, Dec 8, 2017 at 5:08 AM, Wouter Klouwen 
<wouter.klou...@youview.com<mailto:wouter.klou...@youview.com>> wrote:
Hi all,

In trying to improve our build rules, one of the problems I encountered
is that I effectively have some source files that cannot be compiled
unless certain targets are run.

I noticed that cmSourceFile has the AddDepend() method, which looks to
do the kind of thing that I want to do.
cmFlTKWrapUICommand and cmCPluginAPI are the only users of this, with
there being no way of setting this from a CMakeLists.txt.
The former seems to do exactly the kind of think that I need, which is
to set up some code generation.

It would be nice if I could add items to this list, perhaps through
setting a property on the source files themselves, e.g this rather
contrived short example:

add_custom_command(OUTPUT bar.h COMMAND touch bar.h)
add_custom_target(bar DEPENDS generate_bar bar.h)
set_source_files_properties(foo.cpp PROPERTIES DEPENDS bar)

Is this a bad idea? Would there be a better way?

Thanks,
W
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

Powered by www.kitware.com<http://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



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


[External email. Treat hyperlinks and attachments with caution]

-- 

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] Source file dependencies

[Wouter Klouwen]

Hi all,

In trying to improve our build rules, one of the problems I encountered
is that I effectively have some source files that cannot be compiled
unless certain targets are run.

I noticed that cmSourceFile has the AddDepend() method, which looks to
do the kind of thing that I want to do.
cmFlTKWrapUICommand and cmCPluginAPI are the only users of this, with
there being no way of setting this from a CMakeLists.txt.
The former seems to do exactly the kind of think that I need, which is
to set up some code generation.

It would be nice if I could add items to this list, perhaps through
setting a property on the source files themselves, e.g this rather
contrived short example:

add_custom_command(OUTPUT bar.h COMMAND touch bar.h)
add_custom_target(bar DEPENDS generate_bar bar.h)
set_source_files_properties(foo.cpp PROPERTIES DEPENDS bar)

Is this a bad idea? Would there be a better way?

Thanks,
W
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
-- 

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 monotonic time in CMake & CTest

[Wouter Klouwen]

Hi all,

we've started to use CTest for our test running and it's generally
running well.

However, we sometimes get some odd timeouts in tests, and as such it has
been noticed that ctest doesn't use monotonic test timers, but instead
relies on gettimeofday().
When running on some of our devices, they start up thinking that it is
the year 2000 but during the test run, NTP kicks in, and fast forwards
the time to be 2017.

Using gettimeofday(), a test running during this NTP operation would
seem to have taken 17 years.
To avoid this, it's possible to use monotonic timers instead using
clock_gettime().

Is there any reason to not use this?

I've raised a bug* with a proposed patch.

Thanks in advance,
W


*: https://gitlab.kitware.com/cmake/cmake/issues/17345
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

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 script and many subprojects

[Wouter Klouwen]

Hi Zack,

On 04/09/17 15:13, Zack Galbreath wrote:

On Mon, Sep 4, 2017 at 7:50 AM, Wouter Klouwen
<wouter.klou...@youview.com <mailto:wouter.klou...@youview.com>> wrote:
I think if I want it to work in the most optimal way where ctest can
schedule all tests in the mega project for all sub projects in
accordance with its load balancing, the SubProject attribute would have
to become a property of the test, instead of being a global property.

We've developed a feature that essentially does just this.  It's already
implemented in CMake & CDash master, and will be included in the
upcoming releases of CMake and CTest. Here's some documentation
<https://cmake.org/cmake/help/git-master/release/dev/labels_for_subprojects.html>.


We already label our tests with the "sub"project name, so it seems this
is perfect for our workflow.

I'll look forward to the next release.

Thanks!
W
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

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 script and many subprojects

[Wouter Klouwen]

Hi David,

thanks for your view.

I think if I want it to work in the most optimal way where ctest can
schedule all tests in the mega project for all sub projects in
accordance with its load balancing, the SubProject attribute would have
to become a property of the test, instead of being a global property.

In turn this would probably have to require a tweak in CDash's ingestion.

Would you agree with that?

For the time being I'll probably have to resort to using some scripts
that will create a CTest script per subproject, and execute those in turn.

Thanks,
W

On 01/09/17 20:39, David Cole wrote:

[External email]


I think your analysis is correct.

You could try doing a ctest_submit after each ctest_test call. Not
sure if you could get "correct" results with that technique. I run
some scripts that do something similar without subproject involved,
and it mostly works, but messes up the +/- tests passed and failed
since last submission data on the instance of CDash I'm using.

If you would like it to work differently than it presently does, it
would probably involve some changes to ctest. Making it do what you
want it to do and becoming a contributor is probably the quickest way
to achieve that.


HTH,
David C.



On Fri, Sep 1, 2017 at 2:36 PM, Wouter Klouwen
<wouter.klou...@youview.com> wrote:

Hi all,

I've been having some success with CTest and am interested in using
CDash as well.

In order to generate some nice output, sub projects seem to be the best
way of presenting the data in CDash for our setup. This setup is perhaps
summed up by having one projects that contains a few hundred projects.
Most of these "sub projects" are normal CMake projects.

Now, in the normal build, we have a `check` target. This is powered by
having tests added with add_test() and this check target invokes CTest
with a script that contains the setting of the SubProject property.

This produces the expected Test.xml with the SubProject tag. When
submitting these to CDash, it produces the right subproject view and the
expected aggregate view.

The next step is that we have code on devices for which we cross compile
and we want to use the same mechanism here in order to execute tests
when installed on our target devices.

Before I started the CDash work, I was able to generate CTest files
which contain the add_test() and set_tests_properties() in order to run
the tests on the devices. This was then invoked with the
DartConfiguration.tcl and ctest -T Test

Perhaps not ideal as it involves generated many CTestTestfile.cmakes,
but this was able to execute the several hundreds of tests with the
appropriate load balancing and produce one giant Test.xml.

In order to switch to generate Test.xml files with SubProject tags this
mechanism needs to be switched to using a CTest script.

As SubProject is a global property, I assume this needs to be unique for
each invocation of ctest_test().
Unfortunately putting multiple ctest_test() calls in one CTest script
seems to result in one Test.xml, which is the last project run. The test
of the output is overwritten.

It seems the only way I can make this work is by having a script which
effectively creates a new CTest script for each subproject, and moves
the produced Test.xml out of the way for the next run.
Is this right?

I hope this all makes sense.

Thanks in advance,
 W
This transmission contains information that may be confidential and contain
personal views which are not necessarily those of YouView TV Ltd. YouView TV
Ltd (Co No:7308805) is a limited liability company registered in England and
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower
Thames Street, London, EC3R 6YT. For details see our web site at
http://www.youview.com
--

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



[External email. Treat hyperlinks and attachments with caution]


This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

Powered by www.kitware.com

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

[cmake-developers] CTest script and many subprojects

[Wouter Klouwen]

Hi all,

I've been having some success with CTest and am interested in using
CDash as well.

In order to generate some nice output, sub projects seem to be the best
way of presenting the data in CDash for our setup. This setup is perhaps
summed up by having one projects that contains a few hundred projects.
Most of these "sub projects" are normal CMake projects.

Now, in the normal build, we have a `check` target. This is powered by
having tests added with add_test() and this check target invokes CTest
with a script that contains the setting of the SubProject property.

This produces the expected Test.xml with the SubProject tag. When
submitting these to CDash, it produces the right subproject view and the
expected aggregate view.

The next step is that we have code on devices for which we cross compile
and we want to use the same mechanism here in order to execute tests
when installed on our target devices.

Before I started the CDash work, I was able to generate CTest files
which contain the add_test() and set_tests_properties() in order to run
the tests on the devices. This was then invoked with the
DartConfiguration.tcl and ctest -T Test

Perhaps not ideal as it involves generated many CTestTestfile.cmakes,
but this was able to execute the several hundreds of tests with the
appropriate load balancing and produce one giant Test.xml.

In order to switch to generate Test.xml files with SubProject tags this
mechanism needs to be switched to using a CTest script.

As SubProject is a global property, I assume this needs to be unique for
each invocation of ctest_test().
Unfortunately putting multiple ctest_test() calls in one CTest script
seems to result in one Test.xml, which is the last project run. The test
of the output is overwritten.

It seems the only way I can make this work is by having a script which
effectively creates a new CTest script for each subproject, and moves
the produced Test.xml out of the way for the next run.
Is this right?

I hope this all makes sense.

Thanks in advance,
W
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

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] External projects & library dependencies

[Wouter Klouwen]

Hi Brad,

thanks for taking the time to reply.

On 11/04/17 18:00, Brad King wrote:

On 04/11/2017 12:33 PM, Wouter Klouwen wrote:

So in order to create a mega project I want to put all of the third
party packages into the build system using ExternalProject_Add.
This function does provide for targets in terms of build dependencies,
but this isn't quite enough. I need these packages to convey information
in the same way as was done through pkg-config files and provide
COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.

All of this information is present once the ExternalProject is built as
it would be possible to invoke pkg-config afterwards. This is of course
too late for CMake to resolve this information at configure/build rule
creation time.

Is there a better way of solving this other than effectively duplicating
the information in the pkg-config files so that CMake can read it at
generation time?


Make your outer project a "superbuild" that does not compile anything
itself but instead just uses ExternalProject_Add to build everything
else in dependency order.  That way each project won't configure until
all its dependencies are built.


Unfortunately this isn't really an option for us. There's a non trivial
amount of third party packages that take a non trivial amount of time to
compile.
Waiting for all of these to compile while not yet starting on our own
projects would create a very long critical path before the build could
fan out for all targets. This would have a detrimental impact on our
build performance.

I appreciate it's not a usual problem as this is for an embedded
platform where we have to cross build everything from scratch.

Thanks,
W


This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

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] External projects & library dependencies

[Wouter Klouwen]

Hello all,

I've been converting a large build system to use CMake. At the moment it
consists of a custom build system that builds 250+ projects plus a
series of third party open source packages, that each have their own
build system. After some effort I've been able to convert all of our own
projects to use CMake.

This brings us to the next challenge as I'm now in the position where I
want to create one CMake, so that it can take over from our own build
system.
There's a major thing I can't find a good solution for yet. At the
moment each project is built individually and in order. As there's
multiple levels of build systems involved. So include and link flags
between these projects can be transferred through either CMake packages
or FindPkgConfig, for our own CMake projects and the third party
packages respectively. Both of these methods provide for interface
libraries that can be neatly depended on.

So in order to create a mega project I want to put all of the third
party packages into the build system using ExternalProject_Add.
This function does provide for targets in terms of build dependencies,
but this isn't quite enough. I need these packages to convey information
in the same way as was done through pkg-config files and provide
COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.

All of this information is present once the ExternalProject is built as
it would be possible to invoke pkg-config afterwards. This is of course
too late for CMake to resolve this information at configure/build rule
creation time.

Is there a better way of solving this other than effectively duplicating
the information in the pkg-config files so that CMake can read it at
generation time?

Thanks in advance,
 W
This transmission contains information that may be confidential and contain 
personal views which are not necessarily those of YouView TV Ltd. YouView TV 
Ltd (Co No:7308805) is a limited liability company registered in England and 
Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames 
Street, London, EC3R 6YT. For details see our web site at http://www.youview.com
--

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