# Projects/Subprojects in cdash

**URL:** https://discourse.cmake.org/t/projects-subprojects-in-cdash/222
**Category:** Usage
**Created:** [November 18, 2019, 2:09pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222 "2019-11-18T14:09:04Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![David\_Dixon](https://discourse.cmake.org/user_avatar/discourse.cmake.org/david_dixon/32/127_2.png) [@David\_Dixon](https://discourse.cmake.org/u/David_Dixon)
#### Post date: [November 18, 2019, 2:09pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/1 "2019-11-18T14:09:04Z")

</div>

I work on a project (call it `super`) that has several subprojects (call them `sub1` and `sub2`) and I have a few issues (I tried to bold the the issues). Also, I had to remove several images because I am a new user…

In CDash, I went through the process of adding the project `super`:

### had to remove image (i’m a new user…)

and then attaching `sub1` and `sub2`.

**The first issue is as follows** - when I click on the link for the super project it takes me to the following page:

### had to remove image (i’m a new user…)

The above page collects build jobs for all sub projects which is ok but too much detail. **What I would rather see is the following:**

 ![desired](https://discourse.cmake.org/uploads/default/original/1X/c87bb5ca07ec3543f94abb5e59221ac52633531a.png)

Note that in the above webpage I can navigate to either the super project or the subprojects. The only way I can get to this page is by click on the drop down item `SubProjects` as shown below:

### had to remove image (i’m a new user…)

Furthermore, **when I click on the subprojects the header contains the name of the super project rather than the subproject** which can be confusing.

Beyond the navigation issue described above, **I also have a problem with coverage submissions under this project/subproject model.** That is, the coverage reports are not published under the dashboard for the subproject rather they wind up on the project page. Continuous, Nightly, Experimental build jobs all go to the subproject (and super project) as one would expect.

I am currently on version 2.6.0. The behavior that I am after we have in a previous version of cdash (i.e. 2.0.2), but it seems to have gone away in more recent versions.

Thoughts? Thanks!

---

<div class="post-metadata">

### Author: ![zackgalbreath](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zackgalbreath/32/94_2.png) [@zackgalbreath](https://discourse.cmake.org/u/zackgalbreath)
#### Post date: [November 18, 2019, 6:53pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/2 "2019-11-18T18:53:47Z")

</div>

> [@David\_Dixon](#):
>
> The above page collects build jobs for all sub projects which is ok but too much detail. **What I would rather see is the following:**
> 
> ![desired](https://discourse.cmake.org/uploads/default/original/1X/c87bb5ca07ec3543f94abb5e59221ac52633531a.png)
> 
> Note that in the above webpage I can navigate to either the super project or the subprojects. The only way I can get to this page is by click on the drop down item `SubProjects`

The default view in CDash (`index.php`) shows a list of builds for a given testing day. I’m glad you like the subproject-by-subproject view. It’s been on our backlog to allow users to customize their default landing page, but we haven’t gotten around to implementing this feature yet.

> [@David\_Dixon](#):
>
> Furthermore, **when I click on the subprojects the header contains the name of the super project rather than the subproject** which can be confusing.

Good suggestion. We’ll look into adding the SubProject name to the navigation header.

> [@David\_Dixon](#):
>
> Beyond the navigation issue described above, **I also have a problem with coverage submissions under this project/subproject model.** That is, the coverage reports are not published under the dashboard for the subproject rather they wind up on the project page. Continuous, Nightly, Experimental build jobs all go to the subproject (and super project) as one would expect.

We definitely support splitting coverage results up by SubProject. Is the CDash instance you’re submitting to publicly visible? If so I’ll take a closer look to see if I can figure out what’s going wrong.

---

<div class="post-metadata">

### Author: ![David\_Dixon](https://discourse.cmake.org/user_avatar/discourse.cmake.org/david_dixon/32/127_2.png) [@David\_Dixon](https://discourse.cmake.org/u/David_Dixon)
#### Post date: [November 20, 2019, 1:44pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/3 "2019-11-20T13:44:43Z")

</div>

Unfortunately, it is not a public project. We might be able to do some debugging nonetheless. For example, I generate a CTestConfiguration.ini file that contains all of the information about the project. Some of the relevant variables that I set I just learned are considered legacy:

- `DropLocation`
- `DropMethod`
- `DropSite`

I see that I should instead use 'SubmitURL`.

I also use:

- `LabelsForSubprojects`

The variables listed above are he only ones I see that might impact the submission step. Below I capture the relevant CI steps invoked:

```bash
ctest -M Experimental -T Start -- --track Experimental
ctest -M Experimental -T Configure -- --track Experimental
ctest -M Experimental -T Build -- --track Experimental
ctest -M Experimental -T Test -- --track Experimental
ctest -M Experimental -T Coverage -- --track Experimental
ctest -M Experimental -T Submit -- --track Experimental

```

As an aside, the redundant specification of `Experimental` is a result of using a generic CI script where the option following `--track` is a variable e.g. `${CTEST_MODE}` and the reason we do that is due to the fact that:

```auto
ctest -M Continuous -T Start
ctest -M Continuous -T Configure
ctest -M Continuous -T Build
ctest -M Continuous -T Test

```

won’t actually trigger any of the steps in the context of CI - I believe that this is due to the fact that in the context of CI/git it doesn’t look like anything changed so there is no reason configure, build, test, etc. so we use `Experimental` and then send everything to the appropriate track or in CDash speak group.

---

<div class="post-metadata">

### Author: ![zackgalbreath](https://discourse.cmake.org/user_avatar/discourse.cmake.org/zackgalbreath/32/94_2.png) [@zackgalbreath](https://discourse.cmake.org/u/zackgalbreath)
#### Post date: [November 20, 2019, 2:38pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/4 "2019-11-20T14:38:44Z")

</div>

I should be able to whip up a quick example demonstrating code coverage split up by subproject.

With CTest & CDash, there’s two separate ways to do subproject builds:

1. “one at a time”. Build/test each subproject separately.
2. “all at once”. Build your whole project at the same time and use CTest/CDash to split up the results on a subproject-by-subproject basis.

Which approach sounds more appropriate for your situation?

---

<div class="post-metadata">

### Author: ![David\_Dixon](https://discourse.cmake.org/user_avatar/discourse.cmake.org/david_dixon/32/127_2.png) [@David\_Dixon](https://discourse.cmake.org/u/David_Dixon)
#### Post date: [November 20, 2019, 7:14pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/5 "2019-11-20T19:14:24Z")

</div>

Thanks Zack - I am using the one at a time method.

---

<div class="post-metadata">

### Author: ![David\_Dixon](https://discourse.cmake.org/user_avatar/discourse.cmake.org/david_dixon/32/127_2.png) [@David\_Dixon](https://discourse.cmake.org/u/David_Dixon)
#### Post date: [November 21, 2019, 4:47pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/6 "2019-11-21T16:47:53Z")

</div>

I was out of the office this week but I am back and I discovered that using a ctest script seems to resolve the issue of the coverage jobs going to the project dashboard and NOT going to the subproject. I don’t understand why yet, but ctest scripts seem to be the solution.

@craig.scott recommended that I move to ctest scripts as opposed to explicit ctest dashboard commands for another usage issue and I am now convinced.

---

<div class="post-metadata">

### Author: ![David\_Dixon](https://discourse.cmake.org/user_avatar/discourse.cmake.org/david_dixon/32/127_2.png) [@David\_Dixon](https://discourse.cmake.org/u/David_Dixon)
#### Post date: [November 21, 2019, 10:21pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/7 "2019-11-21T22:21:50Z")

</div>

OK so I am perplexed. As I pointed out earlier, by moving things into a ctest script, I was able to get things reporting to the dashboard where I would expect. I borrowed an old script from another team member and ran it as is and it worked. I then started stripping things out and found that again the coverage reports were only going to the super project again!!! After applying the Sherlock Holmes method I found that the key was the following:

```auto
set_property(GLOBAL PROPERTY SubProject "${SUBPROJECT}")

```

I can’t find this property anywhere on the cmake properties documentation page…

In other words, I think the ctest script hypothesis was wrong, but I still prefer it to what I was doing before it actually cleaned up my CI.

---

<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: [February 15, 2020, 10:43pm UTC](https://discourse.cmake.org/t/projects-subprojects-in-cdash/222/8 "2020-02-15T22:43:54Z")

</div>

> [@David\_Dixon](#):
>
> I can’t find this property anywhere on the cmake properties documentation page…

I’ve filed [CMake Issue 20357](https://gitlab.kitware.com/cmake/cmake/issues/20357) for this.
