[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