[cmake-developers] TARGET_OBJECTS and buildsystem replacement macros

Stephen Kelly steveire at gmail.com
Wed Mar 19 13:41:25 EDT 2014


Brad King wrote:

> On 03/19/2014 12:31 PM, Stephen Kelly wrote:
>> However, the contents of the resulting list of objects contains paths
>> which contain replacement macros '$(Configuration)' etc for the
>> buildsystem tool.
> 
> At least for the configuration, it is known when evaluating the genex.
> Whatever is adding the placeholders can be taught to put the real
> configuration in there, no?

The placeholders are added to cmGeneratorTarget::ObjectLibrary and used from 
there. ExpandCFGIntDir could be used to replace them. 

However, should the macro remain when generating the buildsystem files? In 
my topic, $<TARGET_OBJECTS:foo> is evaluated by one piece of code, so if the 
placeholder is replaced by file(GENERATE), it will be replaced when 
generating the buildsystem files too. I can go ahead and make that change if 
it's fine.


>> However, I think that is not possible with Xcode. There seem to be other
>> macros there and I guess the full path is not known at cmake-time at all.
> 
> IIRC for Xcode there is $(CURRENT_ARCH) in the path to the object files.

Correct. There is also a PROJECT_NAME placeholder:

$ cat objlib_files 
.*/cmake/Tests/GeneratorExpression/build/$(PROJECT_NAME).build/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/objlib.build/Objects-
normal/$(CURRENT_ARCH)/objlib1.o

I guess I could replace that with CMAKE_PROJECT_NAME.

> This is necessary for universal binary builds because the architecture
> is substituted at build time by Xcode.  This is not a problem in the
> Makefile and Ninja generators because those handle universal binaries
> by putting all architectures in one object file (multiple -arch flags
> to one compiler invocation).

This seems to be the remaining unknowable, right? Can the arch be treated as 
a dimension like the config? I'm not sure that's a reasonable amount of 
work, but I'm just trying to figure out if it's solvable at all.

Thanks,

Steve.





More information about the cmake-developers mailing list