Re: [cmake-developers] Interface includes and defines plumbing
Brad King wrote: On 01/08/2013 09:07 AM, Stephen Kelly wrote: Done now, thanks. Currently target_include_directories cannot be used with a RHS target that has not yet been created. This could be problematic for projects that want circular include dependencies, especially with targets in sibling directories. Can the non-target/relative-path argument error be moved to generate time when $TARGET_PROPERTY:BadTarget,INTERFACE_INCLUDE_DIRECTORIES is evaluated? Does this make sense? Having played around with the feature a bit more, I agree that it makes sense to be able to specify use of includes from a target before the target is seen. I implemented that in the interface-commands-lazy-target-check in my clone. It has a disadvantage compared to the target_compile_definitions command and a possible workaround. 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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote: I've longed for usage requirements for years and always pictured them propagating through linking. The huge threads of discussion earlier made usage requirements seem more complicated than they are and made it feel like we should hide it all behind new interfaces. Now I think a new command will actually be *more* confusing in the long run because the two will be different only in subtle ways and users will wonder which one to use. Yes, that's exactly my thinking too. I'm almost ready to accept the proposed behavior for target_link_libraries. However, we still need to construct a recommended way for packages and their dependents to handle the transition. There are many, many instances of the old style usage since it is the only one that previously worked. How can a package author allow old dependents using the old style to keep working while also allowing new dependents using the new style to work? As compile definitions are uniq'd, they don't pose any backward compatibility concerns for downstreams of a project whose upstream adds them. In the worst case, the needed compile definitions will be duplicated by an existing call to add_definitions(), and in the best case the needed defintions will be added where they were absent before. In the case of the include directories, there could be incompatibility introduced by an upstream newly using the feature. Even if upstream has all- unique headers in multiple directories (think Qt), downstream might be also using another project which has conflicting headers (in the case of Qt, that's not likely as the 'q' prefix is well claimed). So, the options I see are: 1) Upstream introduces a find_package-time variable to evaluate whether to populate the INTERFACE_INCLUDE_DIRECTORIES (similar to QT4_USE_IMPORTED_TARGETS). Upstream would likely have to clear the target property in that case after including the exported targets file. 2) CMake introduces a standard documented way to not populate the target property in the exported targets file at all (PACKAGE_NAME_NO_INTERFACE_INCLUDE_DIRECTORIES, off by default). 3) Upstream introduces a new set of IMPORTED targets which have the INTERFACE_INCLUDE_DIRECTORIES set. CMake introduces a way to control at INSTALL(EXPORT) time whether to populate it. So upstream would do this: INSTALL(EXPORT fooTargets NAMESPACE Foo:: ...) INSTALL(EXPORT fooTargets EXPORT_INCLUDE_INTERFACE NAMESPACE FooNew:: ...) or some other naming change, and include() both in the config file. (2) is easy for us and for upstream, but source incompatible for downstream. (3) is more awkward for all upstreams, but source compatible for downstream. 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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Stephen Kelly wrote: INSTALL(EXPORT fooTargets NAMESPACE Foo:: ...) INSTALL(EXPORT fooTargets EXPORT_INCLUDE_INTERFACE NAMESPACE FooNew:: ...) or some other naming change, and include() both in the config file. (2) is easy for us and for upstream, but source incompatible for downstream. (3) is more awkward for all upstreams, but source compatible for downstream. Or, of course, (3) could be switched around and NO_EXPORT_INCLUDE_INTERFACE would not populate the INTERFACE_INCLUDE_DIRECTORIES. That would be easier for upstreams, but also leave them potentially accidentally breaking downstreams by not using it when they should. 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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Ninja + Windows CE
Hi,
to compile WindowsCE C++ project with Ninja I need the attached patch
applied.
-- PatrickFrom 7d5e1c3b41b58e29d7dde7742582b3fa35a35e8e Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Sat, 26 Jan 2013 12:28:25 +0100
Subject: [PATCH] Ninja: Fix problems with EnableLanguage()
We need to call EnableLanguage() of the base class with all
languages at once, because general CMake files which require
defines not done by the first language won't appear.
---
Source/cmGlobalNinjaGenerator.cxx | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/Source/cmGlobalNinjaGenerator.cxx
b/Source/cmGlobalNinjaGenerator.cxx
index 60f5a47..de13d13 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -502,12 +502,7 @@ void cmGlobalNinjaGenerator
std::vectorstd::string language;
language.push_back(*l);
-if(*l == NONE)
- {
- this-cmGlobalGenerator::EnableLanguage(language, mf, optional);
- continue;
- }
-else if(*l == Fortran)
+if(*l == Fortran)
{
std::string message = The \;
message += this-GetName();
@@ -551,7 +546,16 @@ void cmGlobalNinjaGenerator
}
}
}
-this-cmGlobalGenerator::EnableLanguage(language, mf, optional);
+}
+
+ this-cmGlobalGenerator::EnableLanguage(languages, mf, optional);
+ for(std::vectorstd::string::const_iterator l = languages.begin();
+ l != languages.end(); ++l)
+{
+if(*l == NONE)
+ {
+ continue;
+ }
this-ResolveLanguageCompiler(*l, mf, optional);
}
}
--
1.8.0.msysgit.0
--
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 check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
