# Aggregating Build Information across the entire configure step

**URL:** https://discourse.cmake.org/t/aggregating-build-information-across-the-entire-configure-step/3622
**Category:** Usage
**Created:** [June 24, 2021, 7:24pm UTC](https://discourse.cmake.org/t/aggregating-build-information-across-the-entire-configure-step/3622 "2021-06-24T19:24:48Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Zachary\_Turner](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachary_turner/32/1551_2.png) [@Zachary\_Turner](https://discourse.cmake.org/u/Zachary_Turner)
#### Post date: [June 24, 2021, 7:24pm UTC](https://discourse.cmake.org/t/aggregating-build-information-across-the-entire-configure-step/3622/1 "2021-06-24T19:24:48Z")

</div>

We have multiple different ways this arises, but one example is that we don’t use ctest. Instead, we have an in-house testing framework that serves a similar purpose. Our list files specify test executables via a custom function `my_add_test_executable(<NAME> <PARAM1> <PARAM2> ...)`. We then have a top-level program which needs to be able to know about every test executable, as well as the parameters that each call to `my_add_test_executable()` was invoked with.

So we need to be able to keep track of this over the life of the configure step, and then at the end, output a single manifest / configuration file that contains information about each test executable and all of the parameters the function was called with.

Is there a good pattern / recipe for this kind of thing? I’ve considered using a global property, but this is cumbersome to parse because it’s a list of lists, and cmake doesn’t make dealing with multi-dimensional lists easy.

Is there an easier way?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 24, 2021, 7:36pm UTC](https://discourse.cmake.org/t/aggregating-build-information-across-the-entire-configure-step/3622/2 "2021-06-24T19:36:45Z")

</div>

I usually do this by making ad hoc associative properties. Something like:

```cmake
set_property(GLOBAL APPEND
  PROPERTY my_test_harness_names "${test_name}")
set_property(GLOBAL
  PROPERTY "my_test_harness_${test_name}_command" "${command_args}")
set_property(GLOBAL
  PROPERTY "my_test_harness_${test_name}_workdir" "${working_directory}")

```

This avoids the “list of lists” problem at least.

---

<div class="post-metadata">

### Author: ![Zachary\_Turner](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zachary_turner/32/1551_2.png) [@Zachary\_Turner](https://discourse.cmake.org/u/Zachary_Turner)
#### Post date: [June 24, 2021, 7:44pm UTC](https://discourse.cmake.org/t/aggregating-build-information-across-the-entire-configure-step/3622/3 "2021-06-24T19:44:54Z")

</div>

How do you enumerate all of these properties though? Let’s say you have not just `my_test_harness`, but also `my_second_test_harness` and `my_fancy_test_harness`. I don’t know of a good way to enumerate all global properties in CMake, so you’d have to know in advance what all the different test harnesses were and then set properties as `set_property(GLOBAL PROPERTY "${harness_name}_${test_name}_command")` etc.

I guess you could keep a second global property which is a list of harness names. Does this sound idiomatic?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 24, 2021, 8:13pm UTC](https://discourse.cmake.org/t/aggregating-build-information-across-the-entire-configure-step/3622/4 "2021-06-24T20:13:25Z")

</div>

It sounds suitable to me. I’m not sure there’s an “idiomatic” answer to this right now (other than using part of the variable/property name to store associative data in some way).
