[cmake-developers] TARGET_OBJECTS and buildsystem replacement macros

[Brad King]

On 03/20/2014 05:52 AM, Stephen Kelly wrote:
> Brad King wrote:
> 
>> If the place in those files where the values get written is per-config
>> then they can be replaced with the literal config names.  Otherwise the
>> macros must be left so that the build system can substitute the config
>> name at build time.
> 
> Exactly. I don't have the information to determine that.

Perhaps the generators that need per-config values can use $<CONFIG>.
Then in the contexts where the configuration is known during evaluation
it can be replaced with the real config.  In contexts where the
configuration is not known but the evaluation is for the build system
then the placeholder can be substituted for $<CONFIG> instead.

> If only the buildsystem tool knows the correct arch, does that mean that 
> CMake can not learn a built-in feature for installing object libraries, 
> because it is not possible to implement install() correctly for the files 
> for Xcode?

I'd rather have a builtin feature for installing object libraries than
encourage use of the install_objlib_hack approach you posted.  When
generating install rules CMake knows about the OSX_ARCHITECTURES target
property and could do something with the arch macros.  The installed
objects would have to be laid out such that an the target exports file
could adjust the list of objects for an importing project based on the
target architecture(s) enabled.

> 1) I can modify the TargetObjectsNode to replace the CfgIntDir macros with 
> the actual configuration, but that will affect the generated buildsystem 
> files too
> 2) We can leave things as they are in the branch, meaning install(FILES) 
> won't work well with $<TARGET_OBJECTS> and let users of file(GENERATE) deal 
> with the output.

Does my $<CONFIG> suggestion above resolve this?  I think it leaves
only the Xcode $(CURRENT_ARCH) problem.  Perhaps a similar $<ARCH>
genex can be used for that too.

> 3) We can make it an error to use $<TARGET_OBJECTS> in any user-context of 
> generator expressions. That will also affect the use of  
> $<TARGET_PROPERTY:SOURCES> when object libraries are involved.

This approach would allow us to delay a decision until later so let's
use it if we can't find a good solution now.

-Brad