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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
