Alexander Neundorf wrote:
With the return() in the FooTargets.cmake file, this included file will
simply do nothing, and we'll stay with the old imported targets and
their properties.
But the FooConfig.cmake file which has just been executed may set a bunch
of variables, which would fit to
Hi,
Brad King wrote:
I'll defer my thoughts on details of defining and exporting each
part of the interface for a future message after we've discussed
the overall approach.
I think it would be more helpful to understanding your proposal if you
detail those now instead.
So far I don't
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
Brad King wrote:
On 12/18/2012 10:38 AM, Stephen Kelly wrote:
Brad King wrote:
I'll defer my thoughts on details of defining and exporting each
part of the interface for a future message after we've discussed
the overall approach.
I think it would be more helpful to understanding your
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 12/18/2012 11:09 AM, Stephen Kelly wrote:
At generate time that property
will be used to accumulate values from INTERFACE_-like properties on
the named interfaces and append them to LINK_LIBRARIES, etc.
You wrote before that you don't propose using properties and generator
expressions:
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
This would have the same effect, but people could simply hide the
USE_INTERFACES keyword in a variable:
set(Foo_LIBRARIES USE_INTERFACES Foo::FooLib)
and then it's again hidden:
target_link_libraries(hello
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
Alexander Neundorf wrote:
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
This would have the same effect, but people could simply hide the
USE_INTERFACES keyword in a variable:
set(Foo_LIBRARIES USE_INTERFACES Foo::FooLib)
and then it's again hidden:
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:
This can all be done inside C++ structures rather than with
properties and generator expressions because it is only done during
generation.
That is the kind of thing I'm confused about. I don't see what value the
USE_INTERFACES property adds.
1. It puts the transitivity
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
With the return() in the FooTargets.cmake file, this included file will
simply do nothing, and we'll stay with the old imported targets and
their properties.
But the FooConfig.cmake file which has just been
Alexander Neundorf wrote:
On Tuesday 18 December 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
With the return() in the FooTargets.cmake file, this included file will
simply do nothing, and we'll stay with the old imported targets and
their properties.
But the FooConfig.cmake
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
Sorry if I add to the confusion, but shouldn't set cmake_minimum_required
automatically set all policies newer than the specified version to old?
Johannes
On Monday, 17. December 2012, 17:57:18, Alexander Neundorf wrote:
On Monday 17 December 2012, David Cole wrote:
I thought we wanted
The question in this thread is about what previous versions of CMake do
with cmake_policy(SET ... OLD) commands where they do not know about the
policy
By default, policies introduced after the minimum required are UNSET, not
set to OLD.
From
On Mon, Dec 17, 2012 at 11:57 AM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Monday 17 December 2012, David Cole wrote:
I thought we wanted them to switch to the new behavior... Isn't that the
goal of emitting warnings from policy implementations...?
...but not as long as the
On 12-12-17 03:11 PM, Matthew Woehlke wrote:
On 2012-12-17 14:55, Ilia Choly wrote:
I'm trying to get the `FindPostgreSQL` module to find
`/usr/include/postgresql/libpq-fe.h`.
This is the error I get:
CMake Error at
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97
On Monday 17 December 2012 20:04:48 Sergey Prokhorenko wrote:
Hello.
I want to run a custom command that parses a whole source tree, so I
can't list dependencies to add_custom_command/target. Is there another
way? Just always run a program, that's all.
add_custom_target doc says:
The target
On Monday 17 December 2012 19:45:53 Derek Cole wrote:
I am trying to figure out what I am doing wrong when trying to use just flex
in a Cmake file to build a shared lib.
i basically have the following
find_package(FLEX)
FLEX_TARGET(Test ../src/test.l ../src/test.c)
set(SRC_FILES
Is there no solution to this based on my assumptions?
On Mon, Dec 10, 2012 at 11:07 AM, Robert Dailey
rcdailey.li...@gmail.com wrote:
Thanks for the tips...
I think this might be a little overkill, because the solution I was
looking at involved the DEBUG_CONFIGURATIONS variable. For
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 12e10272b205bac03c52b93718762bcc178d4386 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f20a0e6de9258518c7dada2251fe70a5258f7950 (commit)
via
25 matches
Mail list logo
