Multi-language OBJECT libraries upset Xcode when unity builds are enabled
Repro steps (on macOS 10.15):
$ cmake --version
cmake version 3.16.2
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(Test)
add_library(foo OBJECT foo.c bar.cxx)
add_executable(exe exe.c)
target_link_libraries(exe PRIVATE foo)
$ touch foo.c bar.cxx
$ echo 'int main() { return 0; }' > exe.c
$ cmake -G Xcode -DCMAKE_UNITY_BUILD=ON .
<...>
$ cmake --build .
<...>
clang: error: no such file or directory: '<...>/Test.build/Debug/foo.build/Objects-normal/x86_64/unity_0.o'
** BUILD FAILED **
It would appear that, because there is both a unity_0.c
and a unity_0.cxx
(each including only one source file - the benefit from doing that remains a mystery to me; is it a bug?), Xcode changes both of their object filenames to avoid a conflict, and neither becomes unity_0.o
.
Really, it looks like this is a fault of the Xcode generator incorrectly predicting the output filenames for OBJECT libraries containing both xyz.c
and xyz.cxx
, but I get the impression from cmLocalXCodeGenerator::ComputeObjectFilenames
that this a known caveat and there is instead a rule against adding two sources with the same base filename to the same target...
...which, if so, is a rule violated by the unity source generator always naming the first batch for a given language unity_0
even if there already exists a unity_0.*
. Would it be best to start the batch numbering where the previous left off, include the batch language in the base name of the generated source files, or resolve the name prediction issue in the Xcode generator?