Hi,
As part of implementing the INTERFACE_SOURCES feature, a SOURCES property is
required.
Unfortunately it already exists and does not contain all sources. It omits
TARGET_OBJECTS items. Backward compatibility must be preserved. I would want
to turn TARGET_OBJECTS into a 'real' generator expression which results in a
list of object file paths, and simply process the SOURCES like other build
properties, allowing that result.
Configure-time code can not handle generator expressions.
cmSetSourceFilesPropertiesCommand is documented as being suitable for
consuming the value of SOURCES from a target. It breaks if a generator
expression is passed in. Additionally user code can be reading the SOURCES
property (it is read-only, they can't be writing it), and would break if the
TARGET_OBJECTS expression were added.
The cmSetSourceFilesPropertiesCommand can be made to ignore generator
expressions. An alternative would be to execute the property setting after
generator expression expansion. However, that would be weird:
add_library(bar bar.cpp)
add_library(foo foo.cpp $<TARGET_PROPERTY:bar,SOURCES>)
# get_target_property(res foo SOURCES)
# message("RES: ${res}")
get_target_property(foo_srcs foo SOURCES)
# Sets bar.cpp property at generate-time:
set_source_files_properties(${foo_srcs} PROPERTIES LABELS fooSRCS)
get_target_property(bar_srcs bar SOURCES)
# Sets bar.cpp property at configure-time:
set_source_files_properties(${bar_srcs} PROPERTIES LABELS barSRCS)
The 'direct' setting of the property is always overridden by the setting on
foo, because that is evaluated lazily.
User code must also be able to ignore generator expressions. For that, we
can add a subcommand string(GENEX_STRIP). An alternative is adding
string(GENEX_SPLIT) and string(FIND_GENEX) instead. Eg:
'foo;bar;$<1:bing;bang;bat>;baz'
splits to
'foo' 'bar' '$<1:bing;bang;bat>' 'baz'
and FIND_GENEX can be used to determine whether to skip an element when
processing.
A policy would be needed to add TARGET_OBJECTS to the SOURCES property.
Other generator expressions could only appear with changes to user code or
dependencies. As I think this is quite a significant policy, I'd prefer to
get it into 3.0 so it can be removed in 4.0 rather than added n 3.1 and
removed in 5.0. The chosen string() subcommands would also need to be added
in 3.0 in order to provide a non-deprecated way of stripping the genexes
from SOURCES.
prop_tgt/SOURCES
command/target_sources
An alternative plan would be to deprecate the SOURCES property and introduce
a new property which contains the generator expressions:
prop_tgt/COMPILE_SOURCES
command/target_compile_sources
That name is not great, because the sources may be object files which do not
get compiled but only linked.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
