Re: [CMake] CMake minimum required version
On Saturday 25 August 2012, Russell Wallace wrote: CMake asks me to specify a minimum required version. I'm writing a mostly fairly vanilla C++ program, primary target platforms are Linux and Windows, dependencies on Boost and GMP, using the glob facility, any idea what I should specify as the minimum version? Or is the recommendation to reason along the lines of, 2.8 is what I happen to have installed, so that's the version I know my program works with since I'm testing with it, so specify that version? That's the safe bet. If you want to support some lower version, you can download and install that lower version from http://www.cmake.org/files/ and use that. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting started with CMake
On Friday 24 August 2012, Russell Wallace wrote: Hi, I'm trying to get up and running with CMake for a project I'm working on. The online documentation seems to describe how to write the script/configuration files; I'm trying to first get my head around a more basic overview. Suppose I have a minimal project called foo, that just consists of a single C++ source file, foo.cc. I write the code and put something or other in a source distribution file called foo-1.0.tgz. A potential user downloads this to a plain-vanilla Linux box. At this stage, the user expects to type: tar xzf foo-1.0.tgz cd foo-1.0 ./configure Here he does cmake . (or better mkdir build cd build cmake .. ) The rest is the same. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] lua bindings?
On Thursday 23 August 2012, Peter Kümmel wrote: Here an example how a Lua based build system could look like: https://github.com/deplinenoise/tundra/blob/master/tundra.lua And more details here: http://deplinenoise.files.wordpress.com/2011/04/tundra43.pdf So, another buildsystem for cmake to target ? Alex -- 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] [Cdash] Problem with cdash, subprojects and CTEST_USE_LAUNCHERS=TRUE?
On Tuesday 21 August 2012, Alexander Neundorf wrote: On Tuesday 21 August 2012, David Cole wrote: On Mon, Aug 20, 2012 at 5:23 PM, Alexander Neundorf neund...@kde.orgwrote: On Monday 20 August 2012, Alexander Neundorf wrote: On Monday 20 August 2012, Alexander Neundorf wrote: ... I'm looking at it right now... I actually haven't figured out yet how that launchers feature works. Should the string launch (or --launch) appear somewhere in the buildtree as soon as I include CTest ? Ah, wait, I got it: this happens in the testing build tree where cmake is executed from within ctest, right ? Ok, here is a first try in the ErrorIfCTEST_USE_LAUNCHERSSetButLauncherRuleNotSet branch on cmake stage. It does now the following: ~/src/CMake/tests/ltest/b$ /opt/cmake-HEAD/bin/cmake - DCTEST_USE_LAUNCHERS=TRUE .. -- Configuring done CMake Error: CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE global property is not defined. Did you forget to include(CTest) in the toplevel CMakeLists.txt ? ~/src/CMake/tests/ltest/b$ Alex I think this should just be a warning. Do you think it's necessary to make it an error condition? I wondered about this too. My colleague spent quite some time trying to find the problem, and I also needed some time to find it. So, I thought it might be a good idea to error out in the case, instead of just printing a warning and proceeding. Not sure there is a use case for setting CTEST_USE_LAUNCHERS to TRUE but not including CTest.cmake, which is I think the only place where it is used. OTOH, if somebody actually has a use for this, this patch would break his build... So, warning or error ? What do the others (Bill, Brad, ...) say ? Alex -- 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] Exporting dependent library targets in multiple export sets
Hi, currently, when exporting library targets, it is required that all in-project libraries which the exported libraries depend on, are also exported in the same export set. I.e. the following currently does not work: add_library(foo SHARED foo.c) install(TARGETS foo EXPORT FooExport DESTINATION lib ) install(TARGETS foo EXPORT FooExportX DESTINATION libx ) install(EXPORT FooExport DESTINATION lib/foo ) install(EXPORT FooExport NAMESPACE Foo:: DESTINATION lib/foo2 ) install(EXPORT FooExportX DESTINATION lib/fooX ) add_library(bar SHARED bar.c) target_link_libraries(bar foo) install(TARGETS bar EXPORT BarExport DESTINATION lib ) install(EXPORT BarExport NAMESPACE Xyz:: DESTINATION lib/bar ) If I would do this, I would get the error for the BarExport export set, that it does not contain target foo, which it depends on. We'd like to make this work, since we need this in KDE. How can this be done ? Here's a relatively simple (I think) idea: export it anyway, and make sure in the generated targets file that those targets which were not part of the export-set exist: if(NOT TARGET Xyz::foo) message(FATAL_ERROR Exported Xyz::target foo not found) endif() This would leave it to the user to make sure that the export file is loaded before. There is an issue with the used namespace. Maybe it could simply assume that the targets which are not present use the same namespace as it does itself (as shown in the example above) ? Also, CMake could still error out if it detects that a library which an exported library depends on, is not exported at all, also taking into account the namespace. Would that work ? Did I miss something ? Better ideas ? Alex -- 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] [Cdash] Problem with cdash, subprojects and CTEST_USE_LAUNCHERS=TRUE?
On Tuesday 21 August 2012, David Cole wrote: On Mon, Aug 20, 2012 at 5:23 PM, Alexander Neundorf neund...@kde.orgwrote: On Monday 20 August 2012, Alexander Neundorf wrote: On Monday 20 August 2012, Alexander Neundorf wrote: ... I'm looking at it right now... I actually haven't figured out yet how that launchers feature works. Should the string launch (or --launch) appear somewhere in the buildtree as soon as I include CTest ? Ah, wait, I got it: this happens in the testing build tree where cmake is executed from within ctest, right ? Ok, here is a first try in the ErrorIfCTEST_USE_LAUNCHERSSetButLauncherRuleNotSet branch on cmake stage. It does now the following: ~/src/CMake/tests/ltest/b$ /opt/cmake-HEAD/bin/cmake - DCTEST_USE_LAUNCHERS=TRUE .. -- Configuring done CMake Error: CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE global property is not defined. Did you forget to include(CTest) in the toplevel CMakeLists.txt ? ~/src/CMake/tests/ltest/b$ Alex I think this should just be a warning. Do you think it's necessary to make it an error condition? I wondered about this too. My colleague spent quite some time trying to find the problem, and I also needed some time to find it. So, I thought it might be a good idea to error out in the case, instead of just printing a warning and proceeding. Not sure there is a use case for setting CTEST_USE_LAUNCHERS to TRUE but not including CTest.cmake, which is I think the only place where it is used. OTOH, if somebody actually has a use for this, this patch would break his build... Alex -- 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-commits] CMake branch, next, updated. v2.8.9-158-g4472d32
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 4472d32c7dc2ed9981fe9d0d6a4a89abeebbe9d1 (commit)
via 8aed02ae0f753dce76a167367ecf54be1d04de2b (commit)
via 7ae4479d655b567d0e2c67e6bdab2580a5c3d4ea (commit)
from e1610afa52e341631038f5e524533a2ea0e60344 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4472d32c7dc2ed9981fe9d0d6a4a89abeebbe9d1
commit 4472d32c7dc2ed9981fe9d0d6a4a89abeebbe9d1
Merge: e1610af 8aed02a
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Mon Aug 20 15:39:34 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Aug 20 15:39:34 2012 -0400
Merge topic 'DependencyScanning_13474' into next
8aed02a -fix Java dependency scanning, broken in previous commit
7ae4479 -fix line length
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8aed02ae0f753dce76a167367ecf54be1d04de2b
commit 8aed02ae0f753dce76a167367ecf54be1d04de2b
Author: Alex Neundorf neund...@kde.org
AuthorDate: Mon Aug 20 21:37:26 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Mon Aug 20 21:37:26 2012 +0200
-fix Java dependency scanning, broken in previous commit
Alex
diff --git a/Source/cmDependsJava.cxx b/Source/cmDependsJava.cxx
index 1d84914..ba0e8fb 100644
--- a/Source/cmDependsJava.cxx
+++ b/Source/cmDependsJava.cxx
@@ -38,7 +38,7 @@ bool cmDependsJava::WriteDependencies(const char *src, const
char *,
return true;
}
-bool cmDependsJava::CheckDependencies(std::istream,
+bool cmDependsJava::CheckDependencies(std::istream, const char*,
std::mapstd::string, DependencyVector )
{
return true;
diff --git a/Source/cmDependsJava.h b/Source/cmDependsJava.h
index fe6fef5..bf7e234 100644
--- a/Source/cmDependsJava.h
+++ b/Source/cmDependsJava.h
@@ -32,7 +32,8 @@ protected:
virtual bool WriteDependencies(const char *src, const char *file,
std::ostream makeDepends, std::ostream internalDepends);
virtual bool CheckDependencies(std::istream internalDepends,
- std::mapstd::string, DependencyVector validDeps);
+ const char* internalDependsFileName,
+ std::mapstd::string, DependencyVector validDeps);
private:
cmDependsJava(cmDependsJava const); // Purposely not implemented.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ae4479d655b567d0e2c67e6bdab2580a5c3d4ea
commit 7ae4479d655b567d0e2c67e6bdab2580a5c3d4ea
Author: Alex Neundorf neund...@kde.org
AuthorDate: Mon Aug 20 21:23:20 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Mon Aug 20 21:23:20 2012 +0200
-fix line length
Alex
diff --git a/Source/cmDepends.cxx b/Source/cmDepends.cxx
index 5a48f7f..166a584 100644
--- a/Source/cmDepends.cxx
+++ b/Source/cmDepends.cxx
@@ -243,8 +243,8 @@ bool cmDepends::CheckDependencies(std::istream
internalDepends,
// The dependee exists, but the depender doesn't. Regenerate if the
// internalDepends file is older than the dependee.
int result = 0;
-if((!this-FileComparison-FileTimeCompare(internalDependsFileName,
dependee,
- result) || result 0))
+if((!this-FileComparison-FileTimeCompare(internalDependsFileName,
+ dependee, result) || result 0))
{
// The depends-file is older than the dependee.
regenerate = true;
---
Summary of changes:
Source/cmDepends.cxx |4 ++--
Source/cmDependsJava.cxx |2 +-
Source/cmDependsJava.h |3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] FindPkgConfig, find_program and stuff
On Sunday 19 August 2012, Rolf Eike Beer wrote:
I scanned through the patches Gentoo applies to CMake to find out which
ones should be dropped in 2.8.9. I found this one:
diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index c47f583..5783d37 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -87,7 +87,12 @@
set(PKG_CONFIG_VERSION 1)
set(PKG_CONFIG_FOUND 0)
-find_program(PKG_CONFIG_EXECUTABLE NAMES pkg-config DOC pkg-config
executable) +if(NOT PKG_CONFIG_EXECUTABLE)
+ set(PKG_CONFIG_EXECUTABLE $ENV{PKG_CONFIG})
+ if(NOT PKG_CONFIG_EXECUTABLE)
+ find_program(PKG_CONFIG_EXECUTABLE NAMES pkg-config DOC
pkg- config executable)
+ endif(NOT PKG_CONFIG_EXECUTABLE)
+endif(NOT PKG_CONFIG_EXECUTABLE)
mark_as_advanced(PKG_CONFIG_EXECUTABLE)
if(PKG_CONFIG_EXECUTABLE)
They should test first whether $ENV{PKG_CONFIG} is set and use it only if it
is set. Or use the path from $ENV{PKG_CONFIG} as PATHS or HINTS for
find_program().
While thinking if we could do that better I found 2 things:
-Not related to this patch: autoconf searches for prefixed pkg-config
first, i.e. prefixed with the compiler prefix. We should probably do the
same when cross- compiling.
I am completely at a loss with pkg-config and cross compiling.
In some cases there is a pkg-config for the target (i.e. can't be executed on
the host), in some cases it's some script which can be executed on the host,
another option is to set just the pkg-config related environment variables so
that they point into the target file hierarchy, and as you say it seems there
is also sometimes a prefix-pkg-config.
I don't know what should be done.
-We have a way to give hints about the paths via an environment variable
for find_program, but I think it would make sense to also allow
environment variables specifying the absolute path to the executable
itself as part of the find_program API.
Well, you can do
$ cmake -DPKG_CONFIG_EXECUTABLE=/wherever/it/is/pkg-config ..
already right now. Isn't this good enough ?
Alex
--
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-commits] CMake branch, next, updated. v2.8.9-138-gf9c04e2
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 f9c04e2f1738d06b4a23549b32f5a7a6e708abcc (commit)
via 87fe4286bdb3f4faffbc603697b4a6f3343fb4ec (commit)
from f8133bf98febcd02690548edfbe476aaabdd0623 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f9c04e2f1738d06b4a23549b32f5a7a6e708abcc
commit f9c04e2f1738d06b4a23549b32f5a7a6e708abcc
Merge: f8133bf 87fe428
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Fri Aug 17 16:41:42 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 17 16:41:42 2012 -0400
Merge topic 'DependencyScanning_13474' into next
87fe428 fix #13474: also rescan dependencies if the depender does not exist
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87fe4286bdb3f4faffbc603697b4a6f3343fb4ec
commit 87fe4286bdb3f4faffbc603697b4a6f3343fb4ec
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 22:46:33 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Fri Aug 17 22:38:38 2012 +0200
fix #13474: also rescan dependencies if the depender does not exist
If the depender (e.g. foo.o) does not exist, also rescan dependencies if
one of the dependees (e.g. foo.cxx) is older than the already existing
depend.internal file, since this means it can be out of date.
Alex
diff --git a/Source/cmDepends.cxx b/Source/cmDepends.cxx
index 545fe97..5a48f7f 100644
--- a/Source/cmDepends.cxx
+++ b/Source/cmDepends.cxx
@@ -98,7 +98,7 @@ bool cmDepends::Check(const char *makeFile, const char
*internalFile,
// Check whether dependencies must be regenerated.
bool okay = true;
std::ifstream fin(internalFile);
- if(!(fin this-CheckDependencies(fin, validDeps)))
+ if(!(fin this-CheckDependencies(fin, internalFile, validDeps)))
{
// Clear all dependencies so they will be regenerated.
this-Clear(makeFile);
@@ -143,6 +143,7 @@ bool cmDepends::WriteDependencies(const char*, const char*,
//
bool cmDepends::CheckDependencies(std::istream internalDepends,
+ const char* internalDependsFileName,
std::mapstd::string, DependencyVector validDeps)
{
// Parse dependencies from the stream. If any dependee is missing
@@ -186,8 +187,11 @@ bool cmDepends::CheckDependencies(std::istream
internalDepends,
}
*/
-// Dependencies must be regenerated if the dependee does not exist
-// or if the depender exists and is older than the dependee.
+// Dependencies must be regenerated
+// * if the dependee does not exist
+// * if the depender exists and is older than the dependee.
+// * if the depender does not exist, but the dependee is newer than the
+// depends file
bool regenerate = false;
const char* dependee = this-Dependee+1;
const char* depender = this-Depender;
@@ -211,24 +215,49 @@ bool cmDepends::CheckDependencies(std::istream
internalDepends,
cmSystemTools::Stdout(msg.str().c_str());
}
}
-else if(dependerExists)
+else
{
- // The dependee and depender both exist. Compare file times.
- int result = 0;
- if((!this-FileComparison-FileTimeCompare(depender, dependee,
- result) || result 0))
+ if(dependerExists)
{
-// The depender is older than the dependee.
-regenerate = true;
+// The dependee and depender both exist. Compare file times.
+int result = 0;
+if((!this-FileComparison-FileTimeCompare(depender, dependee,
+ result) || result 0))
+ {
+ // The depender is older than the dependee.
+ regenerate = true;
-// Print verbose output.
-if(this-Verbose)
+ // Print verbose output.
+ if(this-Verbose)
+{
+cmOStringStream msg;
+msg Dependee \ dependee
+ \ is newer than depender \
+ depender \. std::endl;
+cmSystemTools::Stdout(msg.str().c_str());
+}
+ }
+}
+ else
+{
+// The dependee exists, but the depender doesn't. Regenerate if the
+// internalDepends file is older than the dependee.
+int result = 0;
+if((!this-FileComparison-FileTimeCompare(internalDependsFileName,
dependee,
+ result) || result 0
Re: [CMake] CMAKE 2.8.9, OS X 10.8 and OpenGL
On Wednesday 15 August 2012, Jason T. Slack-Moehrle wrote: HI Mike, SET(CMAKE_C_COMPILER clang) SET(CMAKE_CXX_COMPILER clang++) Those really will have no effect. If you want to use Clang, then set the CC and CXX environment variables BEFORE running cmake for the first time. By the time CMake gets to those lines the C and C++ compilers are already set and can not be changed. ok, I got it. so I can just do this in a shell script so I dont have to remember to do it! ...and you only have to do that for the initial cmake run, after that has found the compiler and stored them in the cache (CMakeCache.txt). Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.9-119-g6da9e9a
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 6da9e9ab53459b3efd9a3e2623a01558b40387e6 (commit)
via 9110d0eab4ed3b024ad485eaaf15b1d7e4c38744 (commit)
via d97b38529efb22579216c406c104c49ea89ba617 (commit)
via c4306dc8057c45bc5edfd18465f85790800124cd (commit)
from 9ae27d461399f6bed55d2fa13df0eea7cb2f88e1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6da9e9ab53459b3efd9a3e2623a01558b40387e6
commit 6da9e9ab53459b3efd9a3e2623a01558b40387e6
Merge: 9ae27d4 9110d0e
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 17:04:07 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 16 17:04:07 2012 -0400
Merge topic 'HandleMacFrameworkIncludeDirs_13465' into next
9110d0e Eclipse on OSX: improve handling of framework include dirs (#13367)
d97b385 Eclipse on OSX: fix handling of framework include dirs (#13464)
c4306dc CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9110d0eab4ed3b024ad485eaaf15b1d7e4c38744
commit 9110d0eab4ed3b024ad485eaaf15b1d7e4c38744
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Aug 10 21:45:03 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 16 23:02:10 2012 +0200
Eclipse on OSX: improve handling of framework include dirs (#13367)
It seems that if cmake finds something like the following:
/System/Library/Frameworks/GLUT.framework/Headers
Eclipse doesn't like that and wants to have
/System/Library/Frameworks
instead
Alex
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx
b/Source/cmExtraEclipseCDT4Generator.cxx
index 5c7d400..99ca375 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -610,6 +610,16 @@ void cmExtraEclipseCDT4Generator::AppendIncludeDirectories(
if (!inc-empty())
{
std::string dir = cmSystemTools::CollapseFullPath(inc-c_str());
+
+ // handle framework include dirs on OSX, the remainder after the
+ // Frameworks/ part has to be stripped
+ // /System/Library/Frameworks/GLUT.framework/Headers
+ cmsys::RegularExpression
frameworkRegex((.+/Frameworks)/.+\\.framework/);
+ if(frameworkRegex.find(dir.c_str()))
+{
+dir = frameworkRegex.match(1);
+}
+
if(emittedDirs.find(dir) == emittedDirs.end())
{
emittedDirs.insert(dir);
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d97b38529efb22579216c406c104c49ea89ba617
commit d97b38529efb22579216c406c104c49ea89ba617
Author: Alex Neundorf neund...@kde.org
AuthorDate: Fri Aug 10 21:28:40 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 16 23:02:10 2012 +0200
Eclipse on OSX: fix handling of framework include dirs (#13464)
On OSX, the output from gcc looks like this:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64
/usr/include/c++/4.2.1/backward
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
The (framework directory) part needs to be removed so that Eclipse
handles it properly
Alex
diff --git
a/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
b/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
index 54a6418..1fa0157 100644
--- a/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
+++ b/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
@@ -42,7 +42,10 @@ macro(_DETERMINE_GCC_SYSTEM_INCLUDE_DIRS _lang
_resultIncludeDirs _resultDefines
# split the output into lines and then remove leading and trailing spaces
from each of them:
string(REGEX MATCHALL [^\n]+\n _includeLines ${CMAKE_MATCH_1})
foreach(nextLine ${_includeLines})
- string(STRIP ${nextLine} _includePath)
+ # on OSX, gcc says things like this: /System/Library/Frameworks
(framework directory), strip the last part
+ string(REGEX REPLACE \\(framework directory\\) nextLineNoFramework
${nextLine})
+ # strip spaces at the beginning and the end
+ string(STRIP ${nextLineNoFramework} _includePath)
list(APPEND ${_resultIncludeDirs} ${_includePath})
endforeach()
---
Summary of changes:
...atorDetermineCompilerMacrosAndIncludeDirs.cmake |5 -
Source/CMakeVersion.cmake
[Cmake-commits] CMake branch, next, updated. v2.8.9-123-g1b33e8a
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 1b33e8a0f802c011c6789fce2384480d706b2811 (commit)
via 5271ba56be87d5f412ea21c6c30cb72a893ceb25 (commit)
from 79d2c9c0e3f946bb290a7da447e9e5272d0b31bf (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b33e8a0f802c011c6789fce2384480d706b2811
commit 1b33e8a0f802c011c6789fce2384480d706b2811
Merge: 79d2c9c 5271ba5
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 17:16:13 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 16 17:16:13 2012 -0400
Merge topic 'EclipseRemoveLinkedOutputDirectoryResources' into next
5271ba5 Eclipse: fix #13358: don't create bad linked resources
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5271ba56be87d5f412ea21c6c30cb72a893ceb25
commit 5271ba56be87d5f412ea21c6c30cb72a893ceb25
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Jul 28 18:00:19 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 16 23:15:21 2012 +0200
Eclipse: fix #13358: don't create bad linked resources
directory where the project file is located (${CMAKE_BINARY_DIR}), which can
happen e.g. for EXECUTABLE_OUTPUT_PATH and related variables.
Now, it seems this code never worked.
If EXECUTABLE_OUTPUT_PATH was set to point into a subdir of
CMAKE_BINARY_DIR,
the code did nothing.
If it pointed directly at CMAKE_BINARY_DIR or some other location, it
created
a linked resource. I tested this with Eclipse Europa (3.3) and Juno (4.2),
and in this
case both versions of Eclipse complained that this is a bad location for a
linked resource.
Alex
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx
b/Source/cmExtraEclipseCDT4Generator.cxx
index 5c7d400..eccc2c1 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -462,18 +462,6 @@ void cmExtraEclipseCDT4Generator::CreateProjectFile()
this-CreateLinksForTargets(fout);
}
- // I'm not sure this makes too much sense. There can be different
- // output directories in different subdirs, so we would need more of them.
-
- // for EXECUTABLE_OUTPUT_PATH when not in binary dir
- this-AppendOutLinkedResource(fout,
-mf-GetSafeDefinition(CMAKE_RUNTIME_OUTPUT_DIRECTORY),
-mf-GetSafeDefinition(EXECUTABLE_OUTPUT_PATH));
- // for LIBRARY_OUTPUT_PATH when not in binary dir
- this-AppendOutLinkedResource(fout,
-mf-GetSafeDefinition(CMAKE_LIBRARY_OUTPUT_DIRECTORY),
-mf-GetSafeDefinition(LIBRARY_OUTPUT_PATH));
-
fout \t/linkedResources\n;
fout /projectDescription\n;
@@ -761,18 +749,6 @@ void cmExtraEclipseCDT4Generator::CreateCProjectFile()
const
excludeFromOut += **/CMakeFiles/;
fout pathentry excluding=\ excludeFromOut
\ kind=\out\ path=\\/\n;
- // add output entry for EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH
- // - if it is a subdir of homeOutputDirectory, there is no need to add it
- // - if it is not then create a linked resource and add the linked name
- // but check it doesn't conflict with other linked resources names
- for (std::vectorstd::string::const_iterator
- it = this-OutLinkedResources.begin();
- it != this-OutLinkedResources.end();
- ++it)
-{
-fout pathentry kind=\out\ path=\ this-EscapeForXML(*it)
- \/\n;
-}
// add pre-processor definitions to allow eclipse to gray out sections
emmited.clear();
@@ -1317,65 +1293,3 @@ void cmExtraEclipseCDT4Generator
\t\t/link\n
;
}
-
-bool cmExtraEclipseCDT4Generator
-::AppendOutLinkedResource(cmGeneratedFileStream fout,
- const std::string defname,
- const std::string altdefname)
-{
- if (defname.empty() altdefname.empty())
-{
-return false;
-}
-
- std::string outputPath = (defname.empty() ? altdefname : defname);
-
- if (!cmSystemTools::FileIsFullPath(outputPath.c_str()))
-{
-outputPath = this-HomeOutputDirectory + / + outputPath;
-}
-
- // in this case it's not necessary:
- if (cmSystemTools::IsSubDirectory(outputPath.c_str(),
-this-HomeOutputDirectory.c_str()))
-{
-return false;
-}
-
- // in these two cases Eclipse would complain:
- if (cmSystemTools::IsSubDirectory(this-HomeOutputDirectory.c_str(),
-outputPath.c_str()))
-{
-return false;
-}
- if (cmSystemTools::GetRealPath(outputPath.c_str())
- == cmSystemTools::GetRealPath
[Cmake-commits] CMake branch, next, updated. v2.8.9-125-g027d2d9
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 027d2d9dd0f4c15a8a79c1a11b9c510ddb257d8a (commit)
via 11f23fee523347a52eb36d439f89b5bd6e99fa6b (commit)
from 1b33e8a0f802c011c6789fce2384480d706b2811 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=027d2d9dd0f4c15a8a79c1a11b9c510ddb257d8a
commit 027d2d9dd0f4c15a8a79c1a11b9c510ddb257d8a
Merge: 1b33e8a 11f23fe
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 17:30:03 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 16 17:30:03 2012 -0400
Merge topic 'RemoveNonworkingKDE4Test' into next
11f23fe remove non-working KDE4 test
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11f23fee523347a52eb36d439f89b5bd6e99fa6b
commit 11f23fee523347a52eb36d439f89b5bd6e99fa6b
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 23:28:52 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 16 23:28:52 2012 +0200
remove non-working KDE4 test
Alex
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 9512ea6..2ba616e 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -70,11 +70,6 @@ if(BUILD_TESTING)
Should the tests that run a full sub ctest process be run?
OFF)
mark_as_advanced(CTEST_TEST_CTEST)
-
-option(TEST_KDE4_STABLE_BRANCH
- Should the KDE4 stable branch test be run?
- OFF)
-mark_as_advanced(TEST_KDE4_STABLE_BRANCH)
endif ()
# Should tests that use CVS be run?
@@ -2106,43 +2101,6 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
endif ()
endif ()
- if (CMAKE_RUN_LONG_TESTS AND TEST_KDE4_STABLE_BRANCH)
-if(UNIX)
- if(NOT QT4_FOUND)
- find_package(Qt4)
- endif()
-
- set(TRY_BUILD_KDE4 TRUE)
- if(QT4_FOUND)
-# check whether it's Qt 4.5 in a cmake 2.4. compatible way:
-if(NOT EXISTS ${QT_QTNETWORK_INCLUDE_DIR}/QAbstractNetworkCache)
- set(TRY_BUILD_KDE4 FALSE)
-endif()
- else()
-set(TRY_BUILD_KDE4 FALSE)
- endif()
-
- find_package(Perl)
- if(NOT PERL_FOUND)
-set(TRY_BUILD_KDE4 FALSE)
- endif()
-
- find_package(ZLIB)
- if(NOT ZLIB_FOUND)
-set(TRY_BUILD_KDE4 FALSE)
- endif()
-
- if(TRY_BUILD_KDE4)
-file(MAKE_DIRECTORY ${CMake_BINARY_DIR}/Tests/KDE4StableBranchTest)
-set(TEST_KDE4_BASE_DIR ${CMake_BINARY_DIR}/Tests/KDE4StableBranchTest)
-
configure_file(${CMake_SOURCE_DIR}/Tests/KDE4StableBranchTest/test_kde4.sh.in
${CMake_BINARY_DIR}/Tests/KDE4StableBranchTest/test_kde4.sh @ONLY)
-execute_process(COMMAND chmod 755
${CMake_BINARY_DIR}/Tests/KDE4StableBranchTest/test_kde4.sh )
-add_test(KDE4StableBranchTest
${CMake_BINARY_DIR}/Tests/KDE4StableBranchTest/test_kde4.sh)
- endif()
-
-endif()
- endif ()
-
if(${CMAKE_TEST_GENERATOR} MATCHES Xcode)
set(CMAKE_SKIP_BOOTSTRAP_TEST 1)
endif()
diff --git a/Tests/KDE4StableBranchTest/test_kde4.sh.in
b/Tests/KDE4StableBranchTest/test_kde4.sh.in
deleted file mode 100755
index bc90b9d..000
--- a/Tests/KDE4StableBranchTest/test_kde4.sh.in
+++ /dev/null
@@ -1,62 +0,0 @@
-#!/bin/sh
-
-# This shell script tests whether cmake is able to build the latest
-# stable KDE4 release, or at least some part of it.
-# It downloads automoc from KDE svn, builds and installs it, then it
-# downloads phonon from KDE svn, builds and installs it, and finally
-# it downloads kdelibs (currently from the 4.3 branch), and builds
-# a (small) part of it, i.e. libkdecore and one unit test depending on it.
-#
-# neundorf AT kde.org
-
-CMAKE=@CMAKE_CMAKE_COMMAND@
-BASEDIR=@TEST_KDE4_BASE_DIR@
-INSTALLDIR=$BASEDIR/install
-QMAKE=@QT_QMAKE_EXECUTABLE@
-
-cd $BASEDIR || exit -1
-echo Removing old install dir $INSTALLDIR
-
-rm -rf install || exit -1
-rm -rf build-automoc || exit -1
-rm -rf build-phonon || exit -1
-rm -rf build-kdelibs || exit -1
-
-
-
-# build and install automoc
-cd $BASEDIR || exit -1
-svn co
svn://anonsvn.kde.org/home/kde/tags/kdesupport-for-4.3/kdesupport/automoc ||
exit -1
-
-mkdir -p build-automoc || exit -1
-
-cd build-automoc || exit -1
-$CMAKE -DCMAKE_INSTALL_PREFIX=$INSTALLDIR
-DQT_QMAKE_EXECUTABLE:STRING=$QMAKE ../automoc || exit -1
-$CMAKE --build . || exit -1
-$CMAKE -P cmake_install.cmake || exit -1
-
-export CMAKE_PREFIX_PATH=$INSTALLDIR:$CMAKE_PREFIX_PATH
-
-
-# build and install phonon
-cd $BASEDIR || exit -1
-svn co
svn://anonsvn.kde.org/home/kde/tags/kdesupport-for-4.3/kdesupport
[Cmake-commits] CMake branch, next, updated. v2.8.9-127-gdbb747a
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 dbb747aad856fc914236429edaa2881b62048dab (commit)
via a3815e67cf9ff7f542e809d8974b695893a6a783 (commit)
from 027d2d9dd0f4c15a8a79c1a11b9c510ddb257d8a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbb747aad856fc914236429edaa2881b62048dab
commit dbb747aad856fc914236429edaa2881b62048dab
Merge: 027d2d9 a3815e6
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 17:38:01 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Aug 16 17:38:01 2012 -0400
Merge topic 'HandleMacFrameworkIncludeDirs_13465' into next
a3815e6 -fix line length
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3815e67cf9ff7f542e809d8974b695893a6a783
commit a3815e67cf9ff7f542e809d8974b695893a6a783
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Aug 16 23:37:15 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 16 23:37:15 2012 +0200
-fix line length
Alex
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx
b/Source/cmExtraEclipseCDT4Generator.cxx
index 99ca375..bb650eb 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -614,10 +614,10 @@ void
cmExtraEclipseCDT4Generator::AppendIncludeDirectories(
// handle framework include dirs on OSX, the remainder after the
// Frameworks/ part has to be stripped
// /System/Library/Frameworks/GLUT.framework/Headers
- cmsys::RegularExpression
frameworkRegex((.+/Frameworks)/.+\\.framework/);
- if(frameworkRegex.find(dir.c_str()))
+ cmsys::RegularExpression frameworkRx((.+/Frameworks)/.+\\.framework/);
+ if(frameworkRx.find(dir.c_str()))
{
-dir = frameworkRegex.match(1);
+dir = frameworkRx.match(1);
}
if(emittedDirs.find(dir) == emittedDirs.end())
---
Summary of changes:
Source/cmExtraEclipseCDT4Generator.cxx |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] Proposal: An IRC dev meeting to chat about CMake stuff
On Wednesday 15 August 2012, David Cole wrote: This is a good idea. How many people would join in if we had a CMake meeting in #cmake IRC? What would be the best day of week and time of day to have one? Usually on workdays after 6 PM, better after 8 PM, Berlin time. Alex -- 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] Bug tracker: I need your help
On Monday 13 August 2012, David Cole wrote: Hi everybody, I need your help. In the next week, if you have time. ... Done for my stuff. Alex -- 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] Bug fix requests for the *next* release of CMake...
On Friday 10 August 2012, David Cole wrote: Hi all, Replies requested. Short replies only. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Example one-line reply: http://public.kitware.com/Bug/view.php?id=13463 Personally I would prefer this link together with the title of the bug - makes it much faster to see what the bug is about: http://public.kitware.com/Bug/view.php?id=12621 - Compatibility with Xcode 4.3 Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] qt4_use_modules
On Friday 10 August 2012, Stephen Kelly wrote: David Cole wrote: I assume it's the qt4_use_modules branch on the stage? Yes, sorry, I should have pointed that out. What was the plan with the more generic target_use_package() or how it was named ? This would do something similar, right ? Alex -- 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] Eclipse generator on mac
On Thursday 09 August 2012, Alexander Broekhuis wrote: Hi Copy'n paste error, I meant this one: http://public.kitware.com/Bug/view.php?id=13367 Can you please look at this one ? No also doesn't look the same. I don't have any missing/incorrect includes other than the 2 mentioned before. Ah, sorry, I missed the part with the braces. Can you please post the output of the following command here ? g++ -v -E -x c++ -dD /dev/null (or clang if you're using that). It would be even better if you could create a bug report at http://public.kitware.com/Bug for this and put the information there :-) One thing that I noticed, it is important to not have any includes in the CMake files pointing to nothing/empty dirs. For the Makefiles this isn't a problem, but in Eclipse those entries are shown as warnings. But this is a problem of my CMake files, not of CMake/Eclipse. * Warnings/Errors are shown three times (Source Directory, Subprojects, Targets) What are subproject and targets? Is there something I can do about this? Seeing everything three times is really confusing. Ah, this is this one: http://public.kitware.com/Bug/view.php?id=13189 I thought this would be a good idea but know it seems people are more complaining about it than liking it... * GIT Team Support isn't added to the source project (is this the normal case for SVN?) This is a deficiency of Eclipse. I filed a bug report at Eclipse. The version control plugins are simply not called for files which are not in a subdir of the project file :-/ I am talking about the Source project. Generated using -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE. If I add the team provided myself it all works ok, but this makes it impossible to regenerate the project files. Can CMake add the team provider during generation? Probably, I'll have a look. Can you create a ticket at http://public.kitware.com/Bug for cmake for that ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Eclipse generator on mac
Hi Alexander, On Wednesday 08 August 2012, Alexander Broekhuis wrote: Hi all, I use the Eclipse CDT4 generator to generate unix makefiles on OSX. Generation works without any errors, but in the generated files there are some errors. There are 2 paths in the .cproject file incorrect: pathentry include=/System/Library/Frameworks (framework directory) kind= inc path= system=true/ pathentry include=/Library/Frameworks (framework directory) kind=inc path= system=true/ Changing these (remove the (framework directory) part) makes the project files work without any problem. What kind of problem do you actually have ? Is there something I am missing in the configuration? No, you are not missing something. It seems the Eclipse project generator needs some special handling for OSX. Is this the maybe same issue as this one ? http://public.kitware.com/Bug/view.php?id=12579 Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Eclipse generator on mac
On Wednesday 08 August 2012, Alexander Broekhuis wrote: Hi No, you are not missing something. It seems the Eclipse project generator needs some special handling for OSX. Is this the maybe same issue as this one ? http://public.kitware.com/Bug/view.php?id=12579 Copy'n paste error, I meant this one: http://public.kitware.com/Bug/view.php?id=13367 Can you please look at this one ? No, I don't have any distant directories. My setup is like: root/CMakeLists.txt root/SubDirs*/CMakeLists.txt root-build/generated files Some other problems I do have: * Warnings/Errors are shown three times (Source Directory, Subprojects, Targets) What are subproject and targets? * GIT Team Support isn't added to the source project (is this the normal case for SVN?) This is a deficiency of Eclipse. I filed a bug report at Eclipse. The version control plugins are simply not called for files which are not in a subdir of the project file :-/ And perhaps not possible, but can CMake keep track of user changes vs the generated files? If I regenerate the project files all my changes are gone. Currently, no. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] find_package without REQUIRED can cause fatal error now
On Tuesday 31 July 2012, Bill Hoffman wrote: On 7/30/2012 3:38 PM, Alexander Neundorf wrote: The idea was that this is a sign of a broken install. Can you uninstall the vtk-devel package (does this exist ?), because it is broken, i.e. does not contain everything is claims to ? I understand that this is maybe not expected behaviour for an optional package, but maybe Brad is right ? Alex Yes, VTK is broken on the machine, and we could fix the machine. However, this would be the first time we did a work around for the modules test by fixing the machine. I wonder if we could just disable fatal error at the start of find_package optional. Then turn it back on at the end. My concern is optional packages, maybe that is a rare case not sure. One reason why I wanted it to be an error was to force people to fix their install, make it is obvious that it is not the fault of the buildsystem of the project being built, but of the package being used. I'm not sure it is better to fail relatively silently in this case instead of complaining loudly that the package is broken. Users might wonder why it doesn't work, the devel package is installed, in the right place, and still CMake doesn't pick it up. I can have a look how to make it not an error if the find_package() is optional, if we really want that. Alex -- 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] Question on internal CMAKE_* variables and scope
On Tuesday 31 July 2012, Fabio Fracassi wrote: Hi, I ran into some problems when I tried to set a cmake internal variable (CMAKE_MODULE_PATH) from a function. I understand that when I use list() commands an new local scoped variable is created that I have to export to the parent scope. I tried to do that but it seems that the scope of cmake internal variables is a different thing. No, they are normal variables. Can you post an example which shows the problem ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] find_package without REQUIRED can cause fatal error now
On Monday 30 July 2012, Bill Hoffman wrote: Alex added this check: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2be068c It guards against broken installations of packages. This is a good thing. However, it is causing a failed test: http://open.cdash.org/buildSummary.php?buildid=2465838 --Checking FindVTK CMake Error at //lib/vtk-5.8/VTKTargets-debug.cmake:996 (MESSAGE): The imported target vtkWrapTcl references the file //bin/vtkWrapTcl but this file does not exist. Possible reasons include: So, there is a bad config file for VTK on this machine. However, if someone does an optional find_package it should not error out. If you were building a project that you did not write the cmake files for and came across this error for an optional part of the system you might be stuck. The idea was that this is a sign of a broken install. Can you uninstall the vtk-devel package (does this exist ?), because it is broken, i.e. does not contain everything is claims to ? I understand that this is maybe not expected behaviour for an optional package, but maybe Brad is right ? Alex -- 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] Recommended Multilib Build Approach?
On Monday 30 July 2012, Gregory Peele ARA/CFD wrote: From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Sent: Saturday, July 28, 2012 11:48 AM To: cmake@cmake.org Cc: Gregory Peele ARA/CFD Subject: Re: [CMake] Recommended Multilib Build Approach? On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote: Hi all, I want to be able to build 32-bit and 64-bit from the same GCC multilib install (currently for MinGW-w64, though this also applies for Linux/Mac GCC and LLVM). To clarify, I want to be able to do two completely separate builds in separate binary dirs - building fat binaries from multiple architectures in the same binary dir is a separate problem I'm also interested in for Android, but I'm not worrying about that yet. What is the proper approach to building the non-default arch in a multilib setup? Obviously using CMake as-is will build the default arch just fine. I think there are no recommendations yet. I'm not aware that somebody else already tried to do this. Can the executables built for the non-default architecture be executed on the hopst where you are building ? If so, there should be a way :-) If not, this sounds like somewhat like crosscompiling. Alex I haven't explored the topic any further since posting. On a multilib system, all multilib architectures are native to the host and can be executed. Ah, ok. So the idea is not that I have e.g. /usr/lib/i386/ and /usr/lib/x86-64 and also /usr/lib/armv7/ and /usr/lib/mips/, which have different libs but share the headers and all other architecture independent files ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Recommended Multilib Build Approach?
On Monday 30 July 2012, Xavier Besseron wrote: Hello Greg, To build i386 binaries on my 64-bit system with multilib, I just do something like this: mkdir build-i386 cd build-i386 CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-melf_i386 cmake ../src/ And to build x86-64 binaries on my 64-bit system, I don't need to specify anything since it is the default behavior. Is this maybe somewhat similar to the fat binaries on OSX ? How is this handled by CMake ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Use OBJECT_DEPENDS in qt4_generate_moc() ?
On Friday 27 July 2012, David Cole wrote: On Fri, Jul 27, 2012 at 4:27 PM, Alexander Neundorf neund...@kde.org wrote: On Thursday 05 July 2012, David Cole wrote: On Thu, Jul 5, 2012 at 12:29 PM, Clinton Stimpson clin...@elemtech.com wrote: On Thursday, July 05, 2012 06:20:56 PM Alexander Neundorf wrote: On Thursday, 5. July 2012 17:37:21 Clinton Stimpson wrote: On Friday, June 15, 2012 09:56:51 PM Alexander Neundorf wrote: Hi, attached is a small patch which sets the OBJECT_DEPENDS property of a moced file to the generated moc file. This has the effect that before the cpp file is built, moc has been run on it. We have that in KDE's version of qt4_generate_moc() this way since 2006 and it works for us. In cmake's version, it was removed January 11th 2008, the removed call to MACRO_ADD_FILE_DEPENDENCIES(): http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=510f578f8b5385 8fb b541c 4e7 e4731de9bfbd483 Now since we are trying to get rid of our custom stuff in KDE, we hit that issue when trying to build parts of KDE with FindQt4.cmake from cmake. Do you remember why this line was removed ? What do you think about adding it again, as the attached patch does ? Alex It was probably removed because I thought add_custom_command() already added the needed dependency information. It should already have this: mocable.h - moc_mocable.cpp - moc_mocable.o This works if the generated moc file is listed as source file for a target. In several places we did not do this, and relied instead on the OBJECT_DEPENDS. Ahh, this was in places where the moc file is generated from a cpp file, which includes the moc file. In those cases the OBJECT_DEPENDS makes it work. We fixed this in the meantime by adding the generated moc file to the source list (which is not too bad, since the developer explicitely names the moc file, so it is ok). So, I would like to have that dependency, but I'm unsure whether it might have any unwanted side effects. Ah, so for the case mocable.h - mocable.moc - mocable.cpp (includes mocable.moc) the mocable.moc is not listed in the sources of the target. I can't think of any possible unwanted side effects. I agree that we need to have this patch. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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 If somebody pushes this to 'next' today or tomorrow, I'll make sure we can get it into 2.8.9-rc2. Too late now for 2.8.9 ? Alex Unless you tell me it's absolutely critical, and the fix is 99.% safe, then, yes, it's too late. But 2.8.10 is right around the corner if you adopt the right viewpoint. :-) Ok, this can wait until 2.8.10. Can the branch EclipseAddSupportForJuno still make it into 2.8.9 ? It improves the Eclipse generator by adding support for Eclipse Juno (the most recent one) and improves behaviour on Mac, and it should be completely safe. Alex -- 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] Recommended Multilib Build Approach?
On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote: Hi all, I want to be able to build 32-bit and 64-bit from the same GCC multilib install (currently for MinGW-w64, though this also applies for Linux/Mac GCC and LLVM). To clarify, I want to be able to do two completely separate builds in separate binary dirs - building fat binaries from multiple architectures in the same binary dir is a separate problem I'm also interested in for Android, but I'm not worrying about that yet. What is the proper approach to building the non-default arch in a multilib setup? Obviously using CMake as-is will build the default arch just fine. I think there are no recommendations yet. I'm not aware that somebody else already tried to do this. Can the executables built for the non-default architecture be executed on the hopst where you are building ? If so, there should be a way :-) If not, this sounds like somewhat like crosscompiling. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling - Avoiding libraries
On Wednesday 18 July 2012, Svenskmand wrote: Hello :) I am one of the developers of OpenDungeons a FOSS RTS game inspired by Dungeon Keeper. I am trying to cross-compile our game on Ubuntu 12.04 for Windows (XP, Vista and 7), but I have run into some trouble. ... SVN/mediaSource/ODLinuxBuildScripts/build_dir/CEGUI/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target OpenDungeons requests linking to directory /home/ckr/Documents/OD SVN/mediaSource/ODLinuxBuildScripts/build_dir/OgreSDK_mingw_v1-7-2/lib/rele ase. Targets may link only to libraries. CMake is dropping the item. -- Generating done -- Build files have been written to: /home/ckr/Documents/OD SVN/mediaSource/ODLinuxBuildScripts/build_dir/opendungeons-0.4.9 Which I am not sure are important or not (but that is not my question for now). Can you try to produce a small testcase which you can post here ? I have never seen that message before. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.8-3581-g185faf5
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 185faf5db13866d04407d1c01b933b4330d235cd (commit)
via 53cc1026bcf446c4e854bac7d6885879f4d8c64a (commit)
via bcccddc7e99336faabe7d15f121d41282773cfcc (commit)
from 2a190dd059ab8293d989684fe560b898110a2ce8 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=185faf5db13866d04407d1c01b933b4330d235cd
commit 185faf5db13866d04407d1c01b933b4330d235cd
Merge: 2a190dd 53cc102
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Sat Jul 28 06:02:18 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Jul 28 06:02:18 2012 -0400
Merge topic 'EclipseAddSupportForJuno' into next
53cc102 Eclipse: improve (fix ?) version detection on OSX
bcccddc Eclipse: add support for the 4.2 Juno release (#13367)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53cc1026bcf446c4e854bac7d6885879f4d8c64a
commit 53cc1026bcf446c4e854bac7d6885879f4d8c64a
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Jul 28 11:58:04 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sat Jul 28 11:58:04 2012 +0200
Eclipse: improve (fix ?) version detection on OSX
This is probably related to a framework installation I guess.
This is part of the patch in #13367 from Nicholas Yue.
Alex
diff --git a/Modules/CMakeFindEclipseCDT4.cmake
b/Modules/CMakeFindEclipseCDT4.cmake
index 80c51c1..86c1a1b 100644
--- a/Modules/CMakeFindEclipseCDT4.cmake
+++ b/Modules/CMakeFindEclipseCDT4.cmake
@@ -24,6 +24,9 @@ FUNCTION(_FIND_ECLIPSE_VERSION)
GET_FILENAME_COMPONENT(_REALPATH_CMAKE_ECLIPSE_EXECUTABLE
${CMAKE_ECLIPSE_EXECUTABLE} REALPATH)
GET_FILENAME_COMPONENT(_ECLIPSE_DIR
${_REALPATH_CMAKE_ECLIPSE_EXECUTABLE} PATH)
FILE(GLOB _ECLIPSE_FEATURE_DIR
${_ECLIPSE_DIR}/features/org.eclipse.platform*)
+IF(APPLE AND NOT _ECLIPSE_FEATURE_DIR)
+ FILE(GLOB _ECLIPSE_FEATURE_DIR
${_ECLIPSE_DIR}/../../../features/org.eclipse.platform*)
+ENDIF()
IF(${_ECLIPSE_FEATURE_DIR} MATCHES
.+org.eclipse.platform_([0-9]+\\.[0-9]+).+)
SET(_ECLIPSE_VERSION ${CMAKE_MATCH_1})
ENDIF()
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bcccddc7e99336faabe7d15f121d41282773cfcc
commit bcccddc7e99336faabe7d15f121d41282773cfcc
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Jul 28 11:40:08 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sat Jul 28 11:40:08 2012 +0200
Eclipse: add support for the 4.2 Juno release (#13367)
Thanks for the path to Nicholas Yue.
Alex
diff --git a/Modules/CMakeFindEclipseCDT4.cmake
b/Modules/CMakeFindEclipseCDT4.cmake
index a4264e7..80c51c1 100644
--- a/Modules/CMakeFindEclipseCDT4.cmake
+++ b/Modules/CMakeFindEclipseCDT4.cmake
@@ -37,6 +37,7 @@ FUNCTION(_FIND_ECLIPSE_VERSION)
SET(_ECLIPSE_VERSION_NAME_3.5 Galileo )
SET(_ECLIPSE_VERSION_NAME_3.6 Helios )
SET(_ECLIPSE_VERSION_NAME_3.7 Indigo )
+ SET(_ECLIPSE_VERSION_NAME_4.2 Juno )
IF(_ECLIPSE_VERSION)
MESSAGE(STATUS Found Eclipse version ${_ECLIPSE_VERSION}
(${_ECLIPSE_VERSION_NAME_${_ECLIPSE_VERSION}}))
@@ -51,7 +52,9 @@ FUNCTION(_FIND_ECLIPSE_VERSION)
3.4
(${_ECLIPSE_VERSION_NAME_3.4})
3.5
(${_ECLIPSE_VERSION_NAME_3.5})
3.6
(${_ECLIPSE_VERSION_NAME_3.6})
-3.7
(${_ECLIPSE_VERSION_NAME_3.7}))
+3.7
(${_ECLIPSE_VERSION_NAME_3.7})
+4.2
(${_ECLIPSE_VERSION_NAME_4.2})
+ )
ENDFUNCTION()
_FIND_ECLIPSE_VERSION()
---
Summary of changes:
Modules/CMakeFindEclipseCDT4.cmake |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] Use OBJECT_DEPENDS in qt4_generate_moc() ?
On Thursday 05 July 2012, David Cole wrote: On Thu, Jul 5, 2012 at 12:29 PM, Clinton Stimpson clin...@elemtech.com wrote: On Thursday, July 05, 2012 06:20:56 PM Alexander Neundorf wrote: On Thursday, 5. July 2012 17:37:21 Clinton Stimpson wrote: On Friday, June 15, 2012 09:56:51 PM Alexander Neundorf wrote: Hi, attached is a small patch which sets the OBJECT_DEPENDS property of a moced file to the generated moc file. This has the effect that before the cpp file is built, moc has been run on it. We have that in KDE's version of qt4_generate_moc() this way since 2006 and it works for us. In cmake's version, it was removed January 11th 2008, the removed call to MACRO_ADD_FILE_DEPENDENCIES(): http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=510f578f8b53858fb b541c 4e7 e4731de9bfbd483 Now since we are trying to get rid of our custom stuff in KDE, we hit that issue when trying to build parts of KDE with FindQt4.cmake from cmake. Do you remember why this line was removed ? What do you think about adding it again, as the attached patch does ? Alex It was probably removed because I thought add_custom_command() already added the needed dependency information. It should already have this: mocable.h - moc_mocable.cpp - moc_mocable.o This works if the generated moc file is listed as source file for a target. In several places we did not do this, and relied instead on the OBJECT_DEPENDS. Ahh, this was in places where the moc file is generated from a cpp file, which includes the moc file. In those cases the OBJECT_DEPENDS makes it work. We fixed this in the meantime by adding the generated moc file to the source list (which is not too bad, since the developer explicitely names the moc file, so it is ok). So, I would like to have that dependency, but I'm unsure whether it might have any unwanted side effects. Ah, so for the case mocable.h - mocable.moc - mocable.cpp (includes mocable.moc) the mocable.moc is not listed in the sources of the target. I can't think of any possible unwanted side effects. I agree that we need to have this patch. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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 If somebody pushes this to 'next' today or tomorrow, I'll make sure we can get it into 2.8.9-rc2. Too late now for 2.8.9 ? Alex -- 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] Disabling C for C++-only projects
On Thursday 26 July 2012, Johannes Zarl wrote: On Wednesday 25 July 2012 22:20:55 Clinton Stimpson wrote: On Wednesday, July 25, 2012 10:06:27 PM Johannes Zarl wrote: I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after all these two projects are C++, so any platform test should IMO be using the same compiler as the build-process does? This has already been fixed in FindQt4 since CMake 2.8.6. ...using cmake 2.8.9-rc1 from debian. if you use it together with FindKDE4.cmake, you get the copy of FindQt4.cmake coming with kdelibs, which apparently does not yet have these fixes applied. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] (Almost) unused status values in the cmake bugtracker
Hi, for some reason I just checked how often the different status value are used in the CMake bug tracker: New: 262 Feedback: 11 Acknowledged: 4 Confirmed: 3 Backlog: 142 Assigned: 599 Resolved: 169 Closed: 2940 Beside that there are currently quite a few in New (262), the values Feedback, Acknowledged and Confirmed are more or less unused. Maybe they could be removed ? (I didn't check the other projects in the bug tracker) Alex -- 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] set ranlib/ar in toolchain file
On Thursday 05 July 2012, Eric Noulard wrote: ... I'm not familiar with the Fortran support of CMake but in any case I think it's worth a bug report and people knowing more than me about Fortran CMake will probable sort this out approriately. If you have a litte more time it would be nice to file this bug report refering to this ML thread. Just for reference, this is the bug report: http://public.kitware.com/Bug/view.php?id=13379 Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Paired values in an iterable data structure like map or tuple
On Friday 13 July 2012, Ateljevich, Eli wrote:
Hi,
I have a series of tests I would like to perform, some of which are serial
and some of which are mpi and should use np processors.
I would further prefer to be able to process this as a list of paired
values. The following is nothing but pseudocode, but it attempts to convey
the idea. The ability to pair attributes (either as tuples or as some sort
of map or dictionary) is something I would love to learn to emulate. Am I
missing an easy way to do this? Thanks -E
foreach(testname (test_serial_1,serial,na),
test_mpi_1,mpi,4),
test_mpi_2,mpi,2) )
maketest(${testname}[0], ${testname}[1],${testname}[2])
endforeach()
A map in C++:
std::mapstd::string, std::string m;
std::string key;
key = foo;
m[key] = CMake;
key = bar;
m[key] = Rules;
key = blub;
m[key] = !;
if (m.find(blah) == m.end())
printf(blah not found in map !);
std::string s = m[blub];
The same in CMake:
set(key foo)
set(FOO_${key} CMake)
set(key bar)
set(FOO_${key} Rules)
set(key blub)
set(FOO_${key} !)
if(FOO_blah)
message(STATUS blah not found in map !)
endif()
set(s ${FOO_blub})
A list of structs in C++
struct Foo
{
std::string s1;
std::string s2;
};
std::vectorFoo v;
Foo f;
f.s1=Alex;
f.s2 = Neundorf;
v.push_back(f);
f.s1=Bill;
f.s2 = Hoffman;
v.push_back(f);
for(std::vectorFoo::const_iterator it = v.begin(); it!=v.end(); ++it)
{
printf(s1: %s s2: %s\n, it-s1.c_str(), it-s2.c_str());
}
In CMake I can think of two ways to do this.
Once by using two lists in parallel
list(APPEND v_s1 Alex)
list(APPEND v_s2 Neundorf)
list(APPEND v_s1 Bill)
list(APPEND v_s2 Hoffman)
list(LENGTH v_s1 count)
math(EXPR count ${count}-1)
foreach(i RANGE ${count})
list(GET v_s1 ${i} s1)
list(GET v_s2 ${i} s2)
message(STATUS s1: ${s1} s2: ${s2})
endforeach()
and alternatively again using specially named variables (as for the map, but
using the index as suffix for the name), but this may be a bit ugly.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to export the user-defined variable in to the parent directory?
On Saturday 14 July 2012, 黄光成 wrote:
my directory hierarchical is : dir1/dir2/dir3.
In dir3's CMakeLists.txt, I define a custom variable named 'xxx' using the
command set(xxx yyy). I want to use the variable 'xxx' in dir1's
CMakeLists.txt, how to do that? Can export the user-defined variable?
For getting a variable one level up, using PARENT_SCOPE should work:
set(foo abc PARENT_SCOPE)
Calling this in dir3 directly in the CMakeLists.txt (i.e. not in a function)
would set foo in dir2.
Alternatively, you can set a variable globally, via two ways:
set(foo abc CACHE STRING something... FORCE)
or using a GLOBAL property:
in dir1/dir2/dir3/:
set_property(GLOBAL )
and then access it from anywhere else
get_property(GLOBAL )
I think setting a directory property should also work:
in dir1/dir2/dir3/:
set_property(DIRECTORY PROPERTY foo abc)
then accessing it should also work from everywhere I think:
get_property(myFoo DIRECTORY ${CMAKE_SOURCE_DIR}/dir1/dir2/dir3 PROPERTY foo)
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Should I create IMPORTED targets for executables?
On Saturday 14 July 2012, Stephen Kelly wrote: Hi, For Qt 5 I'm creating IMPORTED targets for all the libraries, which has several benefits. I'm not sure if there are any benefits to creating IMPORTED targets for the executables too? Yes, intended for crosscompiling. add_custom_command() and add_custom_target() support using the target name of an executable created in the project as command (instead of using the path to an executable). When crosscompiling a project, which contains code generators, you can do something like this: # somewhere at the top level: if(CMAKE_CROSSCOMPILING) # will find the exported executable targets exported and installed from a # native build of this project, which creates the imported target mycodegen find_package(MyProjectExecutables) endif() # then at the place where the code generator is built: if(NOT CMAKE_CROSSCOMPILING) add_executable(mycodegen mcg.c) endif() ... add_custom_command(... COMMAND mycodegen arg1 arg2) Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating an sdk wrapper and hiding implementation
On Wednesday 18 July 2012, Michael Toy wrote: we have a number of internally developed libraries which we use together. i am creating an sdk which wraps all the internal libraries, and presents a single api to customers. i have built a small test by hand, and it works like this % cc -c sdk_api.c % ln -r sdk_api.o libinternal1.a libinternal2.a -o sdk.o -exported_sybmols_list sdk_api_entry.txt % strip -x sdk.o % ar r libsdk.a sdk.o this creates a libsdk.a which ONLY has the api entry points exposed to customers and hides all the globals from the internal libraries. can't quite wrap my head how to express this in cmake's world of sources, libraries and targets. best i can think of is a custom target, which then depends on the internal libraries ( which are built in the same project ), and then somehow get the path names to the internal libraries to construct the link line, only i can't even figure out how to do that. anyone have a clue? we have ended up have tons of system specific target construction rules, so i don't mind if i have to write the custom target differently for different target OSes. So basically this combines several static libraries into one static library ? This is not really/kind of supported by cmake. Since 2.8.8 (I think) you can create OBJECT libraries: add_library(... OBJECT ...) which are basically only a set of object files, but can be used later on to be linked against. So you could build libinternal1.a and libinternal2.a as such OBJECT libs, and then create a library sdk which links against those two. I haven't tested this myself, but maybe it works and kind of does what you want ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disabling C for C++-only projects
On Wednesday 25 July 2012, Johannes Zarl wrote: Hi, Out of curiosity (and thinking about saving a couple of seconds during the first cmake run) I tried just to use C++ as language for some KDE program. It turns out that without C enabled, standard modules like FindKDE, FindQt4 and FindJPEG don't run because they use the CheckSymbolExists module. I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after all these two projects are C++, so any platform test should IMO be using the same compiler as the build-process does? Yes, but I'd consider it a very low severity bug. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Relink to shared libs
On Friday 20 July 2012, Andreas Naumann wrote: If you are using the Makefile system, then the libraries are newer than your tests, so your tests seems to need an update. And sometimes programs need relinking, where should the build system now, if you really need the relinking? Yes, e.g. to make sure the library still has the necessary symbols. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Easier way to override variables
On Wednesday 18 July 2012, Yngve Inntjore Levinsen wrote: Hi Romain, Have a look at the help for the function set: $ cmake --help-command set If I understand the documentation, this should be what you are looking for: set(MY_VAR NEW_VALUE FORCE) I don't think this does what you want. It sets MY_VAR to NEW_VALUE;FORCE. set() without CACHE always sets/overrides anything set before. The only time when you may need to enforce overriding is when the variable in question is a cache variable. set(MY_VAR foo CACHE STRING docs...) set(MY_VAR bar CACHE STRING docs...) will leave MY_VAR at foo, since setting a value in the cache only actually sets its value if it is not yet in the cache. To set it anyway, you have to use FORCE: set(MY_VAR foo CACHE STRING docs...) set(MY_VAR bar CACHE STRING docs... FORCE) Using CACHE and non-CACHE variables with the same name may result in not quite obvious behaviour. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Two toolchains simultaneously within the same project?
On Thursday 12 July 2012, Ingolf Steinbach wrote: Hi, is it possible to use two different toolchains within the same project? This is what I want to achieve: In general not. Most of the project uses a cross-compilation toolchain, so I'd call cmake with the appropriate CMAKE_TOOLCHAIN_FILE settings for the cross compiler. There is however one subdirectory which contains tools to be used on the host machine. I'd like to keep this subdirectory within the project (as these tools directly belong to the project) but would like cmake to use the native compiler instead -- ideally without having to explicitly call cmake again in that subdirectory. Maybe you can use external_project() for that subdirectory ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake + Eclipse on OS X : OpenGL and GLUT headers
On Sunday 01 July 2012, Nicholas Yue wrote: Hi, I am using CMake 2.8.8 I have been generating Eclipse project and building my software successfully both on the command line and within Eclipse. However, when I open up my project in Eclipse, the indexer fails to find the necessary headers for OpenGL and GLUT Moreover, I noticed the following via ccmake GLUT_INCLUDE_DIR /System/Library/Frameworks/GLUT.framework/Headers OPENGL_INCLUDE_DIR /System/Library/Frameworks/OpenGL.framework Note the differences in the directory Headers Is there additional steps for the OS X platform so that code completion and C++ indexer works properly when using OpenGL and GLUT on OS X when generating Eclipse project files via CMake. Just for reference, a ticket has been created for this: http://public.kitware.com/Bug/view.php?id=13367 Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Use OBJECT_DEPENDS in qt4_generate_moc() ?
On Thursday, 5. July 2012 17:37:21 Clinton Stimpson wrote: On Friday, June 15, 2012 09:56:51 PM Alexander Neundorf wrote: Hi, attached is a small patch which sets the OBJECT_DEPENDS property of a moced file to the generated moc file. This has the effect that before the cpp file is built, moc has been run on it. We have that in KDE's version of qt4_generate_moc() this way since 2006 and it works for us. In cmake's version, it was removed January 11th 2008, the removed call to MACRO_ADD_FILE_DEPENDENCIES(): http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=510f578f8b53858fbb541c 4e7 e4731de9bfbd483 Now since we are trying to get rid of our custom stuff in KDE, we hit that issue when trying to build parts of KDE with FindQt4.cmake from cmake. Do you remember why this line was removed ? What do you think about adding it again, as the attached patch does ? Alex It was probably removed because I thought add_custom_command() already added the needed dependency information. It should already have this: mocable.h - moc_mocable.cpp - moc_mocable.o This works if the generated moc file is listed as source file for a target. In several places we did not do this, and relied instead on the OBJECT_DEPENDS. Ahh, this was in places where the moc file is generated from a cpp file, which includes the moc file. In those cases the OBJECT_DEPENDS makes it work. We fixed this in the meantime by adding the generated moc file to the source list (which is not too bad, since the developer explicitely names the moc file, so it is ok). So, I would like to have that dependency, but I'm unsure whether it might have any unwanted side effects. Alex P.S. I'll be offline for the following two weeks -- 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-commits] CMake branch, next, updated. v2.8.8-3333-gd83c8d1
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 d83c8d16b7b2cceadc9e031283ffae9244e48fa4 (commit)
via d7bc8dd6ea5fcecf613134764a040238cb115b4c (commit)
from 92aadd68345a3aa3df5a480465c4e28aca8d4a59 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d83c8d16b7b2cceadc9e031283ffae9244e48fa4
commit d83c8d16b7b2cceadc9e031283ffae9244e48fa4
Merge: 92aadd6 d7bc8dd
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed Jun 27 17:41:46 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jun 27 17:41:46 2012 -0400
Merge topic 'EclipseFixIncludeDirDetectionMinGW' into next
d7bc8dd Eclipse: fix #13313, always set LANG to C, also if unset
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7bc8dd6ea5fcecf613134764a040238cb115b4c
commit d7bc8dd6ea5fcecf613134764a040238cb115b4c
Author: Alex Neundorf neund...@kde.org
AuthorDate: Mon Jun 25 23:09:27 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Mon Jun 25 23:09:27 2012 +0200
Eclipse: fix #13313, always set LANG to C, also if unset
Otherwise include dir detection does not work with MinGW on french systems.
Alex
diff --git
a/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
b/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
index 1b4532d..455f95f 100644
--- a/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
+++ b/Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake
@@ -80,15 +80,10 @@ ENDMACRO(_DETERMINE_GCC_SYSTEM_INCLUDE_DIRS _lang)
SET(_orig_lc_all $ENV{LC_ALL})
SET(_orig_lc_messages $ENV{LC_MESSAGES})
SET(_orig_lang$ENV{LANG})
-IF(_orig_lc_all)
- SET(ENV{LC_ALL} C)
-ENDIF()
-IF(_orig_lc_messages)
- SET(ENV{LC_MESSAGES} C)
-ENDIF()
-IF(_orig_lang)
- SET(ENV{LANG}C)
-ENDIF()
+
+SET(ENV{LC_ALL} C)
+SET(ENV{LC_MESSAGES} C)
+SET(ENV{LANG}C)
# Now check for C, works for gcc and Intel compiler at least
IF (NOT CMAKE_EXTRA_GENERATOR_C_SYSTEM_INCLUDE_DIRS)
@@ -109,12 +104,6 @@ IF (NOT CMAKE_EXTRA_GENERATOR_CXX_SYSTEM_INCLUDE_DIRS)
ENDIF ()
# Restore original LC_ALL, LC_MESSAGES, and LANG
-IF(_orig_lc_all)
- SET(ENV{LC_ALL} ${_orig_lc_all})
-ENDIF()
-IF(_orig_lc_messages)
- SET(ENV{LC_MESSAGES} ${_orig_lc_messages})
-ENDIF()
-IF(_orig_lang)
- SET(ENV{LANG}${_orig_lang})
-ENDIF()
+SET(ENV{LC_ALL} ${_orig_lc_all})
+SET(ENV{LC_MESSAGES} ${_orig_lc_messages})
+SET(ENV{LANG}${_orig_lang})
---
Summary of changes:
...atorDetermineCompilerMacrosAndIncludeDirs.cmake | 25 +--
1 files changed, 7 insertions(+), 18 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [CMake] Can imported libraries depend on ExternalProject targets?
On Tuesday 26 June 2012, Kent Williams wrote: I meant to say 'the approach you use doesn't work, because imported libraries are targets to are targets to which you CANNOT add dependencies. This should work since I think cmake 2.8.4. http://public.kitware.com/Bug/view.php?id=10395 Or am I misunderstanding what you said ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] new Generator
Hi, On Thursday 21 June 2012, J Decker wrote: Is tehre anywhere that I can find a howto of how to approach creating a new genreator? basically, read the sources. For what IDE or build tool would you like to write one ? Alex -- 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] Can imported libraries depend on ExternalProject targets?
On Saturday 23 June 2012, Stefan Reuschl wrote: Am 22.06.2012, 20:21 Uhr, schrieb Kent Williams nkwmailingli...@gmail.com: OK, I guess. The only reason I bring this up is ITK. If you're familiar with the ITK build process, it has a 'module' concept -- not a module in the CMake sense (where it is a library intended for runtime loading), but in the sense that the build process is modular. Each of the ITK libraries is a module, which is defined by a standardised directory layout and cmake files. I made an Module for DCMTK that satisfies the requirements of an ITK module -- it builds DCMTK as an External Project, and uses add_library(name lib-type IMPORTED) on each of the libraries DCMTK creates, and connects the imported library with the actual library file in the file system. This all works fine EXCEPT for this one conundrum, you can't have the imported libraries depend on the ExternalProject target, so if you want to make sure the ExternalProject gets built before the targets that try to link to them, you have to make the executable (or library) target depend on the ExternalProject target to serialize the build of the dependee before the depnder. The following once worked fine for me using CMake 2.8.8: ExternalProject_Add( ep ) add_library( epLib IMPORTED ) set_target_properties( epLib PROPERTIES IMPORTED_LOCATION ... ) add_dependencies( epLib ep ) Yes, that's what I use too, and it works fine for me, at least if you know what you are doing. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.8-3308-g6d52cb8
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 6d52cb8f6ad489c777db89edb9b517521bb1f6cb (commit)
via 20e133e38aa2e0556da61b1441fbd4bcacc925cc (commit)
via 38df155dd394efd45dff887028b2e1a4c0969b03 (commit)
via e6a935f39b2d15677830fdba8090d8c725165ca9 (commit)
from 61b157fb73046d4015e7800639ecafbeec623c4b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d52cb8f6ad489c777db89edb9b517521bb1f6cb
commit 6d52cb8f6ad489c777db89edb9b517521bb1f6cb
Merge: 61b157f 20e133e
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Jun 21 17:22:33 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jun 21 17:22:33 2012 -0400
Merge topic 'DetectManSection' into next
20e133e man documentation: detect man section from the given filename
38df155 documentation: preparation for making the man section configurable
e6a935f -remove trailing whitespace
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20e133e38aa2e0556da61b1441fbd4bcacc925cc
commit 20e133e38aa2e0556da61b1441fbd4bcacc925cc
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Jun 21 23:19:55 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Jun 21 23:19:55 2012 +0200
man documentation: detect man section from the given filename
E.g. if you say cmake --help-custom-modules mymodules.7
cmake will now put section 7 into the generated manpage.
Alex
diff --git a/Source/cmDocumentation.cxx b/Source/cmDocumentation.cxx
index 0f44e19..1b042ae 100644
--- a/Source/cmDocumentation.cxx
+++ b/Source/cmDocumentation.cxx
@@ -642,7 +642,8 @@ bool
cmDocumentation::PrintRequestedDocumentation(std::ostream os)
cmDocumentation::Form cmDocumentation::GetFormFromFilename(
- const std::string filename)
+ const std::string filename,
+ int* manSection)
{
std::string ext = cmSystemTools::GetFilenameLastExtension(filename);
ext = cmSystemTools::UpperCase(ext);
@@ -659,6 +660,10 @@ cmDocumentation::Form cmDocumentation::GetFormFromFilename(
// .1 to .9 should be manpages
if ((ext.length()==2) (ext[1] ='1') (ext[1]='9'))
{
+if (manSection)
+ {
+ *manSection = ext[1] - '0';
+ }
return cmDocumentation::ManForm;
}
@@ -1128,49 +1133,57 @@ bool cmDocumentation::CheckOptions(int argc, const
char* const* argv,
{
help.HelpType = cmDocumentation::Properties;
GET_OPT_ARGUMENT(help.Filename);
- help.HelpForm = this-GetFormFromFilename(help.Filename);
+ help.HelpForm = this-GetFormFromFilename(help.Filename,
+help.ManSection);
}
else if(strcmp(argv[i], --help-policies) == 0)
{
help.HelpType = cmDocumentation::Policies;
GET_OPT_ARGUMENT(help.Filename);
- help.HelpForm = this-GetFormFromFilename(help.Filename);
+ help.HelpForm = this-GetFormFromFilename(help.Filename,
+help.ManSection);
}
else if(strcmp(argv[i], --help-variables) == 0)
{
help.HelpType = cmDocumentation::Variables;
GET_OPT_ARGUMENT(help.Filename);
- help.HelpForm = this-GetFormFromFilename(help.Filename);
+ help.HelpForm = this-GetFormFromFilename(help.Filename,
+help.ManSection);
}
else if(strcmp(argv[i], --help-modules) == 0)
{
help.HelpType = cmDocumentation::Modules;
GET_OPT_ARGUMENT(help.Filename);
- help.HelpForm = this-GetFormFromFilename(help.Filename);
+ help.HelpForm = this-GetFormFromFilename(help.Filename,
+help.ManSection);
}
else if(strcmp(argv[i], --help-custom-modules) == 0)
{
help.HelpType = cmDocumentation::CustomModules;
GET_OPT_ARGUMENT(help.Filename);
- help.HelpForm = this-GetFormFromFilename(help.Filename);
+ help.HelpForm = this-GetFormFromFilename(help.Filename,
+help.ManSection);
}
else if(strcmp(argv[i], --help-commands) == 0)
{
help.HelpType = cmDocumentation::Commands;
GET_OPT_ARGUMENT(help.Filename);
- help.HelpForm = this-GetFormFromFilename(help.Filename);
+ help.HelpForm = this-GetFormFromFilename(help.Filename,
+help.ManSection
Re: [cmake-developers] target_automoc targets in VS2010 projects
On Wednesday 20 June 2012, Thomas Sondergaard wrote: Is it possible to hide the target_automoc targets when using the VS2010 generator? If it is not possible, it would be very useful if they could be put in a folder, ie set_property(GLOBAL PROPERTY USE_FOLDERS ON) set_property(GLOBAL PROPERTY AUTOMOC_FOLDER automoc) We tried putting the generated target_automoc targets in VS2010 folders manually like shown below, but it doesn't work. I don't have any Windows around. But if you can come up with a way how to do it, I can implement it. Alex -- 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] Generating Eclipse project failed ( MacOS + Eclipse CDT 3.7 + vtk )
On Wednesday 20 June 2012, Jana Sefcikova wrote: Dear users, I am new in CMake and I followed tutorial http://www.vtk.org/Wiki/Eclipse_CDT4_Generator , downloaded latest c++ Eclipse , my cmake version is 2.8.7 I obtained following warning/error ? during cmake configuration of my project : -- Could not determine Eclipse version, assuming at least 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this is wrong. So I used cmake-gui to present manually version to 3.7 and run configuration again. I got exactly same message. This is just a warning, not an error. The files should be generated nevertheless. Tutorial states that eclipse projects .project and .cproject should be generated but they are not generated. Sorry for a stupid question: .project and .cproject are hidden files. They are really not there ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Not in next branches on the CMake stage...
On Tuesday 19 June 2012, David Cole wrote: On Tue, Jun 19, 2012 at 2:04 PM, Rolf Eike Beer e...@sf-mail.de wrote: On Di., 19. Jun. 2012 19:53:39 CEST, David Cole david.c...@kitware.com wrote: Alex and Eike, The following topic branches have been on the CMake stage for months, without any movement. Are there further plans to move these topics forward and get them into 'next' or are they simply abandoned at this point...? Shouldn't there be a list here? Eike Uh, why yes, of course. Perhaps since it's after lunch now, I should consider pouring myself a second cup of coffee for the day. (A call to 'ssh g...@cmake.org stage cmake print' shows next=0 for those branches not in 'next' at any given moment) # Not in 'next': ... # NinjaEclipse | master=0 next=0 At some point I want to get this working. I'm actually not convinced I'll continue on what I have there, or whether to start fresh. If it's a problem for you, feel free to remove it. Alex -- 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] Faster automoc with parallel processing?
On Tuesday 19 June 2012, Thomas Sondergaard wrote: Hi Alexander, Thanks for replying. On 2012-06-18 21:58, Alexander Neundorf wrote: On Sunday 17 June 2012, Thomas Sondergaard wrote: On Windows with MSVC 2010 Generator, moc seems to be very slow and it is a paint to see it run sequentially. Could automoc be taught to do this in parallel using all the cores on the machine? is certainly good enough as an answer ? ;-) It's a good start :-) The thing is, for each target there is an accompanying automoc target. So if you have 4 cores, and 4 targets are built in parallel, then also 4 (auto)mocs should be running in parallel. If you have only 1 target, consisting of many files, only 1 automoc target will be executed, processing one moc after the other. Interesting. I haven't actually fully switched to automoc, I have only tested it on one target in a project with +50 targets. Perhaps the situation will look better if I automoc everything. Parallelizing this is not obvious. Simply running as many mocs on a machine as it has cores might lead to 16 mocs running on 4 cores (for 4 different targets). I think overparallization is better than underparallization. I don't think running 16 parallel mocs at a time on a 4 core machine should be dramatically slower than running 4. An experiment could show. Considering a 8 or 16 core machine, this could give already 256 mocs running on 16 cores. I think this would then really be a bit much. I'd actually have to check first whether most of the time is spent in executing moc, or in parsing the files for stuff to be moc'ed. Also the parsing can still be optimized by caching results from earlier runs (which it doesn't do right now). For executing moc, this could also be limited to some number, like 2 or 4, which should already bring a lot. Anyway, currently executing moc is very simple, it's a system-style call, i.e. it starts the executable and blocks until the process has exited. Making this non-blocking is a bit of work. So, it is possible, it is some implementation work, and I'm not clear on how to do the logic. Do you have some ideas how to do this in a good way ? automoc could start a background process and use that to handle all moc'ing. The process could stop after a few seconds of inactivity. That way moc would never use more than the number of cores in the machine, but it might overlap with other build activity. It doesn't seem sensible that automoc should only be concerned about overutilization from other mocs. Perhaps the best way is simply to look at the load-average, like make --load-average? This must be cross-platform, i.e. work on Windows, OSX, Linux, *BSD, AIX, etc. This would be quite an effort I think. Alex -- 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] Faster automoc with parallel processing?
On Sunday 17 June 2012, Thomas Sondergaard wrote: Hi, I've tested the new automoc feature and it certainly makes the developers life simpler and the CMakeLists.txt a lot simpler. Thanks for that, it is a great improvement. On Windows with MSVC 2010 Generator, moc seems to be very slow and it is a paint to see it run sequentially. Could automoc be taught to do this in parallel using all the cores on the machine? is certainly good enough as an answer ? ;-) The thing is, for each target there is an accompanying automoc target. So if you have 4 cores, and 4 targets are built in parallel, then also 4 (auto)mocs should be running in parallel. If you have only 1 target, consisting of many files, only 1 automoc target will be executed, processing one moc after the other. Parallelizing this is not obvious. Simply running as many mocs on a machine as it has cores might lead to 16 mocs running on 4 cores (for 4 different targets). So, it is possible, it is some implementation work, and I'm not clear on how to do the logic. Do you have some ideas how to do this in a good way ? Alex -- 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] cmake as pkg-config replacement has problems?
On Saturday 16 June 2012, Hendrik Sattler wrote: Hi, I try the following commands with my projects config file. It is not installed but the build tree is registered with export(TARGET). $ cmake -DNAME=OpenObex -DCOMPILER_ID=GNU -DLANGUAGE=C -DMODE=COMPILE --find-package -I/home/hendrik/projects/obex/openobex/repository/include $ cmake -DNAME=OpenObex -DCOMPILER_ID=GNU -DLANGUAGE=C -DMODE=LINK --find-package -rdynamic lib/libopenobex.so.1.6 -Wl,-rpath,/home/hendrik/projects/obex/openobex/repository/build/lib I think the latter is missing the complete path to the library or alternatively a -L entry. Am I doing something wrong or is this a cmake bug. This may be. I consider this feature still experimental, it needs users (like you) to actually figure out whether it is real-world useful. Can you open a ticket for this please in the tracker ? Thanks Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] Use OBJECT_DEPENDS in qt4_generate_moc() ?
Hi,
attached is a small patch which sets the OBJECT_DEPENDS property of a moced
file to the generated moc file.
This has the effect that before the cpp file is built, moc has been run on it.
We have that in KDE's version of qt4_generate_moc() this way since 2006 and it
works for us.
In cmake's version, it was removed January 11th 2008, the removed call to
MACRO_ADD_FILE_DEPENDENCIES():
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=510f578f8b53858fbb541c4e7e4731de9bfbd483
Now since we are trying to get rid of our custom stuff in KDE, we hit that
issue when trying to build parts of KDE with FindQt4.cmake from cmake.
Do you remember why this line was removed ?
What do you think about adding it again, as the attached patch does ?
Alex
--- Qt4Macros.cmake.orig 2012-06-15 21:39:23.0 +0200
+++ Qt4Macros.cmake 2012-06-15 21:36:00.0 +0200
@@ -133,6 +133,7 @@ MACRO (QT4_GENERATE_MOC infile outfile )
ENDIF(NOT IS_ABSOLUTE ${outfile})
QT4_CREATE_MOC_COMMAND(${abs_infile} ${_outfile} ${moc_flags} )
SET_SOURCE_FILES_PROPERTIES(${outfile} PROPERTIES SKIP_AUTOMOC TRUE) # dont run automoc on this file
+ SET_PROPERTY(SOURCE ${abs_infile} APPEND PROPERTY OBJECT_DEPENDS ${_outfile} )
ENDMACRO (QT4_GENERATE_MOC)
--
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] Recommended usage of OBJECT_DEPENDS
Hi, we hit an issue in KDE related to the usage (or not-usage) of the OBJECT_DEPENDS source file property. In KDEs FindQt4.cmake the macro qt4_generate_moc(inCppFile outMocFile) uses the OBJECT_DEPENDS property to enforce that the moc file is generated before the cpp file is built. This seems to work reliably, at least I haven't heard of any problems with this since years. Now the same macro in cmake does not set the OBJECT_DEPENDS property. Should it ? Is enforcing such a dependency a valid use case for OBJECT_DEPENDS ? Alex -- 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-commits] CMake branch, next, updated. v2.8.8-3173-g7343e73
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 7343e73937f37dda1de42d84b247f528dfca75b3 (commit)
via e4a2d5f9eeca03470192f0f0b4e3bc16ef33e084 (commit)
via 7717d964b86f86e001641d1afea84c327e336ee7 (commit)
from a885c0574474456fd1b1ef93d2bfd3b33176470f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7343e73937f37dda1de42d84b247f528dfca75b3
commit 7343e73937f37dda1de42d84b247f528dfca75b3
Merge: a885c05 e4a2d5f
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Thu Jun 14 16:29:39 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jun 14 16:29:39 2012 -0400
Merge topic 'FailIfMocFails-13299' into next
e4a2d5f automoc: better error handling (#13299)
7717d96 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4a2d5f9eeca03470192f0f0b4e3bc16ef33e084
commit e4a2d5f9eeca03470192f0f0b4e3bc16ef33e084
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Jun 14 22:27:22 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Jun 14 22:27:22 2012 +0200
automoc: better error handling (#13299)
automoc now fails immediately if moc fails, instead of continuing
and letting the build fail later on.
Alex
diff --git a/Source/cmQtAutomoc.cxx b/Source/cmQtAutomoc.cxx
index 113d678..65ecdf7 100644
--- a/Source/cmQtAutomoc.cxx
+++ b/Source/cmQtAutomoc.cxx
@@ -245,6 +245,7 @@ void cmQtAutomoc::SetupAutomocTarget(cmTarget* target)
bool cmQtAutomoc::Run(const char* targetDirectory)
{
+ bool success = true;
cmake cm;
cmGlobalGenerator* gg = this-CreateGlobalGenerator(cm, targetDirectory);
cmMakefile* makefile = gg-GetCurrentLocalGenerator()-GetMakefile();
@@ -256,7 +257,7 @@ bool cmQtAutomoc::Run(const char* targetDirectory)
if (this-QtMajorVersion == 4 || this-QtMajorVersion == 5)
{
-this-RunAutomoc();
+success = this-RunAutomoc();
}
this-WriteOldMocDefinitionsFile(targetDirectory);
@@ -264,7 +265,7 @@ bool cmQtAutomoc::Run(const char* targetDirectory)
delete gg;
gg = NULL;
makefile = NULL;
- return true;
+ return success;
}
@@ -578,7 +579,7 @@ bool cmQtAutomoc::RunAutomoc()
if (this-RunMocFailed)
{
-std::cerr returning failed.. std::endl;
+std::cerr moc failed... std::endl;
return false;
}
outStream.flush();
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 242..451aec8 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -1699,8 +1699,8 @@ int cmake::ExecuteCMakeCommand(std::vectorstd::string
args)
else if (args[1] == cmake_automoc)
{
cmQtAutomoc automoc;
-automoc.Run(args[2].c_str());
-return 0;
+bool automocSuccess = automoc.Run(args[2].c_str());
+return automocSuccess ? 0 : 1;
}
#endif
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
Source/cmQtAutomoc.cxx|7 ---
Source/cmake.cxx |4 ++--
3 files changed, 7 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.8-3147-g9c05d34
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 9c05d34c5ca8927250d0c783981549cbf33e0795 (commit)
via 414bf6732bf504d200b5c00490f160271e5b1b50 (commit)
from fbfed8156e43f5897a08b2b3a3fb6fdffb9e9dca (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c05d34c5ca8927250d0c783981549cbf33e0795
commit 9c05d34c5ca8927250d0c783981549cbf33e0795
Merge: fbfed81 414bf67
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed Jun 13 16:51:59 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jun 13 16:51:59 2012 -0400
Merge topic 'EclipseParallelMakeForBuildProject' into next
414bf67 Eclipse: parallel build also for Build project #13287
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=414bf6732bf504d200b5c00490f160271e5b1b50
commit 414bf6732bf504d200b5c00490f160271e5b1b50
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed Jun 13 22:49:45 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed Jun 13 22:49:45 2012 +0200
Eclipse: parallel build also for Build project #13287
Use ${CMAKE_ECLIPSE_MAKE_ARGUMENTS} also for the overall build command,
not only for the per-target commands.
Alex
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx
b/Source/cmExtraEclipseCDT4Generator.cxx
index 65077b3..dc9eb6a 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -286,6 +286,9 @@ void cmExtraEclipseCDT4Generator::CreateProjectFile()
// set the make command
std::string make = mf-GetRequiredDefinition(CMAKE_MAKE_PROGRAM);
+ const std::string makeArgs = mf-GetSafeDefinition(
+ CMAKE_ECLIPSE_MAKE_ARGUMENTS);
+
fout
\t\t\t\tdictionary\n
\t\t\t\t\tkeyorg.eclipse.cdt.make.core.enabledIncrementalBuild/key\n
@@ -293,7 +296,7 @@ void cmExtraEclipseCDT4Generator::CreateProjectFile()
\t\t\t\t/dictionary\n
\t\t\t\tdictionary\n
\t\t\t\t\tkeyorg.eclipse.cdt.make.core.build.command/key\n
-\t\t\t\t\tvalue + this-GetEclipsePath(make) + /value\n
+\t\t\t\t\tvalue this-GetEclipsePath(make) /value\n
\t\t\t\t/dictionary\n
\t\t\t\tdictionary\n
\t\t\t\t\tkeyorg.eclipse.cdt.make.core.contents/key\n
@@ -305,7 +308,7 @@ void cmExtraEclipseCDT4Generator::CreateProjectFile()
\t\t\t\t/dictionary\n
\t\t\t\tdictionary\n
\t\t\t\t\tkeyorg.eclipse.cdt.make.core.build.arguments/key\n
-\t\t\t\t\tvalue/value\n
+\t\t\t\t\tvalue makeArgs /value\n
\t\t\t\t/dictionary\n
\t\t\t\tdictionary\n
\t\t\t\t\tkeyorg.eclipse.cdt.make.core.buildLocation/key\n
---
Summary of changes:
Source/cmExtraEclipseCDT4Generator.cxx |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.8-3136-g9267a6a
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 9267a6a1cdeea5b8847c903e114334280d6bb90c (commit)
via 0b343cb71e00871591af28452fff8a577ce27a65 (commit)
from 77f471b8405f93d8f56c4b5f4e31642d9f49 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9267a6a1cdeea5b8847c903e114334280d6bb90c
commit 9267a6a1cdeea5b8847c903e114334280d6bb90c
Merge: 77f471b 0b343cb
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Tue Jun 12 16:29:14 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jun 12 16:29:14 2012 -0400
Merge topic 'RemoveASMDebugOutput' into next
0b343cb ASM compiler detection: remove debug output (#13270)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b343cb71e00871591af28452fff8a577ce27a65
commit 0b343cb71e00871591af28452fff8a577ce27a65
Author: Alex Neundorf neund...@kde.org
AuthorDate: Tue Jun 12 22:27:34 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Tue Jun 12 22:27:34 2012 +0200
ASM compiler detection: remove debug output (#13270)
This must have been left in accidentially.
Alex
diff --git a/Modules/CMakeDetermineCompilerId.cmake
b/Modules/CMakeDetermineCompilerId.cmake
index 686cc9b..67f5a59 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -302,12 +302,6 @@ FUNCTION(CMAKE_DETERMINE_COMPILER_ID_VENDOR lang)
TIMEOUT 10
)
-IF(${lang} STREQUAL ASM)
- MESSAGE(STATUS Checked for ${vendor})
- MESSAGE(STATUSOutput: -${output}-)
- MESSAGE(STATUSResult: -${result}-)
-ENDIF(${lang} STREQUAL ASM)
-
IF(${output} MATCHES ${regex})
FILE(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
Checking whether the ${lang} compiler is ${vendor} using \${flags}\
---
Summary of changes:
Modules/CMakeDetermineCompilerId.cmake |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] Welcome to June, time for the next release candidate
On Monday, June 04, 2012 11:58:19 PM Stephen Kelly wrote: David Cole wrote: We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? I'd very much like the POSITION_INDEPENDENT_CODE topic to be part of it. (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Yury did some work on export-sets: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7257/focus=7274 But I don't think it's 'done' enough for inclusion yet unfortunately. The existing tests pass, but new ones are needed. Hopefully we can get it ready early in the next cycle. That's really a pity. It's kind of a blocker for the splitted kdelibs :-/ Alex -- 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] Selectively adding source files and compiling assembly sources
On Monday 28 May 2012, Petr Kmoch wrote:
Hi Johannes,
the only solution I can think of is something like:
#
option(WITH_A ...)
option(WITH_B ...)
set(MySources always/present/files ...)
if(WITH_A)
list(APPEND MySources files/for/a ...)
endif()
if(WITH_B)
list(APPEND MySources files/for/b ...)
endif()
add_executable(MyExec ${MySources})
Yes, that's the way t do it.
I have never used assembler files, so I can't comment there,
Did you enable the ASM language ?
and I don't think there's an option for better GUI grouping than string
prefixes.
Yes, they are grouped by prefixes in their name.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] a cmake install question
On Monday 28 May 2012, luxInteg wrote: Greetings, A cmake install question:- When installing say an unknown package (one where only installation prefix is described) appart from such $CMAKE_INSTALL_DIRECTORY (or prefix), are there 'generic' swithes to fix other directories such as --sysconfdir (normally /etc) --mandir (usually /usr/share/man) and -- localstatedir (usually /var) ? Or does one have to make these settings either on the command line or in the package; and in any case how so? In general, except CMAKE_INSTALL_PREFIX, providing such switches is up to each individual package. Since verrsion 2.8.5 cmake ships with a GNUInstallDirs.cmake, which provides a set of install location variables: http://www.cmake.org/cmake/help/v2.8.5/cmake.html#module:GNUInstallDirs So if a package uses this, those are the variables which can be set. Any KDE package using cmake uses a standard set of variables, which can all be set via -D or cmake-gui: http://api.kde.org/cmake/modules.html#module_FindKDE4Internal LIB_INSTALL_DIR, BIN_INSTALL_DIR etc. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Making the default install component name configurable
On Tuesday 22 May 2012, Alexander Neundorf wrote: On Monday 14 May 2012, Alexander Neundorf wrote: On Monday 14 May 2012, Brad King wrote: On 5/13/2012 2:15 PM, Alexander Neundorf wrote: the CMAKE_DEFAULT_INSTALL_COMPONENT_NAME variable is still in Unspecified, so this is still the default. I'd rather the name be CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to keep the CMAKE_INSTALL_ prefix for variables affecting installation (along with CMAKE_INSTALL_PREFIX). Done, updated branch pushed. I've merged it into next now. Could this failure be caused by my commit ? http://open.cdash.org/testDetails.php?test=147001711build=2299302 The default behaviour should not have changed. Alex -- 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] Need to prepend compiler with static analysis tool
On Wednesday 23 May 2012, jrosensw wrote: Hey all, I'm trying to integrate insure++ with my cmake workspace. The way insure works is that you prepend the compiler with the insure executable. For example /usr/bin/insure /usr/bin/g++ -o test test.cpp. I've tried to overrid CMAKE_CXX_COMPILER with these two executables, but it doesn't seem like CMAKE likes this way. I've also tried overriding CXX before running cmake with this. Can someone please tell me how to make this work? Seems like it should be simple enough, but I'm not finding the answer :-). Something like the following shoduld work: $ CXX=/usr/bin/insure /usr/bin/g++ cmake .. (on a fresh build tree) Alex -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.8-2922-g5cd83e8
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 5cd83e87123fce024b449d01d7e40f6742e5b5d4 (commit)
via 14b213c0ceb9fb2882dc41574ebacaf0ef906fc1 (commit)
via 00ae36fdfffe39fb71cb54f81990b44be81d6833 (commit)
from 8ee9ec40bb9d5dab474dbd4daa158da55ffd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cd83e87123fce024b449d01d7e40f6742e5b5d4
commit 5cd83e87123fce024b449d01d7e40f6742e5b5d4
Merge: 8ee9ec4 14b213c
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Wed May 23 14:51:01 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed May 23 14:51:01 2012 -0400
Merge topic 'HandleEmptySIZEOF_VOID_P' into next
14b213c add test for #13241: empty SIZEOF_VOIDP in
write_basic_package_version_file
00ae36f write_basic_package_version_file() now works with unset
CMAKE_SIZEOF_VOID_P
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14b213c0ceb9fb2882dc41574ebacaf0ef906fc1
commit 14b213c0ceb9fb2882dc41574ebacaf0ef906fc1
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed May 23 20:48:47 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed May 23 20:48:47 2012 +0200
add test for #13241: empty SIZEOF_VOIDP in write_basic_package_version_file
Alex
diff --git a/Tests/FindPackageTest/CMakeLists.txt
b/Tests/FindPackageTest/CMakeLists.txt
index 5862094..e85fb4d 100644
--- a/Tests/FindPackageTest/CMakeLists.txt
+++ b/Tests/FindPackageTest/CMakeLists.txt
@@ -363,10 +363,16 @@ endif()
#-
# Test write_basic_config_version_file().
+# also test that an empty CMAKE_SIZEOF_VOID_P is accepted:
+set(_CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P})
+set(CMAKE_SIZEOF_VOID_P )
+
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/Foo123ConfigVersion.cmake
VERSION 1.2.3
COMPATIBILITY AnyNewerVersion)
+set(CMAKE_SIZEOF_VOID_P ${_CMAKE_SIZEOF_VOID_P})
+
set(PACKAGE_FIND_VERSION 2.3.4)
include(${CMAKE_CURRENT_BINARY_DIR}/Foo123ConfigVersion.cmake)
if(PACKAGE_VERSION_COMPATIBLE)
@@ -379,6 +385,10 @@ if(NOT PACKAGE_VERSION_COMPATIBLE)
message(SEND_ERROR Did not find Foo123 with version 1.2.3 (0.0.1 was
requested) !)
endif()
+if(PACKAGE_VERSION_UNSUITABLE)
+ message(SEND_ERROR PACKAGE_VERSION_UNSUITABLE set, but must not be !)
+endif()
+
set(PACKAGE_FIND_VERSION 1.0.0)
include(${CMAKE_CURRENT_BINARY_DIR}/Foo123ConfigVersion.cmake)
if(NOT PACKAGE_VERSION_COMPATIBLE)
@@ -405,6 +415,7 @@
write_basic_config_version_file(${CMAKE_CURRENT_BINARY_DIR}/Boo123ConfigVersion.
VERSION 1.2.3
COMPATIBILITY SameMajorVersion)
+unset(PACKAGE_VERSION_UNSUITABLE)
set(PACKAGE_VERSION_EXACT FALSE)
set(PACKAGE_FIND_VERSION 2.3.4)
set(PACKAGE_FIND_VERSION_MAJOR 2)
@@ -456,6 +467,7 @@
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/Bar123ConfigVersion
VERSION 1.2.3.17
COMPATIBILITY ExactVersion)
+unset(PACKAGE_VERSION_UNSUITABLE)
set(PACKAGE_VERSION_EXACT FALSE)
set(PACKAGE_FIND_VERSION 2.3.4)
include(${CMAKE_CURRENT_BINARY_DIR}/Bar123ConfigVersion.cmake)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00ae36fdfffe39fb71cb54f81990b44be81d6833
commit 00ae36fdfffe39fb71cb54f81990b44be81d6833
Author: Alex Neundorf neund...@kde.org
AuthorDate: Wed May 23 20:46:48 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Wed May 23 20:46:48 2012 +0200
write_basic_package_version_file() now works with unset CMAKE_SIZEOF_VOID_P
This fixes #13241.
If CMAKE_SIZEOF_VOID_P is not set, either in the installed or in the
using project, don't check for it.
Alex
diff --git a/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
b/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
index cf53db8..9f7f03e 100644
--- a/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
+++ b/Modules/BasicConfigVersion-AnyNewerVersion.cmake.in
@@ -18,6 +18,11 @@ else()
endif()
endif()
+# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set,
ignore it:
+if(${CMAKE_SIZEOF_VOID_P} STREQUAL OR @CMAKE_SIZEOF_VOID_P@ STREQUAL
)
+ return()
+endif()
+
# check that the installed version has the same 32/64bit-ness as the one which
is currently searching:
if(NOT ${CMAKE_SIZEOF_VOID_P} STREQUAL @CMAKE_SIZEOF_VOID_P@)
math(EXPR installedBits @CMAKE_SIZEOF_VOID_P@ * 8)
diff --git a/Modules
[Cmake-commits] CMake branch, next, updated. v2.8.8-2917-g683f838
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 683f838337494cb13eafa5867ef46929efb1a5d5 (commit)
via b71e731b9b91f9f79ab49838baae5bb5ab42c30e (commit)
via 7ced0732e875ab7cf4797ef33bd4b897bc41eb53 (commit)
via b6fba35411053e334072a1203493140c67f3d30a (commit)
from e5f6155bc0cc474f679d1db33734216e7e3a1584 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=683f838337494cb13eafa5867ef46929efb1a5d5
commit 683f838337494cb13eafa5867ef46929efb1a5d5
Merge: e5f6155 b71e731
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Tue May 22 16:41:25 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue May 22 16:41:25 2012 -0400
Merge topic 'MakeDefaultInstallComponentNameConfigurable' into next
b71e731 -add docs for ${CMAKE_INSTALL_DEFAULT_COMPONENT_NAME}
7ced073 make default install component name configurable
b6fba35 -strip trailing whitespace
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b71e731b9b91f9f79ab49838baae5bb5ab42c30e
commit b71e731b9b91f9f79ab49838baae5bb5ab42c30e
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sun May 13 17:48:13 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Mon May 14 22:19:30 2012 +0200
-add docs for ${CMAKE_INSTALL_DEFAULT_COMPONENT_NAME}
Alex
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 897e516..6881236 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -523,6 +523,16 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
Variables That Change Behavior);
cm-DefineProperty
+(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME, cmProperty::VARIABLE,
+ Default component used in install() commands.,
+ If an install() command is used without the COMPONENT argument,
+ these files will be grouped into a default component. The name of this
+ default install component will be taken from this variable.
+ It defaults to \Unspecified\. ,
+ false,
+ Variables That Change Behavior);
+
+cm-DefineProperty
(CMAKE_FIND_LIBRARY_PREFIXES, cmProperty::VARIABLE,
Prefixes to prepend when looking for libraries.,
This specifies what prefixes to add to library names when
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732e875ab7cf4797ef33bd4b897bc41eb53
commit 7ced0732e875ab7cf4797ef33bd4b897bc41eb53
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sun May 13 15:44:37 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Mon May 14 22:19:12 2012 +0200
make default install component name configurable
Until now an unnamed component was always named Unspecified.
Now this name is taken from the new cmake variable
CMAKE_INSTALL_DEFAULT_COMPONENT_NAME,
which is initialized to Unspecified. But it can now be set to something
project-specific, per directory
Alex
diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake
index 45d1fbf..6c61d3d 100644
--- a/Modules/CMakeGenericSystem.cmake
+++ b/Modules/CMakeGenericSystem.cmake
@@ -168,6 +168,10 @@ ELSE(CMAKE_HOST_UNIX)
SET(CMAKE_GENERIC_PROGRAM_FILES)
ENDIF(CMAKE_HOST_UNIX)
+# Set a variable which will be used as component name in install() commands
+# where no COMPONENT has been given:
+SET(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME Unspecified)
+
MARK_AS_ADVANCED(
CMAKE_SKIP_RPATH
CMAKE_SKIP_INSTALL_RPATH
diff --git a/Source/cmInstallCommand.cxx b/Source/cmInstallCommand.cxx
index d8522ee..4016734 100644
--- a/Source/cmInstallCommand.cxx
+++ b/Source/cmInstallCommand.cxx
@@ -55,6 +55,13 @@ bool cmInstallCommand::InitialPass(std::vectorstd::string
const args,
this-Makefile-GetLocalGenerator()
-GetGlobalGenerator()-EnableInstallTarget();
+ this-DefaultComponentName = this-Makefile-GetSafeDefinition(
+ CMAKE_INSTALL_DEFAULT_COMPONENT_NAME);
+ if (this-DefaultComponentName.empty())
+{
+this-DefaultComponentName = Unspecified;
+}
+
// Switch among the command modes.
if(args[0] == SCRIPT)
{
@@ -95,7 +102,7 @@ bool cmInstallCommand::InitialPass(std::vectorstd::string
const args,
//
bool cmInstallCommand::HandleScriptMode(std::vectorstd::string const args)
{
- std::string component(Unspecified);
+ std::string component = this-DefaultComponentName;
int componentCount = 0;
bool doing_script = false;
bool doing_code = false;
@@ -222,7 +229,7 @@ bool
cmInstallCommand
Re: [CMake] Packaging Best Practices for Linux
On Wednesday 16 May 2012, Michael Jackson wrote: ... That was VERY informative. This is what I was afraid of. With Windows and OS X even though there are 3 or 4 versions if you build for the earliest one (XP or 10.5) the binary has a really good chance of still running on the latest (Win7 or Lion). With Linux and so many distributions I don't have time to create that many different virtual machines to compile on each and every one. I am a single developer. I think I am going to go the source route and make sure that my software just compiles with the standard packages from each of the distros (Qt 4, HDF5 1.8, Boost and Qwt). The only issue might be Qwt as I still use Version 5 and I think there is a newer version out that I doubt I am compatible with. All else fails I have my own repo for Qwt that is public for anyone to pull from. I very much want to support Linux in the best way possible. I was hoping for some thing easier but I guess this is just the way it is. Well, e.g. Kitware releases a binary cmake package for Linux for every release, so it is possible. You should use a relatively old distribution to build that binary package. Relying on Qt from the distro should be ok (... which means it kind of contradicts with use an old distro). Linking statically against Qwt and HDF5 would make things a bit easier. Otherwise you can link dynamically and set RPATH to $ORIGIN/../lib/ or something like this for your executable(s). The others are right that for a first-class citizen the package should get into the distro repository. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking to libraries that depend on other libraries
On Thursday 17 May 2012, Andreas Pakulat wrote: Hi Am Donnerstag, 17. Mai 2012 schrieb Petr Kmoch : Hi David, there's a target property LINK_INTERFACE_LIBRARIES (and per-configuration variants) which can be used for this purpose. Starting with 2.8.7, target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as a new argument mode, setting the property instead of linking. Actually using link_interface_libraries in target_link_libraries works already in 2.6.4 I believe, since KDE uses that and requires that cmake version at the moment. LINK_INTERFACE_LIBRARIES exists since cmake 2.6.2. http://www.cmake.org/Wiki/CMake_2.6.1_Docs http://www.cmake.org/Wiki/CMake_2.6.2_Docs http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix/Commands Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Packaging Best Practices for Linux
On Thursday 17 May 2012, Craig Scott wrote: That was VERY informative. This is what I was afraid of. With Windows and OS X even though there are 3 or 4 versions if you build for the earliest one (XP or 10.5) the binary has a really good chance of still running on the latest (Win7 or Lion). With Linux and so many distributions I don't have time to create that many different virtual machines to compile on each and every one. I am a single developer. I think I am going to go the source route and make sure that my software just compiles with the standard packages from each of the distros (Qt 4, HDF5 1.8, Boost and Qwt). The only issue might be Qwt as I still use Version 5 and I think there is a newer version out that I doubt I am compatible with. All else fails I have my own repo for Qwt that is public for anyone to pull from. I very much want to support Linux in the best way possible. I was hoping for some thing easier but I guess this is just the way it is. Don't give up just yet! There are other options which might meet your needs. No-one appears yet to have mentioned the LSB (Linux Standards Base) and it is designed to solve problems just like yours. Admittedly, it will take a little bit of (one-time) work, but as someone who has done this with production code at a previous employer, we found it was well worth it. After getting things working, we only had to distribute a single package to cover all linux distributions (yes, even Debian-based ones such as Ubuntu). Can you put this information, how to build a LSB-compatible application using cmake, somewhere in the cmake wiki ? http://www.cmake.org/Wiki/CMake I guess this is a problem many cmake users have (maybe without knowing). Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] copy dependant shared libs locally
On Thursday 17 May 2012, Daniel Krikun wrote:
Hello,
I would like to trace shared library dependencies between targets (and also
to external packages) and then copy required dll's to output bin directory
(so that they are immediately available, without PATH editing) in the
post-build.
However, for debug configuration, I need to copy debug dll's (usually with
'd' suffix) and for release configuration - release dll's.
I can copy files to run-time directory using add_custom_command, but how
could I make a distinction for the release-debug files?
So you want to be able to run your executables directly from the buildtree,
right ?
To solve the problem for dlls which are built in your project, you can adjust
the directories where cmake creates executables and shared libs, so that they
are created in the same directory and the dlls will be found:
set(RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin )
This should put both exes and dlls into one common directory.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries chain dynamic-static
On Thursday 17 May 2012, Petr Kmoch wrote: Hi Anton, you should look into target property LINK_INTERFACE_LIBRARIES (and its per-configuration variants) which controls transitive linking. target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as an argument mode, which sets the property instead of linking. No, this is a different problem. Linking a shared library against static libraries does not have the effect that the object files of the static libs are included in the shared lib. But this is probably what Anton expected. So, since this does not happen, to resolve the functions when linking the executable, it also needs to link against the static libraries. So this is correct. Convenience libraries as they are called with autotools are not really supported with cmake. You have two options: 1) simply compile all source files directly into the shared library. They can be in different directories, no problem. 2) since cmake 2.8.8: instead of creating static libs, create a object libs: add_library(.. OBJECT ...). This basically avoids the need for recompiling the source files if the files are otherwise built multiple times (which may happen with solution 1) ). Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: module and cmake
On Saturday 19 May 2012, Johannes Zarl wrote: Hello Paul, I don't know about your specific find_package file for FFTW, but we do use modules together with CMake, so I'll add my thoughts: As Eric already said, the modules command alters your environment. CMake doesn't know about shell modules, but most find_package commands provide some way to tell them about the location of a package by specifying an environment variable (normally something like PACKAGE_ROOT or PACKAGE_DIR). You'll have to look in the find-package script if this is the case with your FindFFTW.cmake script. If it's not written in the documentation on top of that file, search for $ENV. If your FindFFTW3.cmake does not examine any environment variable, you should fix it in your project (and file a bug with the original project, if it's not your project). If that's not an option, it's probably best if you just set whatever variable your findFFTW3.cmake script expects as a clue as parameter to cmake (e.g. cmake .. -DFFTW3_INCLUDE_DIR=$FFTW3_ROOT/include). So in summary, you should fix your module file to provide a suitable variable pointing to your installation root, and you should also fix poorly written FindXXX.cmake scripts circulating in the wild. Yes, either such a env. variable as pointed out here, or a modified CMAKE_PREFIX_PATH as mentioned in the other email. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] copy dependant shared libs locally
On Sunday 20 May 2012, Daniel Krikun wrote: I do that, but I want more. I want to trace third-parties. In general, I would wonder why there is no such functionality available in cmake, why is that there are all these helpful find* modules that find headers, static libs etc., but not dlls. Currently, we have to update the PATH variable, but it is tedious and error-prone. Please keep replies on the list, so others can help too :-) Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding include directories when importing targets exported via install(EXPORT ...)
On Tuesday 15 May 2012, Matthew LeRoy wrote:
Hi again,
I'm working on setting up install(...) commands for a shared library
project (call it libA), and I'm using the install(EXPORT ...) signature as
has been recommended to me previously to export the shared library target
so I can import it in another CMake-based project (call it libB). So far
things have been pretty straightforward, but I'm now trying to determine
how to deal with the public header files for the project. So, two
questions:
1. What's the preferred method for installing public headers? I've seen
sparse documentation about a PUBLIC_HEADER target property, but the lack
of information I can find about it via Google makes me wonder if it's not
considered 'best practice'. Taking a look at the CMake list files for the
LLVM project, they seem to be using multiple install(DIRECTORY ...)
commands. I'm sure there are multiple ways to do this, so what's
recommended?
set(INCLUDE_INSTALL_DIR include)
install(FILES a.h b.h. c.h. DESTINATION ${INCLUDE_INSTALL_DIR} )
or using GNUInstallDirs.cmake:
include(GNUInstallDirs)
...
install(FILES DESTINATION ${CMAKE_INSTALL_INCLUDEDIR} )
2. How should libB find the location of the installed headers for libA?
With Find* modules (of which I'm using a few, FindBoost being one), there
is generally a LibName_INCLUDE_DIRs variable that gets set with the
include path that I would add in libB's list file via
include_directories(${LibName_INCLUDE_DIRS}). But, since I'm using
exported/imported targets instead of a Find* module, there doesn't seem to
be any built-in support for 'importing' the headers. I saw something in
the release notes for a recent CMake version (2.8, I think?) about
something called 'per-target INCLUDE_DIRECTORIES', which sounds promising,
but couldn't find much more info about it.
This is related, but not yet ready for this purpose.
This is just that you can set per-target include dirs instead of using
include_directories()
which works per directory.
Alright, I lied... a third somewhat-related question:
3) What's the general practice as far as where to install the .cmake file
generated by the install(EXPORT ...) command? Should it go in the install
location along with the built targets? It seems that the generated .cmake
file is intended to replace Find* modules and prevent other projects from
having to know the installed location of the exported library... but
wouldn't putting the generated .cmake import file in the install location
require dependent projects to know where the install location is in order
to include the .cmake import file?
This is described in detail in the documentation to find_package().
Short version: put it into lib/cmake/$YourProject/
optionally with a version number:
lib/cmake/$YourProject-1.2.3/
CMake will look there for FooConfig.cmake.
I recommend to export the targets into a file named e.g. FooTargets.cmake, and
write FooConfig.cmake yourself, something like:
...
set(FOO_INCLUDE_DIRS ... )
include(${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake)
(CMAKE_CURRENT_LIST_DIR exists since cmake 2.8.3 I think)
Setting the include dirs here properly is not trivial.
The user expects it to be an absolute path.
Configuring an absolute path into this file at build time means the install
location of that package is fixed and cannot be changed later on.
To make this package relocatable, i.e. so that the later user can decide
about the install location, I recommend to use CMakePackageConfigHelpers.cmake
coming with cmake 2.8.8, use the function configure_package_config_file().
If the documentation is unclear, let me know.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Making the default install component name configurable
On Monday 14 May 2012, Brad King wrote: On 5/13/2012 2:15 PM, Alexander Neundorf wrote: the CMAKE_DEFAULT_INSTALL_COMPONENT_NAME variable is still in Unspecified, so this is still the default. I'd rather the name be CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to keep the CMAKE_INSTALL_ prefix for variables affecting installation (along with CMAKE_INSTALL_PREFIX). Or shorter CMAKE_INSTALL_DEFAULT_COMPONENT ? But that sounds more like a boolean switch... Alex -- 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] Making the default install component name configurable
On Monday 14 May 2012, Brad King wrote: On 5/13/2012 2:15 PM, Alexander Neundorf wrote: the CMAKE_DEFAULT_INSTALL_COMPONENT_NAME variable is still in Unspecified, so this is still the default. I'd rather the name be CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to keep the CMAKE_INSTALL_ prefix for variables affecting installation (along with CMAKE_INSTALL_PREFIX). Done, updated branch pushed. Alex -- 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] set_property(DIRECTORY) regression ?
Hi, it seems the behaviour of DIRECTORY properties changed from cmake 2.6.4 to 2.8.0. It seems when setting a directory property, with 2.6.4 this was inherited into subdirs, with 2.8.0 and above not anymore. This is the output I get when running the attachec example with cmake 2.6.4 and 2.8.0: Please note how with 2.6.4 ex is TRUE in the subdir sub/, while with 2.8.0 it is not set in sub/ : hammer:~/src/CMake/tests/dirprop/build$ /opt/cmake-2.6.4-Linux-i386/bin/cmake .. -- ex 1: -- DF: Qt5CoreConfig.cmake add_library(Qt5::Core SHARED IMPORTED) -- ex 2: TRUE -- ex sub: TRUE -- Configuring done -- Generating done -- Build files have been written to: /home/alex/src/CMake/tests/dirprop/build hammer:~/src/CMake/tests/dirprop/build$ /opt/cmake-2.8.0-Linux-i386/bin/cmake .. -- ex 1: -- DF: Qt5CoreConfig.cmake add_library(Qt5::Core SHARED IMPORTED) -- ex 2: TRUE -- ex sub: -- DF: Qt5CoreConfig.cmake add_library(Qt5::Core SHARED IMPORTED) -- Configuring done -- Generating done -- Build files have been written to: /home/alex/src/CMake/tests/dirprop/build Alex dirprops.tar.gz Description: application/compressed-tar -- 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] Making the default install component name configurable
Hi, the install() command has a COMPONENT argument. If this is not used, such unnamed components are always named Unspecified. In the MakeDefaultInstallComponentNameConfigurable branch on stage I added a new cmake variable CMAKE_DEFAULT_INSTALL_COMPONENT_NAME, which is now used instead. It is initialized to Unspecified, so if nobody does anything, everything stays as it was. But if needed, this variable can now be set to something project-specific or directory specific. Comments ? Alex P.S. documentation is still missing, will do this soon -- 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] Making the default install component name configurable
On Sunday 13 May 2012, Eric Noulard wrote: 2012/5/13 Alexander Neundorf neund...@kde.org: Hi, the install() command has a COMPONENT argument. If this is not used, such unnamed components are always named Unspecified. In the MakeDefaultInstallComponentNameConfigurable branch on stage I added a new cmake variable CMAKE_DEFAULT_INSTALL_COMPONENT_NAME, which is now used instead. It is initialized to Unspecified, so if nobody does anything, everything stays as it was. But if needed, this variable can now be set to something project-specific or directory specific. Comments ? This looks like a nice feature. It will have a may-be unoticeable side-effect with CPack. That's why I CC'd you :-) Currently CPack.cmake do automatically require the default component to be installed (if specified in CPACK_COMPONENTS_ALL) . You can see that, because you have: Modules/CPack.cmake:set(CPACK_COMPONENT_UNSPECIFIED_HIDDEN TRUE) Modules/CPack.cmake:set(CPACK_COMPONENT_UNSPECIFIED_REQUIRED TRUE) As soon as the user do change the default component he/she will loose this automatic behavior and shall set(CPACK_COMPONENT_compName_REQUIRED TRUE) in order to get back this behavior. We could patch CPack.cmake in the case where CMAKE_DEFAULT_INSTALL_COMPONENT_NAME is set globally but if it is set on a per-directory basis then it would be up to the user to set CPACK_COMPONENT_compName_ variables with appropriate value. I think this should be ok. I mean, everything where the project does not change the CMAKE_DEFAULT_INSTALL_COMPONENT_NAME variable is still in Unspecified, so this is still the default. And everything else has been set explicitely by the user, so it should be ok if he has the set the respective cpack variables, I think. Alex -- 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] How to use different assemblers in single build?
On Saturday 12 May 2012, Alexey Istomin wrote: Yes. You need to duse two different assembler dialects, each dialect counts as a separate language to cmake, so you can have many in parallel. So you should add e.g. a ASM-DSP dialect, and set the language of the source files to ASM-DSP. This this assembler will be invoked on these files. Adding an assembler dialect is not hard, you need just a few tiny files: http://www.cmake.org/Wiki/CMake/Assembler This page is slightly out of date, but the documentation how to add a new assembler is still valid. Just have a look at the Modules/ directory for the ASM-related files, you should see how this works. Alex Thanks a lot, Alex. I done some experiments. It looks like dsp-asm sources should have a different file extension? Can CMake select specific asm-compiler depends on subdir instead of file extesion? Not per directory, but per file. You can use set_source_files_properties(... LANGUAGE ASM_DSP) This should work. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use different assemblers in single build?
On Saturday 12 May 2012, Alexey Istomin wrote: Thanks a lot, Alex. I done some experiments. It looks like dsp-asm sources should have a different file extension? Can CMake select specific asm-compiler depends on subdir instead of file extesion? Not per directory, but per file. You can use set_source_files_properties(... LANGUAGE ASM_DSP) This should work. Alex Thanks! set_source_files_properties works fine! It seams last question. Is it possible to place CMakeASM-DSPInformation.cmake, CMakeDetermineASM-DSPCompiler.cmake and CMakeTestASM-DSPCompiler.cmake files inside the project (without copy to system usr\share\cmake-2.8.7\Modules)? In this case we don't need to explain for users how to add these files to system before build. Does it work if you set CMAKE_MODULE_PATH to the directory where you put these files ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use different assemblers in single build?
On Friday 11 May 2012, Alexey Istomin wrote: Is it possible to use different assemblers in single build with CMake? I try to use CMake for building embedded application - statically linked elf file. Main CPU has 2 cores: general-purpose MIPS based core and DSP. Project has simple structure: main dir contains asm and C sources for Mips core, dsp-lib subdir has only asm sources for DSP core: main/ crt0-mips.s main.c ... dsp-lib/ fft.s GCC compiler and assembler are used for Mips sources, special assembler (dspasm) based on gnu should be used for DSP. Main should be linked with dsp lib into single elf file. I can successfully build main app without dsp-lib. But when I try to add dsp-lib subdir and set dspadm as assembler, CMake still uses mips-asm in the dsp-lib. Is it any solution? Yes. You need to duse two different assembler dialects, each dialect counts as a separate language to cmake, so you can have many in parallel. So you should add e.g. a ASM-DSP dialect, and set the language of the source files to ASM-DSP. This this assembler will be invoked on these files. Adding an assembler dialect is not hard, you need just a few tiny files: http://www.cmake.org/Wiki/CMake/Assembler This page is slightly out of date, but the documentation how to add a new assembler is still valid. Just have a look at the Modules/ directory for the ASM-related files, you should see how this works. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Passing back list of files from Function
On Friday 11 May 2012, Michael Jackson wrote:
I have a function where I am generating a number of files and I need to
pass that list of files back to the original calling cmake
command/file/scope. How would I go about that?
function(create_files)
set(options)
set(multiValueArgs GENERATED_HEADERS)
cmake_parse_arguments( WIG ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN} )
foreach ()
.. Generate some files
endforeach()
??
endfunction()
set(headers )
create_files (GENERATED_HEADERS headers)
Could someone help me fill in the blanks? Thanks
Give the name of a variable to create_files() which will be used to return the
values:
function(create_files)
set(options)
set(multiValueArgs GENERATED_HEADERS)
cmake_parse_arguments( WIG ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN} )
foreach ()
.. Generate some files
endforeach()
# the following line sets generatedFiles to file[123].x
set(${outVar} file1.x file2.x file3.x PARENT_SCOPE)
endfunction()
set(headers foo.h bar.h blub.h)
set(generatedFiles )
create_files (GENERATED_HEADERS INFILES ${headers} OUTVAR generatedFiles)
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Volunteering to become maintainer of FindLibLZMA.cmake
On Thursday 10 May 2012, Mario Bensi wrote: I'm not a LZMA maintainer. I think FindLibLZMA is a good candidate to integrate CMake/Modules like FindBZip2 or FindZLib. Yes, I think so too. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
On Wednesday 09 May 2012, Michael Wild wrote:
On 05/08/2012 11:13 PM, Dave Abrahams wrote:
on Tue May 08 2012, Alexander Neundorf a.neundorf-work-hi6Y0CQ0nG0-AT-
public.gmane.org wrote:
On Tuesday 08 May 2012, Dave Abrahams wrote:
Here's another one!
Scenario:
* I am running CMake under 0install to build and install libraries
* Each library builds a package SomePackage for the library binaries
and another package SomePackage-dev for the library headers (and
import libraries on Windows)
* The FindSomePackage.cmake file is part of the -dev package
* After building, 0install moves each package's build products into a
mostly-unpredictable subdirectory of its otherwise-read-only cache
(~/.cache/0install.net/). The subdirectory's name is determined by a
hash of the files.
* To get this working, I followed the scheme discussed here:
http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40plut
o.l uannocracy.com%3e
Summary:
1. Create a 0install SomePackage-preinstall package. Building this
package involves CMake building and installing both SomePackage and
SomePackage-dev into separate subdirectories (main/ and dev/) of
some prefix. 0install thereafter moves the whole directory tree
into its cache in a directory called sha1=someuglyhash
2. SomePackage's 0installation procedure is to copy
sha1=someuglyhash/main/ into its distribution directory (which then
ends up in
~/.cache/0install.net/sha1=otheruglyhash)
3. SomePackage-dev's 0installation procedure is to copy
sha1=someuglyhash/dev/ into its distribution directory
Problem: FindSomePackageConfig.cmake now has the wrong path to the
library binaries.
Any help most appreciated.
Can you please summarize what you actually want to achieve ?
Well, I tried to, above.
In short, I want to create separate main and -dev packages without
building twice, under the constraints imposed by 0install.
Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel
?
If that's the case, then this is wrong.
I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
libFoo.devel
FindFoo.cmake must be part of the using software, not of the software to
be searched.
Why do you have to find the installed library in this cache directory
?
Because, in a 0install world, that's where things go when you install
them.
Ok, how you do it along these lines:
CMakeLists.txt:
#-- BOF
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(Foo)
set(FOO_VERSION 1.2.3)
# initialize (absolute) installation directory variables
set(INSTALL_BIN_DIR bin CACHE PATH Install path for binaries)
set(INSTALL_LIB_DIR lib CACHE PATH Install path for libraries)
set(INSTALL_INCLUDE_DIR include CACHE PATH Install path for headers)
# this is for UNIX systems, see docs of find_package() for the search
# paths on APPLE and WIN32
set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
Install path for CMake files)
foreach(t BIN LIB INCLUDE CMAKE)
if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
endif()
mark_as_advanced(INSTALL_${t}_DIR)
endforeach()
# configure FooConfig.cmake and friends. FooConfig.cmake must be able
# to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
# directory without using absolute paths.
configure_file(cmake/FooConfig.cmake.in
${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
Please have a lokok at the new macro configure_package_config_file() which is
in cmake 2.8.8.
This helps a lot with writing config files which are relocatable.
The Config.cmake.in file has to contains a few special variables/macros:
@PACKAGE_INIT@
set(FOO_INCLUDE_DIR @PACKAGE_INSTALL_INCLUDE_DIR@ )
set(FOO_BIN_DIR @PACKAGE_INSTALL_BIN_DIR@ )
i.e. for every FOO_XYZ variable use a @PACKAGE_FOO_XYZ@ variable, and the
configure_package_config_file() will replace this with the help of the
@PACKAGE_INIT@ macro with a relocatable version.
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:CMakePackageConfigHelpers
configure_file(cmake/FooConfigVersion.cmake.in
${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
# configure the headers into the build tree so the package can be used
# without installing it and not hard-coding the source/build directory
# information into FooConfig.cmake
configure_file(include/foo.h
${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
The input file should have a suffix which indicates it is a file which is
intended to be configured, usually foo.h.in.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE command within a toolchain file is stripping file path if filename is a variable?
On Wednesday 09 May 2012, Terrence Meiczinger wrote:
I have a top level cmake toolchain file and I want it to include another
file. If I give the include a string filename it works. However, if I try
to make the filename a variable, it can no longer find the included file.
It appears cmake is stripping the path.
The following works fine...
linux-gnu-x86_64.cmake:
include(/src/toolchains/linux-common.cmake)
however, if I do the following it does not..
linux-gnu-x86_64.cmake:
set(TOOLCHAIN_COMMON /src/toolchains/linux-common.cmake)
message(STATUS TOOLCHAIN_COMMON: ${TOOLCHAIN_COMMON})
include(${TOOLCHAIN_COMMON})
It fails:
- cmake -DCMAKE_TOOLCHAIN_FILE=/src/toolchains/linux-gnu-x86_64.cmake
-- TOOLCHAIN_TOP: /src/toolchains/linux-gnu-x86_64.cmake
-- TOOLCHAIN_COMMON: /src/toolchains/linux-common.cmake
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
CMake Error at /src/toolchains/linux-gnu-x86_64.cmake:18 (INCLUDE):
include could not find load file:
/linux-common.cmake
As you can see the from the status output, the path is the same as the
first example. However, it appears cmake is stripping it prior to actually
including it.
Strange.
I tried to reproduce it here and was not able to.
I added this to the end of a toolchain file, and test.cmake happily issued its
message without problems:
set(myDir /home/alex/src/CMake/tc/test.cmake)
include(${myDir})
If you look into CMakefiles/CMakeSystem.cmake, there the toolchain file is
included using include(), nothing special there.
Can you send a simple testcase ?
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
On Wednesday 09 May 2012, Michael Wild wrote:
On 09.05.2012, at 21:03, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
...
# configure the headers into the build tree so the package can be used
# without installing it and not hard-coding the source/build directory
# information into FooConfig.cmake
configure_file(include/foo.h
${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
The input file should have a suffix which indicates it is a file which is
intended to be configured, usually foo.h.in. Alex
I don't agree, since it's COPYONLY. Besides, with a little more work in
FooConfig.cmake you can skip that step...
Oh, sorry, I missed the COPYONLY.
Alex
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Package installation conundrum
On Tuesday 08 May 2012, Dave Abrahams wrote: Here's another one! Scenario: * I am running CMake under 0install to build and install libraries * Each library builds a package SomePackage for the library binaries and another package SomePackage-dev for the library headers (and import libraries on Windows) * The FindSomePackage.cmake file is part of the -dev package * After building, 0install moves each package's build products into a mostly-unpredictable subdirectory of its otherwise-read-only cache (~/.cache/0install.net/). The subdirectory's name is determined by a hash of the files. * To get this working, I followed the scheme discussed here: http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l uannocracy.com%3e Summary: 1. Create a 0install SomePackage-preinstall package. Building this package involves CMake building and installing both SomePackage and SomePackage-dev into separate subdirectories (main/ and dev/) of some prefix. 0install thereafter moves the whole directory tree into its cache in a directory called sha1=someuglyhash 2. SomePackage's 0installation procedure is to copy sha1=someuglyhash/main/ into its distribution directory (which then ends up in ~/.cache/0install.net/sha1=otheruglyhash) 3. SomePackage-dev's 0installation procedure is to copy sha1=someuglyhash/dev/ into its distribution directory Problem: FindSomePackageConfig.cmake now has the wrong path to the library binaries. Any help most appreciated. Can you please summarize what you actually want to achieve ? Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ? If that's the case, then this is wrong. FindFoo.cmake must be part of the using software, not of the software to be searched. Why do you have to find the installed library in this cache directory ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Target usage requirements and conventions
On Saturday 05 May 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Wednesday 02 May 2012, Stephen Kelly wrote:
Brad King wrote:
...
to mean find-if-necessary. Then arguments after Bar would be
passed to the implied find_package for version and all the other
options. Either Module mode or Config mode could detect whether
there is enough information to define the Bar package, and then
do so. See below.
This brings up a fundamental question for this design discussion.
Are usage requirements associated with packages, with targets, or
with either/both?
Both, I think. They are associated with targets because properties on
targets are what needs to be propagated as required for usage, and
because targets will get usage requirements from other targets.
They are associated with packages for compatibility with packages which
do not create exported targets, but which do have conventional prefixes
on variables.
Going one step back: why is the package mode then necessary at all ?
If it is for packages which don't create imported targets, can't the
VARIABLE_PREFIX mode be used then ?
If a package does not define imported targets and does not use variables
with a consistent and conventional names, then finding the PACKAGE mode is
indeed not useful, I think.
The FIND_PACKAGE mode would find the package of the specified name, if we
can agree on doing that and the exact syntax for it.
That seems to be the point that there is disagreement on currently though
indeed.
I like your proposal very much for (imported) targets.
For (imported) targets it's clear what it is good for and how it is supposed
to work.
OTOH the package-mode and variable-mode are IMO not necessary.
While for the variable-mode the behaviour is still quite clear, for the
package mode there are many issues which are not obvious. What to do with
multiple components, or one component and multiple libraries, search paths,
required versions, etc.
If a package wants to support the new feature, it can install exported targets
and set the appropriate properties.
If not, then users will continue to use the ${FOO_INCLUDE_DIRS} and
${FOO_LIBRARIES} variables. I think that's fine.
Alex
--
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-commits] CMake branch, next, updated. v2.8.8-2819-ga026199
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 a02619930e10121c29189d6c20da1a7b1d7f9efd (commit)
via 1f8f58a0b9a7883aedf7a4bcb185e9784db4f13b (commit)
via b4a189fd14bd2abf1dba61cd06e540eb8744159e (commit)
from d6ff0a7ecad91b20dfb219cc17ab33dd1a940a09 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a02619930e10121c29189d6c20da1a7b1d7f9efd
commit a02619930e10121c29189d6c20da1a7b1d7f9efd
Merge: d6ff0a7 1f8f58a
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Sun May 6 10:35:25 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun May 6 10:35:25 2012 -0400
Merge topic 'FixMultipleResultsInFeatureSummary' into next
1f8f58a fix #13195: avoid multiple mentions of found packages
b4a189f CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f8f58a0b9a7883aedf7a4bcb185e9784db4f13b
commit 1f8f58a0b9a7883aedf7a4bcb185e9784db4f13b
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sun May 6 16:32:10 2012 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Sun May 6 16:32:10 2012 +0200
fix #13195: avoid multiple mentions of found packages
Now before adding a package to the list of found or not-found
packages, the package is remvoed from both lists before.
Alex
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index 4f9ba7e..be47f95 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -1368,41 +1368,73 @@ bool cmFindPackageCommand::ReadListFile(const char* f,
PolicyScopeRule psr)
}
//
-void cmFindPackageCommand::AppendToProperty(const char* propertyName)
+void cmFindPackageCommand::AppendToFoundProperty(bool found)
{
- std::string propertyValue;
- const char *prop =
- this-Makefile-GetCMakeInstance()-GetProperty(propertyName);
- if (prop *prop)
+ std::vectorstd::string foundContents;
+ const char *foundProp =
+ this-Makefile-GetCMakeInstance()-GetProperty(PACKAGES_FOUND);
+ if (foundProp *foundProp)
{
-propertyValue = prop;
+std::string tmp = foundProp;
-std::vectorstd::string contents;
-cmSystemTools::ExpandListArgument(propertyValue, contents, false);
-
-bool alreadyInserted = false;
-for(std::vectorstd::string::const_iterator it = contents.begin();
- it != contents.end(); ++ it )
+cmSystemTools::ExpandListArgument(tmp, foundContents, false);
+std::vectorstd::string::iterator nameIt = std::find(
+ foundContents.begin(), foundContents.end(), this-Name);
+if(nameIt != foundContents.end())
{
- if (*it == this-Name)
-{
-alreadyInserted = true;
-break;
-}
+ foundContents.erase(nameIt);
}
-if (!alreadyInserted)
+}
+
+ std::vectorstd::string notFoundContents;
+ const char *notFoundProp =
+ this-Makefile-GetCMakeInstance()-GetProperty(PACKAGES_NOT_FOUND);
+ if (notFoundProp *notFoundProp)
+{
+std::string tmp = notFoundProp;
+
+cmSystemTools::ExpandListArgument(tmp, notFoundContents, false);
+std::vectorstd::string::iterator nameIt = std::find(
+ notFoundContents.begin(), notFoundContents.end(), this-Name);
+if(nameIt != notFoundContents.end())
{
- propertyValue += ;;
- propertyValue += this-Name;
+ notFoundContents.erase(nameIt);
}
}
+
+ if(found)
+{
+foundContents.push_back(this-Name);
+}
else
{
-propertyValue = this-Name;
+notFoundContents.push_back(this-Name);
+}
+
+
+ std::string tmp;
+ const char* sep =;
+ for(size_t i=0; ifoundContents.size(); i++)
+{
+tmp += sep;
+tmp += foundContents[i];
+sep = ;;
+}
+
+ this-Makefile-GetCMakeInstance()-SetProperty(PACKAGES_FOUND,
+ tmp.c_str());
+
+ tmp = ;
+ sep = ;
+ for(size_t i=0; inotFoundContents.size(); i++)
+{
+tmp += sep;
+tmp += notFoundContents[i];
+sep = ;;
}
- this-Makefile-GetCMakeInstance()-SetProperty(propertyName,
- propertyValue.c_str());
- }
+ this-Makefile-GetCMakeInstance()-SetProperty(PACKAGES_NOT_FOUND,
+ tmp.c_str());
+}
//
void cmFindPackageCommand::AppendSuccessInformation()
@@ -1413,14 +1445,10 @@ void cmFindPackageCommand
Re: [cmake-developers] Target usage requirements and conventions
On Thursday 03 May 2012, Stephen Kelly wrote: Alexander Neundorf wrote: ... So, I don't see any need for automatically invoking find_package() from some other command. Calling find_package() is something people should be used to, it shouldn't be hard for them. Hiding it in some other commmands IMO would be good maybe for the lazy programmers, but not for maintainability. E.g. you have start deciding/explaining when to use find_package() and when not. Long term it's easy: You should never use find_package except for cases where the package is unconventional and target_use_package doesn't work. This is really the first time that I hear that deprecating find_package() is the long term goal. Why should this be a goal ? Alex -- 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] variable inheritance
On Thursday 03 May 2012, David Cole wrote: I think it qualifies as a bug because it's somewhat unexpected. The question is: can we fix it without disrupting people who are accidentally depending on this behavior The p-word again ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Version-specific documentation pages (was: Could a cmake_maximum_required() work?)
On Tuesday 01 May 2012, Brad King wrote: On 4/25/2012 2:17 PM, Stephen Kelly wrote: This issue came up because KDE wants to ensure that developers do not accidentally use features of newer versions of CMake. It will be helpful to reference documentation specific to the minimum required CMake version to avoid using features from newer versions. We've updated the CMake documentation page to provide persistent version-specific CMake, CTest, and CPack documentation pages: http://www.cmake.org/cmake/help/documentation.html Cool, that's new, right ? Alex -- 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] Target usage requirements and conventions
On Tuesday 01 May 2012, Stephen Kelly wrote: Stephen Kelly wrote: This avoids the 'double booking' problem[1], which I think might be real, so I think it's a good idea to optimize the common case, but I won't be too disappointed if it's not acceptable. [1] http://lists.qt-project.org/pipermail/development/2011- November/000258.html Ask different people and you get different answers, preferable all containing the word should. I would ignore if Lars says doesn't like Qt5Config.cmake having knowledge about the modules Qt5 consists of. I don't see any problem with this, and it makes it very clear and explicit what Qt5Config.cmake is for. I would also ignore Thiago saying I don't realise that I left the XmlPatterns requirement in the find_package line. So now everyone needs to install this addon when compiling the tests even if nothing uses it. This is not a problem. In his example there is find_package(... XmlPatterns), so XmlPatterns is searched. Very obvious behaviour. If the developer doesn't clean up properly it's his problem. Also, if Thiago thinks this is bad find_package(Qt5 COMPONENTS Widgets) ... qt5_add_module(mylib Widgets) it is just his opinion (...you remember his other comments). I think this is the right way to do it. Two commands, each one does one thing right. Orthogonal API. Also consider the Convenience trap (http://doc.trolltech.com/qq/qq13-apis.html). Two commands for two different things: search a package, use a package. So, I don't see any need for automatically invoking find_package() from some other command. Calling find_package() is something people should be used to, it shouldn't be hard for them. Hiding it in some other commmands IMO would be good maybe for the lazy programmers, but not for maintainability. E.g. you have start deciding/explaining when to use find_package() and when not. Alex -- 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] Target usage requirements and conventions
On Wednesday 02 May 2012, Stephen Kelly wrote:
Brad King wrote:
...
to mean find-if-necessary. Then arguments after Bar would be
passed to the implied find_package for version and all the other
options. Either Module mode or Config mode could detect whether
there is enough information to define the Bar package, and then
do so. See below.
This brings up a fundamental question for this design discussion.
Are usage requirements associated with packages, with targets, or
with either/both?
Both, I think. They are associated with targets because properties on
targets are what needs to be propagated as required for usage, and because
targets will get usage requirements from other targets.
They are associated with packages for compatibility with packages which do
not create exported targets, but which do have conventional prefixes on
variables.
Going one step back: why is the package mode then necessary at all ?
If it is for packages which don't create imported targets, can't the
VARIABLE_PREFIX mode be used then ?
We will likely need to make packages something first-class on the
C++ side. If find_package(Bar) detects that the files it loaded
define sufficient information for a package it should construct a
C++ object to represent the package. This event should establish
the package. A loose sequence of variable set()s is not explicit
enough.
Right.
How might find_package detect/define a first-class package object?
Just look for the right variables? Perhaps we could add an (optional)
explicit package declaration:
cmake_package(Bar LIBRARIES ... DEFINITIONS ...)
that can be either in the Find module or in the package configuration
file. This would allow more detailed information to be set.
Maybe. Where would this get us that convention in the right variables would
not?
I can imagine someone looking at that and thinking that that's the way to
notify users of my package/config file how to use it, and disregard the
actual variable name conventions:
FooConfig.cmake:
set(THE_FOO_LIBRARIES foo1 foo2)
cmake_package(Foo LIBRARIES ${THE_FOO_LIBRARIES})
Then again, cmake_package could also ensure that the correct conventional
variables are set by actually setting Foo_LIBRARIES to be the contents of
THE_FOO_LIBRARIES in that case, ensuring the possibility of using the
variables conventionally.
That also opens up the question of whether it should overwrite
Foo_LIBRARIES if it already exists, or warn about that.
I also think the 'Foo' would be redundant. It should be this to avoid
mistakes:
cmake_package(LIBRARIES ${THE_FOO_LIBRARIES})
CMake already knows the name of the package, right?
Isn't this getting a bit too much of new concepts ?
I mean, the semantics of target_use_package() with imported or in-project
targets are quite clear.
Isn't everything else not maybe only added complexity for little benefit ?
Alex
--
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] Target usage requirements and conventions
On Sunday 29 April 2012, Stephen Kelly wrote:
Hi there,
The topic of 'target usage requirements' has come up several times. It's
something I'd like to work further towards in CMake 2.8.9.
I have created a wiki page on the KDE wiki (there for my convenience
mostly) so that we can discuss the design, implementation and
implications.
http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements
Thanks for any comments,
Some comments:
You propose target_use_package(Foo Bar) to state that the target Foo should
use the include dirs and libraries from Bar. I like the idea of having a
separate command for that.
I do not like the idea that target_use_package() should automatically do a
find_package() for several reasons.
* find_package() has many options, in the end they would all have to be
present there too
* find_package() is an important part of the CMakeLists.txt, it should not be
hidden
* wouldn't this fall back to a find_package() call with its associated error
messages at cmake-time for every typo in the package name ?
Looking at other cmake commands, many of them now have two modes, an old one,
where simply the options are listed without separating keywords:
find_library(FOO_LIBRARY foo /opt/foo /usr/foo/lib)
and a new, more powerful one with additional keywords:
find_library(FOO_LIBRARY NAMES foo PATHS /opt/foo /usr/foo/lib)
When adding a new command, we should start with the keyword-based variant, to
avoid having two signatures in the future.
This also makes the code more explicit about what it does, less guessing
involved for readers:
target_use_package(Foo IMPORTED_TARGETS Bar Blub)
or
target_use_package(Foo VIA_PREFIX Bar_Bat )
or
target_use_package(Foo PACKAGE Bar)
Doing it this way would also solve the problem that your prefix-based example:
target_use_package(Foo ${Bar_Bat_LIBRARIES})
... Otherwise, the variables with the appropriate naming conventions (eg
Bar_Bat_LIBRARIES Bar_Bat_INCLUDE_DIRS) are used.
the target_use_package() implementation would get to see that value of
${Bar_Bat_LIBRARIES}, which might be /usr/lib/libbat.so;/usr/lib/libbar.so,
and wouldn't be able to find out about prefixes anymore.
Alex
--
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] CCTray like tool for CDash?
On Monday 16 April 2012, NoRulez wrote: Hello, is there a tool for CDash which is equivalent to CCTray for Cruise Control or is such tool planned? what is CCTray ? Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.7 + XCode generator + nasm files
On Wednesday 11 April 2012, David Cole wrote: On Wed, Apr 11, 2012 at 4:23 AM, Damien Chavarria roy...@gmail.com wrote: Thank you David Alex, I also have the ASM_NASM language enabled in my CMakeLists.txt files, and this works for Makefile generators so I'm not sure I understand why there is more work involved in that area of the code ? It seems to handle nasm fine to me. My problem was only with XCode, and regardless of the Makefile generators, I think the CMake XCode generator should know about the nasm file type and set the correct field in the XCode project. David's suggestions looks good to me and I can submit a patch later today if you guys agree this is the correct course of action ? Yes, please do. (I assume everything works well for you from within Xcode once you set the nasm file types correctly? Everything builds fine?) But shouldn't this only be enabled when the ASM_NASM language has been enabled ? Otherwise a project which builds for xcode doesn't build with makefiles, because the enable_language(ASM_NASM) is missing. Also, I think it would be a good idea to reuse e.g. the file suffix extensions from CMakeASM_NASMInformation.cmake so this information is not duplicated. IOW, I don't want to keep you from submitting a patch, these are just some points which IMO should be kept in mind. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple Versions of CMake
On Tuesday 10 April 2012, Sara Rolfe wrote: Hello, I have been using CMake on a compute cluster with 64-bit nodes running RHEL 5.7. CMake was not installed on the nodes so I built version 2.8.4 in my home directory. Recently the cluster nodes were upgraded from RHEL 5.7 to RHEL 6.2, which has version 2.6 of CMake installed. Now I am getting the following error: CMake Error at /homes/grail/smrolfe/ITK/bin/ITK-3-20-x86_64/ ITKBuildSettings.cmake:10 (message): This ITK was built by CMake 2.8.4, but this is CMake 2.6.4. Please upgrade CMake to a more recent version. I would like to change the path to Cmake since I don't have permission to upgrade the software on the nodes and would like to continue using my own build. I'd appreciate any pointers. Simply download the version you want to have from www.cmake.org (in http://www.cmake.org/files/v2.8/ ) and unpack the binary package (i.e. -Linux- i386.tar.gz) anywhere, e.g. in your home, and then call this cmake using the full path to it. Alex -- 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://www.cmake.org/mailman/listinfo/cmake
