Add EXECUTORCH_SEPARATE_FLATCC_HOST_PROJECT cmake option (#3356)

sdk/CMakeLists.txt

@@ -69,18 +69,33 @@ include(ExternalProject)
 set(_program_schema__include_dir "${CMAKE_BINARY_DIR}/sdk/include")
 set(_bundled_schema__include_dir "${CMAKE_BINARY_DIR}/sdk/bundled_program")
 
-# Add the host project
-# lint_cmake: -readability/wonkycase
-ExternalProject_Add(
-  flatcc_project
-  PREFIX ${CMAKE_BINARY_DIR}/_host_build
-  SOURCE_DIR ${_flatcc_source_dir}
-  BINARY_DIR ${CMAKE_BINARY_DIR}/_host_build
-  CMAKE_CACHE_ARGS -DFLATCC_TEST:BOOL=OFF -DFLATCC_REFLECTION:BOOL=OFF
+# TODO(dbort): Only enable this when cross-compiling. It can cause build race
+# conditions (libflatcc.a errors) when enabled.
+option(EXECUTORCH_SEPARATE_FLATCC_HOST_PROJECT
+  "Whether to build the flatcc commandline tool as a separate project" ON)
+
+if(EXECUTORCH_SEPARATE_FLATCC_HOST_PROJECT)
+  # Add the host project. We build this separately so that we can generate
+  # headers on the host during the build, even if we're cross-compiling the
+  # flatcc runtime to a different architecture.
+
+  # lint_cmake: -readability/wonkycase
+  ExternalProject_Add(
+    flatcc_project
+    PREFIX ${CMAKE_BINARY_DIR}/_host_build
+    SOURCE_DIR ${_flatcc_source_dir}
+    BINARY_DIR ${CMAKE_BINARY_DIR}/_host_build
+    CMAKE_CACHE_ARGS
+      -DFLATCC_TEST:BOOL=OFF -DFLATCC_REFLECTION:BOOL=OFF
       # See above comment about POSITION_INDEPENDENT_CODE.
       -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON
-  INSTALL_COMMAND "" # Prevent the install step, modify as needed
-)
+    INSTALL_COMMAND "" # Prevent the install step
+  )
+  set(_etdump_schema_gen_dep flatcc_project)
+else()
+  # If we're not cross-compiling, we can just use the plain commandline target.
+  set(_etdump_schema_gen_dep flatcc_cli)
+endif()
 
 set(_etdump_schema__outputs)
 foreach(fbs_file ${_etdump_schema_names})
@@ -114,33 +129,45 @@ file(MAKE_DIRECTORY ${_program_schema__include_dir}/executorch/sdk/etdump)
 file(MAKE_DIRECTORY
      ${_program_schema__include_dir}/executorch/sdk/bundled_program)
 
-add_custom_command(
-  OUTPUT ${_etdump_schema__outputs}
-  COMMAND
-    # Note that the flatcc project actually writes its outputs into the source
-    # tree instead of under the binary directory, and there's no way to change
-    # that behavior.
-    ${_flatcc_source_dir}/bin/flatcc -cwr -o
-    ${_program_schema__include_dir}/executorch/sdk/etdump
-    ${_etdump_schema__srcs}
+if(EXECUTORCH_SEPARATE_FLATCC_HOST_PROJECT)
+  # If we cross-compiling, we need to use the version of the commandline tool
+  # built for the host.
+  set(_etdump_schema_gen_dep flatcc_project)
+
   # TODO(dbort): flatcc installs its files directly in its source directory
-  # instead of under CMAKE_BINARY_DIR, and it has no options to avoid
-  # doing this. We build flatcc twice in the executorch build: once to get
-  # the `flatcc` host commandline tool, and once to get the (potentially
+  # instead of under CMAKE_BINARY_DIR, and it has no options to avoid doing
+  # this. We build flatcc twice in the executorch build: once to get the
+  # `flatcc` host commandline tool, and once to get the (potentially
   # cross-compiled) target runtime library. The host build will put its outputs
-  # in the source tree, making the cross-compiling target build think that
-  # the outputs have already been built. It will then try to link against the
+  # in the source tree, making the cross-compiling target build think that the
+  # outputs have already been built. It will then try to link against the
   # host-architecture libraries, failing when cross-compiling. To work around
   # this, delete the host outputs after running this command (which only runs
   # when setting up the cmake files, not when actually building). This leaves
   # room for the target build to put its own files in the source tree. We should
   # try to remove this hack, ideally by submitting an upstream PR that adds an
   # option to change the installation location.
+  set(_etdump_schema_cleanup_paths ${_flatcc_source_dir}/bin/*
+                                   ${_flatcc_source_dir}/lib/*)
+else()
+  # If we're not cross-compiling we can use the plain commandline target, and we
+  # don't need to delete any files.
+  set(_etdump_schema_gen_dep flatcc_cli)
+  set(_etdump_schema_cleanup_paths "")
+endif()
+
+add_custom_command(
+  OUTPUT ${_etdump_schema__outputs}
   COMMAND
-    rm -f ${_flatcc_source_dir}/bin/*
-    ${_flatcc_source_dir}/lib/*
+    # Note that the flatcc project actually writes its outputs into the source
+    # tree instead of under the binary directory, and there's no way to change
+    # that behavior.
+    ${_flatcc_source_dir}/bin/flatcc -cwr -o
+    ${_program_schema__include_dir}/executorch/sdk/etdump
+    ${_etdump_schema__srcs}
+  COMMAND rm -f ${_etdump_schema_cleanup_paths}
   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/sdk
-  DEPENDS flatcc_project
+  DEPENDS ${_etdump_schema_gen_dep}
   COMMENT "Generating etdump headers"
   VERBATIM)
 

setup.py

@@ -430,6 +430,11 @@ def run(self):
             "-DEXECUTORCH_ENABLE_LOGGING=ON",
             "-DEXECUTORCH_LOG_LEVEL=Info",
             "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.15",
+            # The separate host project is only required when cross-compiling,
+            # and it can cause build race conditions (libflatcc.a errors) when
+            # enabled. TODO(dbort): Remove this override once this option is
+            # managed by cmake itself.
+            "-DEXECUTORCH_SEPARATE_FLATCC_HOST_PROJECT=OFF",
         ]
 
         build_args = [f"-j{self.parallel}"]