The flatcc third party library builds its libraries and executables directly into its source tree (under bin/ and lib/) instead of into the cmake output directory. This causes problems for us, because we need to be able to build both host and cross-compiled target versions of flatcc. But since they both are built to the same directory, they can overwrite each other.
We have a hack at
|
# TODO(dbort): flatcc installs its files directly in its source directory |
to deal with this, but it'd be a lot easier if flatcc had a build option to install the binaries under the cmake build directory instead.
@dbort sent dvidelabs/flatcc#306 to the upstream project, but there's been no further response for months.
db31f49 is the simplification change we'll be able to make to ET. And that hack didn't work all the time anyway (e.g., #7260), so with this we should be able to permanently avoid the environment-specific build race conditions we've run into.
cc @larryliu0820 @lucylq
The
flatccthird party library builds its libraries and executables directly into its source tree (under bin/ and lib/) instead of into the cmake output directory. This causes problems for us, because we need to be able to build both host and cross-compiled target versions of flatcc. But since they both are built to the same directory, they can overwrite each other.We have a hack at
executorch/devtools/CMakeLists.txt
Line 105 in 4f12131
@dbort sent dvidelabs/flatcc#306 to the upstream project, but there's been no further response for months.
db31f49 is the simplification change we'll be able to make to ET. And that hack didn't work all the time anyway (e.g., #7260), so with this we should be able to permanently avoid the environment-specific build race conditions we've run into.
cc @larryliu0820 @lucylq