_BINARY_DIR` to point inside its own build area. Developers are strongly encouraged to use this mechanism rather than editing the sources populated in the default location, as changes to sources in the default location can be lost when content population details are changed by the project.
And [CPM.cmake local-package-override](https://github.com/cpm-cmake/CPM.cmake/tree/v0.38.7?tab=readme-ov-file#local-package-override)
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [March 2, 2024, 10:43pm UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/7 "2024-03-02T22:43:45Z")
Use ninja at build dir and it works:
```bash
Claus-iMac:build clausklein$ ninja -C A help
ninja: Entering directory 'A'
[1/1] All primary targets available:
edit_cache: phony
rebuild_cache: phony
all: phony
build.ninja: RERUN_CMAKE
clean: CLEAN
help: HELP
Claus-iMac:build clausklein$ ninja -C B help
ninja: Entering directory 'B'
[1/1] All primary targets available:
edit_cache: phony
rebuild_cache: phony
all: phony
build.ninja: RERUN_CMAKE
clean: CLEAN
help: HELP
Claus-iMac:build clausklein$
```
---
### Author:  [@Chardrazle](https://discourse.cmake.org/u/Chardrazle)
#### Post date: [March 3, 2024, 9:35am UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/8 "2024-03-03T09:35:16Z")
The _ExternalProject\_Add_ directive is clearly intended to support cmake projects, after all, that’s what it looks for by default.
However, it’s looking like trying to manage this pattern doesn’t fit, and it’s simply easier to use a script to build the sub-projects independently.
The _FetchContent_ approach appears to always (ultimately) use ‘add\_subdirectory’. This isn’t suitable because the sub-projects (in this case) have to be treated as very independent builds, so they do not want pollution of settings from each other.
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [March 3, 2024, 12:19pm UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/9 "2024-03-03T12:19:15Z")
> [@Chardrazle](#):
>
> However, it’s looking like trying to manage this pattern doesn’t fit, and it’s simply easier to use a script to build the sub-projects independently.
Yes, I agree.
---
### Author:  [@Chardrazle](https://discourse.cmake.org/u/Chardrazle)
#### Post date: [March 3, 2024, 7:37pm UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/10 "2024-03-03T19:37:41Z")
I figured out a way of achieving what I need. It’s all there in the docs for `ExternalProject`, under the _Explicit Step Management_.
The problem I had essentially boils down to the top-level project not configuring the sub-projects. This means the desired targets of the sub-projects cannot be built because the cmake configuration is not available for them.
This is where the _step targets_ come in. The configurations for those sub-projects can be forced to run by “exposing” the _configure_ step. This is simply just a case of adding `STEP_TARGETS configure` to the `ExternalProject_Add` options.
This is then used to force configuration of the sub-project. It means several calls to cmake are required, but it avoids specific shell/platform/generator directives.
So a sequence would be:
```auto
cmake ../Superbuild # Configure top-level project
cmake --build . --target A-configure # Force configuration of A by executing the "step" target exposed for sub-project A
cmake --build A --target A_exe2 # Now build a specific target of sub-project A
```
---
### Author:  [@Chardrazle](https://discourse.cmake.org/u/Chardrazle)
#### Post date: [March 10, 2024, 12:11am UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/11 "2024-03-10T00:11:11Z")
> [@Chardrazle](#):
>
> Perhaps there is a way of forcing the sub-project configuration without the build?
Looks like this can be achieved by an explicit _execute\_process_ following the _ExternalProject\_Add_ (removing the need for the STEP target); e.g.:
```auto
execute_process(COMMAND
${CMAKE_COMMAND} -S ${CMAKE_SOURCE_DIR}/A -B ${CMAKE_BINARY_DIR}/A
)
```
I’m surprised there isn’t an option on _ExternalProject\_Add_ for forcing just that. Unless I missed it?
( @craig.scott any opinion? 😉)
---
### Author:  [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [March 10, 2024, 6:12am UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/12 "2024-03-10T06:12:51Z")
> [@Chardrazle](#):
>
> So a sequence would be:
>
> ```auto
> cmake ../Superbuild # Configure top-level project
> cmake --build . --target A-configure # Force configuration of A by executing the "step" target exposed for sub-project A
> cmake --build A --target A_exe2 # Now build a specific target of sub-project A
>
> ```
**IMHO** : it would be much clearer to write a script, on even better, a `GNUmakefile`, or not?
---
### Author:  [@Chardrazle](https://discourse.cmake.org/u/Chardrazle)
#### Post date: [March 10, 2024, 10:49am UTC](https://discourse.cmake.org/t/selection-of-targets-from-a-superbuilds-sub-projects/10243/13 "2024-03-10T10:49:28Z")
Sure, as soon as there are multiple commands to type in then a script file might become beneficial.
The aim was that the script could consist purely of calls to _cmake_. IOW: it serves as not having to remember the _cmake_ command lines, rather than being intrinsically involved in the build logic.
Adding the _execute\_process_ entry, the second call to _cmake_ in the above sequence is no longer required; i.e. only two calls to _cmake_ are required in order to build a _specific target_ of a sub-project.