[CMake] OBJECT Libraries with Xcode Generator

Matthew Keeler mkeeler at tenable.com
Wed Apr 6 17:02:16 EDT 2016


Ah, I thought cmake was controlling the output filenames of the compiler and not Xcode. Then its not really a cmake problem. Changing source names is easy enough. I was just curious. Also in the real case I could just as easily use a STATIC library instead but normally go for OBJECT libraries first. Oh well. Thanks for the info.

-- 
Matthew Keeler
On April 6, 2016 at 16:06:11, Brad King (brad.king at kitware.com) wrote:

On 04/06/2016 03:47 PM, Gregor Jasny wrote:  
> On 06/04/16 20:32, Matthew Keeler wrote:  
>> clang: error: no such file or directory:  
>> '.../lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o'  
>>  
>> Within the directory .../lib/example.build/Debug/example.build/Objects-normal/x86_64  
>> there is in fact no x.o. Instead there are two files, x-8171277E06B93FB2.o and  
>> x-FA155118579B6D7E.o. So it looks like for the XCode generators sources intermediate  
>> object files for a single CMakeLists.txt are stored within a single directory.  
>> And in this case the sources have the same name so the x-<id>.o names are used instead.  
>> However the $<TARGET_OBJECTS:…> generator expression seems to be referencing an  
>> incorrect name. Is there any workaround so that for the Xcode generator it will  
>> not store all the build artifacts in a single directory and not use the object  
>> file name with the unique id in it  

It is unlikely CMake will be able to predict the object file names  
Xcode will choose for repeated sources, so yes it would be nice to  
be able to tell Xcode to put the objects in separate directories.  
I don't know whether this is possible though.  

As a workaround you could either rename one source or add/generate  
another source with a different name that uses #include to get the  
original.  

>> and secondly where is the proper place to file a bug for this.  
> Thank you for the minimal example. Please file a bug in the bug tracker.  

https://cmake.org/Bug  

Thanks,  
-Brad  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160406/7d94243b/attachment.html>


More information about the CMake mailing list