On 01/24/2013 03:39 PM, David Cole wrote:
> It's not only that target_link_libraries would be doing more
> than linking, it's also that you want to change the behavior of
> something that has existed for 12+ years without this behavior.
>
> If you do re-use target_link_libraries for your glorious "one
> command to rule them all," just be aware that you are
> invalidating 12+ years worth of everything ever written about
> it on the web, and the collective experience of thousands of
> CMake users around the world.
>
> *That* is my objection to re-purposing the name
> target_link_libraries, not that you'd be doing more than
> linking. I don't think it's worth the confusion that might come
> after this.
>
> I would not object at all to any *new* command with an entirely
> new name, such that it may be written about anew, with great
> excitement, now that the one true command is about to be born.
David's wording helped me think about this more from both a
historical and future perspective, and to my surprise actually
come to the opposite conclusion.
I've longed for "usage requirements" for years and always pictured
them propagating through linking. The huge threads of discussion
earlier made usage requirements seem more complicated than they are
and made it feel like we should hide it all behind new interfaces.
Now I think a new command will actually be *more* confusing in the
long run because the two will be different only in subtle ways and
users will wonder which one to use.
The "written about anew, with great excitement" feature is actually
the usage requirements. Since no projects set them yet there is no
change in behavior by adding the feature to tll. Now we can tell
library authors that they can simplify the usage interface for their
dependents.
Alex originally raised his concerns with an example of the old and
new styles, arguing that users should be able to choose between them.
The old style uses variables and several calls:
find_package(Foo)
include_directories(${Foo_INCLUDE_DIRS})
add_definitions(${Foo_DEFINITIONS}) # needed for Foo?
link_directories(${Foo_LIBRARY_DIRS}) # needed for Foo?
target_link_libraries(mytgt ${Foo_LIBRARIES}) # need all Foo libs?
# (more for conditional libraries or special compile flags)
but for every package one must read the documentation to know which
pieces are needed. The new style uses usage requirements:
find_package(Foo)
target_link_libraries(mytgt Foo::SpecificLibINeed)
It might look nicer to have a different name for the command in the
new-style usage, but that's about it. The complication of my
earlier proposals for how the new command would work was due to
trying to mix the two notions of transitive behavior of the two
commands. As Steve has said it is much easier to have only one
command to define such relationships among targets.
I'm almost ready to accept the proposed behavior for
target_link_libraries. However, we still need to construct a
recommended way for packages and their dependents to handle the
transition. There are many, many instances of the old style usage
since it is the only one that previously worked.
How can a package author allow old dependents using the old style to
keep working while also allowing new dependents using the new style
to work? One either populates the usage requirements properties or
does not. If enabling the new features requires possible breakage
for existing dependents then no one will do it. Steve?
Thanks,
-Brad
--
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
