Brad King wrote:
> On 03/19/2014 01:41 PM, Stephen Kelly wrote:
>> However, should the macro remain when generating the buildsystem files?
>
> 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.
>>> This is necessary for universal binary builds because the architecture
>>> is substituted at build time by Xcode.
>>
>> This seems to be the remaining unknowable, right?
>
> Yes. When not building universal binaries we can probably hard-code
> the one architecture to be built instead of using the placeholder.
> When building universal binaries with Xcode anything that the project
> does with the value of the generator expression will have to be aware
> of multiple architectures anyway so perhaps we can just leave the
> placeholder and let them deal with it.
I was thinking of something like this:
add_library(objlib OBJECT foo.cpp)
macro(install_objlib_hack)
foreach(lib ${ARGN})
set(dest objects)
install(FILES $<TARGET_OBJECTS:${lib}> DESTINATION ${dest})
file(GENERATE OUTPUT ${lib}Target.cmake
CONTENT "
add_library(Prefix::${lib} INTERFACE IMPORTED)
set(objects \"$<TARGET_OBJECTS:${lib}>\")
foreach(obj \${objects})
get_filename_component(objname \${obj} NAME)
list(APPEND srcs \"\${IMPORT_PREFIX}/${dest}/\${objname}\")
endforeach()
set_property(TARGET Prefix::${lib} PROPERTY
INTERFACE_SOURCES \"\${srcs}\")
")
endforeach()
endmacro()
install_objlib_hack(objlib)
It would be better with $<EACH> and $<REPLACE> expressions, but we can
ignore that for now.
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?
----
The immediate question is what to do about the the target-sources-refactor
topic I've re-merged to next.
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.
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.
Thanks,
Steve.
--
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
