Stephen Kelly wrote:
> Brad King wrote:
>>>> It should be in cmTarget::ComputeLinkImplementation at this line:
>>
>> If it is not that early then we need to consider the interaction
>> of at least these pieces:
>>
>>cmTarget::GetLinkerLanguage
>>cmTarget::GetLinkClosure
>>cmTarget::ComputeLinkClosure
>>cmTarget::GetLinkImplementation
>>cmTarget::ComputeLinkImplementation
>>cmComputeLinkInformation
>>cmComputeLinkDepends
>>
>> They all deal with the link libraries and need the processed
>> output of generator expressions.
>
> Thanks for the info. There is indeed a lot to look into for the link
> libraries part of theis feature.
While investigating generator expressions for link libraries, I discovered
a problem which might make it harder to accomplish.
Any user code which invokes
get_target_property(loc tgt LOCATION)
or
get_target_property(loc tgt LOCATION_${Config})
causes
cmTarget::GetLocation(const char *config)
to be called.
That in turn causes GetLinkImplementation to be called, for which the
linker language must be determined, for which it is necessary to know the
targets linked to.
This is all at configure-time.
If the targets linked to is different at generate-time, the link-languages
might be different, and the LOCATION might even get a different value.
It seems that the generator expressions for linked targets is in conflict
with the 'linker preference' feature. Is this a resolvable situation?
The only option I see that might work is to extend the undefined behavior
documentation of the LOCATION* properties to cover use of generator
expressions with link libraries, and then try to refactor/copy the code out
of cmTarget to cmGeneratorTarget to add the generator expressions feature.
The problem that would remain even then is that the maintainer of the build-
system doesn't have full control. A dependency could use generator
expressions in its LINK_INTERFACE_LIBRARIES property, so even if the
maintainer thinks he's not writing code to hit the undefined behavior, a
dependency might. Hmm, actually that would be
IMPORTED_LINK_INTERFACE_LIBRARIES instead, so maybe adding generator
expressions to that wouldn't work at all anyway.
I wonder if it would work to introduce generator expression capable
LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES properties, which would be
consistent with INTERFACE_INCLUDE_DIRECTORIES and
INTERFACE_COMPILE_DEFINITIONS.
At generate-time their content would be used together with the information
from target_link_libraries and INTERFACE_LINK_LIBRARIES. The downside is
that it potentially makes the link language guessing at configure-time
useless. People porting to use the stuff would have to set the
LINK_LANGUAGE if they want a real LOCATION at configure-time.
That was a bit of brain-dump. This is getting messy.
I've put some work in progress for the INCLUDE_DIRECTORIES and
COMPILE_DEFINITIONS in the interface-target-properties branch of my clone.
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
