# Failures due to build order of Slicer CAT with superbuild remote modules

**URL:** <https://discourse.slicer.org/t/failures-due-to-build-order-of-slicer-cat-with-superbuild-remote-modules/21841>\
**Category:** Support\
**Created:** [February 7, 2022, 4:14pm UTC](https://discourse.slicer.org/t/failures-due-to-build-order-of-slicer-cat-with-superbuild-remote-modules/21841 "2022-02-07T16:14:23Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [February 7, 2022, 9:45pm UTC](https://discourse.slicer.org/t/failures-due-to-build-order-of-slicer-cat-with-superbuild-remote-modules/21841/5 "2022-02-07T21:45:53Z")

</div>

> [@jcfr](#):
>
> Exactly, extensions having external project dependencies that are required only when “bundled” should be specified using this pattern:
> 
> ```auto
> if(DEFINED Slicer_SOURCE_DIR)
> list(APPEND ${proj}_DEPENDS
> NameOfExternalProject1
> NameOfExternalProject2
> ...
> )
> endif()
> 
> ```

Could we put this pattern inside `ExternalProject_Include_Dependencies`? To me it looks like a bug in `ExternalProject_Include_Dependencies` that it always enforces existence of `External_ITK.cmake` even if it is not needed. I think we could solve the issues by adding a check in `ExternalProject_Include_Dependencies` that would prevent the function from looking for `External_ITK.cmake` if `ITK_FOUND` is already set, similarly how it is done here:

> <https://github.com/lassoan/SlicerSegmentMesher/blob/4315b7b5ab34a6464bbf3c53fac0e9862fa6be55/SuperBuild/External_cleaver.cmake#L5-L9>

I guess by introducing a new `SuperBuildPrerequisites.cmake` file we could do more, but things are already so complex that we should really try to avoid adding a new mechanism to make things any more powerful, nicer, and generic and instead we should striving to make this simpler, less flexible, less configurable if at all possible.

> [@jamesobutler](#):
>
> Using the /MP flag is helpful on Windows and works well with Slicer core to reduce the total build time

If we want to make the Windows build faster I would not bother with the mere 20-30% speedup that `/MP` can do, because it rarely, if ever makes a difference - build takes hours either way. However, if we can reach the 30-minute full build from scratch (as on Linux) then it would worth investing time into developing and supporting that build option. Making Windows builds significantly faster using Ninja [came up a few years ago](https://discourse.slicer.org/t/msvc-cmake-cxx-mp-flag-default-value/1786/5), and interestingly nested external project builds caused the problems with that, too. If making things more complicated is inevitable then at least we should check if we can get other benefits out of it, such as faster builds.

---

_[View the full topic](https://discourse.slicer.org/t/failures-due-to-build-order-of-slicer-cat-with-superbuild-remote-modules/21841)._