No, the CONFIGURE_COMMAND, BUILD_COMMAND, etc. are explicitly documented as not supported by FetchContent. It discards any such options and forces them to be empty strings. An explicit goal of FetchContent is to avoid building at configure time. You’re incorrectly expecting FetchContent to have all the capabilities of ExternalProject, but they have different goals and are aimed at different use cases. FetchContent can only add CMake-based projects directly to the main project. If you use it with a non-CMake dependency, all FetchContent can do for you in that case is download the sources, but not add it to your main project’s build, which is what you’ve observed. A non-CMake dependency can really only be added using ExternalProject.
Based on your scenario, it sounds like your internal Docker environment builds are fine, but builds by people outside your company are where you’re hitting problems. For those, I’d advise don’t try to do too much and leave those users to decide which approach for providing the dependencies works best for them. Just have the find_package() calls in your project. Let the end user decide how those should be satisfied. They might choose to use a package manager, or they might pre-build them and make them available by modifying CMAKE_PREFIX_PATH. Or they might implement their own wrapper to build them with scripts. Or… whatever other esoteric approach works for them. For dependencies that do build with CMake, there’s nothing wrong with your project calling FetchContent_Declare() with the FIND_PACKAGE_ARGS keyword and calling FetchContent_MakeAvailable(). That still leaves all options open for your non-internal users to provide the dependency using their preferred method. For the non-CMake dependencies though, I don’t think FetchContent is what you should be using in this situation.