The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14284
==
Reported By:abma
Assigned To:
On 07/10/2013 08:52 AM, Stephen Kelly wrote:
The problem is revealed because I changed GetCompileDefinitions to populate
an out-vector instead of returning a string, which the VS generator used to
use directly. The use of ExpandListArguments does not handle the 'escaped'
semicolon. Should
On 07/10/2013 09:04 AM, Brad King wrote:
The new code does:
+ target.GetCompileDefinitions(targetDefines, configName);
which runs ExpandListArguments internally too. Then you re-compose
a ;-list without re-escaping the semicolons and pass it to
+
On 07/09/2013 11:30 AM, Stephen Kelly wrote:
Brad King brad.king@... writes:
On 06/07/2013 09:13 AM, Stephen Kelly wrote:
SOURCES $$CONFIG:Debug:other.cpp
That has been requested as a feature occasionally. I'm not sure
it is possible to implement on all the generators though.
I just
Hi,
I've been looking into a patch to add an include directory automatically
when a framework is used. For example:
target_link_libraries(sometarget LINK_PRIVATE ${FOO})
if ${FOO}/.. is a framework path, then add ${FOO}/.. to the
INCLUDE_DIRECTORIES of sometarget (at generate time).
This
Stephen Kelly steveire@... writes:
We could also probably add a runtime warning if enabled. You need to enable
deprecation warnings with your compiler, so it would make sense to have to
enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS
could be used to determine whether
Brad King wrote:
IIRC we have the same problem with inter-target dependencies and
we solved it by taking the union of dependencies from all configs.
Is that right?
Yes, I think that's right.
I don't think that solution can work for source files.
Perhaps for Xcode we can generate wrapper
On 07/10/2013 11:12 AM, Stephen Kelly wrote:
Yes, but I guess it's also memory management. I can't return str.c_str() if
str is an automatic variable. I guess I can use the trick of creating a
static std::string and return that.
Oh, right. I'd rather not expose that to projects that might
Brad King wrote:
On 7/4/2013 4:29 AM, Stephen Kelly wrote:
I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH
which can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on
the command line, I think). Should we enumerate the use cases to consider
documenting it
Brad King wrote:
IIUC currently real library paths like foo.framework/foo have no
special handling right now. They are (correctly) not split and
there is no include directory added for them.
Correct.
So, the question is: do we want to add *new* special handling for
library paths inside
On 07/10/2013 11:21 AM, Stephen Kelly wrote:
Brad King wrote:
Any
project depending on this will already have platform-specific
code to #include with the framework name.
Yes. I'm not familiar enough with mac or frameworks myself to know how
useful or 'expected' this new behavior would be?
Brad King wrote:
On 07/10/2013 11:17 AM, Stephen Kelly wrote:
Brad King wrote:
On 7/4/2013 4:29 AM, Stephen Kelly wrote:
I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH
which can't be done with CMAKE_PREFIX_PATH (with a bit more repetition
on the command line, I
Stephen Kelly wrote:
Nope, this is really not about that.
I mean 'not really', but it's also part of the story.
Thanks,
Steve.
--
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
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14285
==
Reported By:Neil Darlow
Assigned To:
On 07/10/2013 12:05 PM, Stephen Kelly wrote:
However, that won't exclude the default paths in the root prefix, so I guess
that's where CMAKE_FIND_ROOT_PATH is not replacable.
Yes.
Any project-specific place that needs to know the on-target path
can use a project-specific variable.
Yes,
15 matches
Mail list logo
