Brad King wrote:
On 12/19/2012 09:49 AM, Stephen Kelly wrote:
The problem is that in this code:
include_directories(foo/bar)
add_library(the_lib ...)
the INCLUDE_DIRECTORIES target property is seeded by the directory
property of the same name. The backtrace then leads to the
On 12/20/2012 06:59 AM, Stephen Kelly wrote:
Ok, I've force-pushed the include-dirs-debugging branch to my clone. Let me
know if I can merge that to next.
Yes, it looks good, thanks.
Please also add documentation for the CMAKE_DEBUG_TARGET_PROPERTIES
variable. State in the docs that it works
On 12/19/2012 07:31 AM, Stephen Kelly wrote:
I think this idea gets complex quickly.
Yes, we're bikeshedding it.
The cmPropertyMap would need to hold cmProperty* and new them. cmPropertyMap
and cmProperties are currently copied but that would have to be made
impossible as it introduces
Brad King wrote:
Okay. Since this is purely internal it can be factored into a generalized
approach later.
Great. I mentioned this before:
Note that the branch is work in progress. Currently the backtrace is not
always initialized correctly when include_directories() is used. What do
On 12/19/2012 09:49 AM, Stephen Kelly wrote:
The problem is that in this code:
include_directories(foo/bar)
add_library(the_lib ...)
the INCLUDE_DIRECTORIES target property is seeded by the directory property
of the same name. The backtrace then leads to the add_library invokation
Stephen Kelly wrote:
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.
https://gitorious.org/~steveire/cmake/steveires-
On 12/18/2012 10:29 AM, Stephen Kelly wrote:
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
Brad King wrote:
On 12/18/2012 10:29 AM, Stephen Kelly wrote:
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?
Providing backtraces for debugging would be helpful for
On 12/18/2012 11:02 AM, Stephen Kelly wrote:
I didn't look into the implementation of it yet. By 'intern', you mean
storing const char * instead of std::string with the cmListFileBacktrace
object, and maintaining the strings elsewhere (globally?)?
Yes, something along these lines.
Yes. Do
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
...
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
Brad King wrote:
On 12/18/2012 11:02 AM, Stephen Kelly wrote:
Yes. Do you have any idea of what you'd like to see generalized? The
interception and struct for handling the INCLUDE_DIRECTORIES property
itself?
The cmPropertyMap/cmProperty infrastructure could potentially store
structures
Brad King wrote:
On 12/18/2012 11:49 AM, Stephen Kelly wrote:
Brad King wrote:
The cmPropertyMap/cmProperty infrastructure could potentially store
structures with the string values plus meta-data instead of just the
strings as now.
That sounds more complex to me. Would the possible
12 matches
Mail list logo
