Step 3 from §4 of the documentation states that the top-level CMakeLists.txt in tudatBundle must be modified to include new Tudat applications (§4.4). This means that users writing a new application must:

1. check out a repository inside a repository (tudatBundle ← userApplication).
2. Modify another repository's file(s) to get their own code working

This is somewhat awkward. git will typically complain (a lot) about issue 1, and issue 2 comes with an implicit promise from the user to never push that file to the tudatBundle repository...As someone who knows not to trust himself with weakly-enforced constructs like this, what I would do in this situation is clone tudatBundle, followed by deleting its .git folder.

This has some obvious drawbacks.

As an outsider, I'm not sure what the road most traveled is (and I may very well be overlooking many parts of the documentation regarding this issue), but as I see it, the root cause of this situation is that tudatBundle views itself as the main project, while it should be viewing itself as a library. I.e., one would typically use algorithms inside of an application, rather than include applications that run as part of an algorithm...

Of course, I recognize that such a change of "paradigm" requires a great amount of refactoring in a great number of places, and break quite a bit of legacy code.

Instead, I propose a simple way around issue 2 above (see PR): make the CMakeLists.txt able to find all top-level CMakeLists.txt inside of tudatApplications/. That way, step 3 from §4 can simply be removed; tudatBundle now takes care of it automatically. One caveat: I've implemented this using file globbing, which is not without its drawbacks, but in this specific case, I think its use is justified.