Alexander Neundorf wrote:
The point is that you get targets from one installed Config.cmake file,
and other information from a different installed Config.cmake file, due to
different required version or search paths.
Should we guard the whole Config.cmake file ?
A Config file author
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
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
On Friday 30 November 2012, Stephen Kelly wrote:
Brad King wrote:
On 11/29/2012 02:22 PM, David Cole wrote:
But with the multiple OR technique, if there is a single target name
clash, NONE of the targets will be included properly
Good catch. I read it as AND, which it should be:
Brad King wrote:
On 11/29/2012 02:22 PM, David Cole wrote:
But with the multiple OR technique, if there is a single target name
clash, NONE of the targets will be included properly
Good catch. I read it as AND, which it should be:
if(TARGET a AND TARGET b AND ...)
return()
Hi there,
This subject came up before and I would like to revisit it:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2147/focus=2151
The problem is that authors of Config files are currently required to guard
their include(MyPackageTargets.cmake) line manually.
This is
On 11/29/2012 12:29 PM, Stephen Kelly wrote:
Really I think the most practical solution is to generate 'if (NOT TARGET)'
Defining the targets is not the only thing that a targets file does.
It also sets all the properties. How will you guard those? They
do not always appear next to the
Brad King wrote:
On 11/29/2012 12:29 PM, Stephen Kelly wrote:
Really I think the most practical solution is to generate 'if (NOT
TARGET)'
Defining the targets is not the only thing that a targets file does.
It also sets all the properties. How will you guard those? They
do not always
On 11/29/2012 01:44 PM, Stephen Kelly wrote:
1) and 2) imply for me that we can wrap the entire snippet I pasted above in
if (NOT TARGET grantlee_core).
Okay with me. You could also do
if(NOT TARGET a AND NOT TARGET b AND ...)
for all of the targets. Then there would be almost no chance
Brad King wrote:
On 11/29/2012 01:44 PM, Stephen Kelly wrote:
1) and 2) imply for me that we can wrap the entire snippet I pasted above
in if (NOT TARGET grantlee_core).
Okay with me. You could also do
if(NOT TARGET a AND NOT TARGET b AND ...)
for all of the targets. Then there
On 11/29/2012 02:12 PM, Stephen Kelly wrote:
Rather than reindenting everything, can I do this instead?
if(TARGET a OR TARGET b OR ...)
return()
endif()
Yes. That will be much cleaner too. Please also generate a
comment that explains the motivation.
Thanks,
-Brad
--
Powered by
But with the multiple OR technique, if there is a single target name
clash, NONE of the targets will be included properly, and quite likely,
very mysteriously...
I don't know about the rest of you, but I hate mysterious (and silent)
errors.
On Thu, Nov 29, 2012 at 2:18 PM, Brad King
On 11/29/2012 02:22 PM, David Cole wrote:
But with the multiple OR technique, if there is a single target name clash,
NONE of the targets will be included properly
Good catch. I read it as AND, which it should be:
if(TARGET a AND TARGET b AND ...)
return()
endif()
-Brad
--
Powered
14 matches
Mail list logo
