[cmake-developers] Printing the origin of include dirs (Was Setting include directories via target_link_libraries() ?)
Stephen Kelly
steveire at gmail.com
Tue Dec 18 10:29:31 EST 2012
Alexander Neundorf wrote:
> All kinds of users will notice when for whatever reason something suddenly
> doesn't build for them due to bad include dirs.
> When they then see
>
> target_link_libraries(hello ${Foo_LIBRARIES} ${Bar_LIBRARIES})
>
> there is no hint that this does more than it always did, so why should
> they even check the documentation whether tll() now also sets include dirs
> ? They will just see that their include dirs are wrong in some way, but
> figuring out that this might be caused by target properties hidden in
> ${Foo_LIBRARIES} will probably need an advanced user who knows about this
> new feature.
>
Or we can add a way to print where include directories come from. That's
something that's been on the plans since the beginning, and some of the code
and API is already in master for it.
More of the useful code for that was in my branch, but it's independent of
this whole command API question, so I've cherry-picked it out of there and
put it in the include-dirs-debugging branch of my clone.
I think it's useful on its own, so I think we should get something like it
into 2.8.11.
Note that the branch is work in progress. Currently the backtrace is not
always initialized correctly when include_directories() is used. What do
ya'll think of the idea?
> Probably it would be good if we could provide also a convenient way to
> print target properties for debugging purposes, something like
>
> cmake_print_properties(Foo::Foo_Libraries PROPERTIES INCLUDE_DIRS BLUB ...
> )
Because include dirs go through a uniqueness-filter, that doesn't help on
its own. My branch is a better solution because it tells you the backtrace
of the includes that were actually used, and where they came from.
Thanks,
Steve.
More information about the cmake-developers
mailing list