Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 2015-04-28 14:22-0400 Brad King wrote: On 04/27/2015 05:53 PM, Alan W. Irwin wrote: Anybody here got a clue about what is going on? Please strip it down to a minimal example. That will either find the culprit or provide a test case we can use independently. Hi Brad: The problem is I am reporting the problem second-hand, and I don't have access to a Cygwin platform myself. But from the report I received the incorrect warning message occurs each time a different compiler is enabled. So this is just an educated guess, but I think the following minimal two-line project (which enables the C compiler) cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR) project(test_cygwin C) would exercise the code in $PREFIX/share/cmake-3.2/Modules/Platform/CYGWIN.cmake and, it is that code that generates the incorrect warning message that my reporter is seeing. So please let me know if the above two-liner does provide that desired test case for the bug, i.e., always generates the warning on Cygwin platforms despite the above minimum CMake version. By the way, the above order of cmake_minimum_required and project commands is exactly the order used by PLplot if that order is relevant to this issue. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] How to specify compiler only flags
I'm trying to patch the CMakeLists.txt for openjpeg. Currently it does:
# Do not use ffast-math for all build, it would produce incorrect results,
only set for release:
SET(CMAKE_C_FLAGS_RELEASE -ffast-math ${CMAKE_C_FLAGS_RELEASE})
Unfortunately, CMAKE_C_FLAGS are also used in link step, which for -ffast-math
causes problems for users of the shared library.
I'm unable to find an equivalent flag that is for compiling only. I see I can
set the COMPILE_FLAGS property for the library, but there does not appear to
be a COMPILE_FLAGS_RELEASE property that would only set it for the Release
build type.
Suggestions?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.2.2-2270-gce6e191
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 ce6e191ff8036edf510f5ee0ebb8e79d8ae054d2 (commit)
via 28d80f11ba1be3126175904c16b148b20a868329 (commit)
via 42a21db772fbe407babaf30ae822023004505248 (commit)
from cacf47a2354c547f40a0cbd6ad9aed248c216c0e (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=ce6e191ff8036edf510f5ee0ebb8e79d8ae054d2
commit ce6e191ff8036edf510f5ee0ebb8e79d8ae054d2
Merge: cacf47a 28d80f1
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 19:10:22 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 19:10:22 2015 -0400
Merge topic 'simplify-cmDefinitions-Closure' into next
28d80f11 cmDefinitions: Replace recursion with loop.
42a21db7 cmDefinitions: Replace private constructor with MakeClosure.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28d80f11ba1be3126175904c16b148b20a868329
commit 28d80f11ba1be3126175904c16b148b20a868329
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Apr 26 15:49:43 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 01:01:18 2015 +0200
cmDefinitions: Replace recursion with loop.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index ccd20db..9ab6239 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -89,29 +89,27 @@ cmDefinitions cmDefinitions::MakeClosure() const
void cmDefinitions::MakeClosure(std::setstd::string undefined,
cmDefinitions const* defs)
{
- // Consider local definitions.
- for(MapType::const_iterator mi = defs-Map.begin();
- mi != defs-Map.end(); ++mi)
+ while(defs)
{
-// Use this key if it is not already set or unset.
-if(this-Map.find(mi-first) == this-Map.end()
- undefined.find(mi-first) == undefined.end())
+// Consider local definitions.
+for(MapType::const_iterator mi = defs-Map.begin();
+mi != defs-Map.end(); ++mi)
{
- if(mi-second.Exists)
-{
-this-Map.insert(*mi);
-}
- else
+ // Use this key if it is not already set or unset.
+ if(this-Map.find(mi-first) == this-Map.end()
+ undefined.find(mi-first) == undefined.end())
{
-undefined.insert(mi-first);
+if(mi-second.Exists)
+ {
+ this-Map.insert(*mi);
+ }
+else
+ {
+ undefined.insert(mi-first);
+ }
}
}
-}
-
- // Traverse parents.
- if(cmDefinitions const* up = defs-Up)
-{
-this-MakeClosure(undefined, up);
+defs = defs-Up;
}
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42a21db772fbe407babaf30ae822023004505248
commit 42a21db772fbe407babaf30ae822023004505248
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Apr 26 15:44:26 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 01:01:17 2015 +0200
cmDefinitions: Replace private constructor with MakeClosure.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index 0556654..ccd20db 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -77,21 +77,16 @@ std::vectorstd::string cmDefinitions::LocalKeys() const
}
//
-cmDefinitions cmDefinitions::Closure() const
-{
- return cmDefinitions(ClosureTag(), this);
-}
-
-//
-cmDefinitions::cmDefinitions(ClosureTag const, cmDefinitions const* root):
- Up(0)
+cmDefinitions cmDefinitions::MakeClosure() const
{
std::setstd::string undefined;
- this-ClosureImpl(undefined, root);
+ cmDefinitions closure;
+ closure.MakeClosure(undefined, this);
+ return closure;
}
//
-void cmDefinitions::ClosureImpl(std::setstd::string undefined,
+void cmDefinitions::MakeClosure(std::setstd::string undefined,
cmDefinitions const* defs)
{
// Consider local definitions.
@@ -116,7 +111,7 @@ void cmDefinitions::ClosureImpl(std::setstd::string
undefined,
// Traverse parents.
if(cmDefinitions const* up = defs-Up)
{
-this-ClosureImpl(undefined, up);
+this-MakeClosure(undefined, up);
}
}
diff --git a/Source/cmDefinitions.h b/Source/cmDefinitions.h
index 4664090..6917402 100644
--- a/Source/cmDefinitions.h
+++ b/Source/cmDefinitions.h
@@ -45,13 +45,11 @@ public:
/** Get the set of all local keys. */
[CMake] Apple Metal Support in Xcode?
Hi, I'm trying to get Apple's new shading language, Metal, to work with my CMake project, but I am not having any luck. Xcode will automagically compile .metal files that are part of the project, but their Type (in the File Inspector in the right-hand Utilities pane) has to be set to Default - Metal Shader Source File. When I add .metal files via CMake they are a) not listed in the project's Compile Sources list (in the Target's Build Phases tab), and b) their Type is set to Source File. A) can be solved by adding source file properties (e.g. compile flags) to the .metal file in CMake, but I haven't been able to change the Type of the .metal files through CMake. I have seen a commit log [0] about Add[ing] file type for Metal shader files, but that change doesn't seem to have made it to the released CMake version yet. My questions: 1) Is there anything I can do right now (with CMake 3.2.2.) that would make Xcode handle .metal files correctly? 2) Are there plans to support .metal files via CMake and if so, how far along are they? Thanks, [0] http://www.cmake.org/pipermail/cmake-commits/2015-April/022952.html -- Marek Vojtko mail: marek.voj...@firaxis.com phone: (+1) 410-229-2519 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.2.2-2272-ged96169
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 ed9616928b88eef8d7ea7b7f7e02a994ea8b0e59 (commit)
via 37a66fa9cf34637ed0edc25df1156d9bdb241a43 (commit)
from ce6e191ff8036edf510f5ee0ebb8e79d8ae054d2 (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=ed9616928b88eef8d7ea7b7f7e02a994ea8b0e59
commit ed9616928b88eef8d7ea7b7f7e02a994ea8b0e59
Merge: ce6e191 37a66fa
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 19:21:50 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 19:21:50 2015 -0400
Merge topic 'remove-cmDefinitions-stack-adaptor' into next
37a66fa9 cmMakefile: Remove stack adaptor for the VarStack.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=37a66fa9cf34637ed0edc25df1156d9bdb241a43
commit 37a66fa9cf34637ed0edc25df1156d9bdb241a43
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Apr 25 17:21:51 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 01:20:43 2015 +0200
cmMakefile: Remove stack adaptor for the VarStack.
The purpose of the stack is to allow access only to the top of it. Access
to items which are not at the top is needed, so cmDefinitions objects
get a Parent pointer.
The existence of the Parent pointer is a workaround for the inappropriate
use of stack in the first place. Remove it now.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 5fc8647..0bff327 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -46,7 +46,7 @@
class cmMakefile::Internals
{
public:
- std::stackcmDefinitions, std::listcmDefinitions VarStack;
+ std::listcmDefinitions VarStack;
std::stackstd::setstd::string VarInitStack;
std::stackstd::setstd::string VarUsageStack;
bool IsSourceFileTryCompile;
@@ -56,24 +56,24 @@ public:
cmDefinitions* parent = 0;
if (!this-VarStack.empty())
{
- parent = this-VarStack.top();
+ parent = this-VarStack.back();
}
-this-VarStack.push(cmDefinitions(parent));
+this-VarStack.push_back(cmDefinitions(parent));
}
void InitializeDefinitions(cmMakefile* parent)
{
-this-VarStack.top() = parent-Internal-VarStack.top().MakeClosure();
+this-VarStack.back() = parent-Internal-VarStack.back().MakeClosure();
}
const char* GetDefinition(std::string const name)
{
-return this-VarStack.top().Get(name);
+return this-VarStack.back().Get(name);
}
void SetDefinition(std::string const name, std::string const value)
{
-this-VarStack.top().Set(name, value.c_str());
+this-VarStack.back().Set(name, value.c_str());
}
void RemoveDefinition(std::string const name)
@@ -81,32 +81,32 @@ public:
if (this-VarStack.size() 1)
{
// In lower scopes we store keys, defined or not.
- this-VarStack.top().Set(name, 0);
+ this-VarStack.back().Set(name, 0);
}
else
{
- this-VarStack.top().Erase(name);
+ this-VarStack.back().Erase(name);
}
}
std::vectorstd::string LocalKeys() const
{
-return this-VarStack.top().LocalKeys();
+return this-VarStack.back().LocalKeys();
}
std::vectorstd::string ClosureKeys() const
{
-return this-VarStack.top().ClosureKeys();
+return this-VarStack.back().ClosureKeys();
}
void PopDefinitions()
{
-this-VarStack.pop();
+this-VarStack.pop_back();
}
bool RaiseScope(std::string const var, const char* varDef, cmMakefile* mf)
{
-cmDefinitions cur = this-VarStack.top();
+cmDefinitions cur = this-VarStack.back();
if(cmDefinitions* up = cur.GetParent())
{
// First localize the definition in the current scope.
---
Summary of changes:
Source/cmMakefile.cxx | 24
1 file changed, 12 insertions(+), 12 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.2.2-2267-gcacf47a
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 cacf47a2354c547f40a0cbd6ad9aed248c216c0e (commit)
via 933c144f1d2ff5d21b1e7fb41da83f9d47e740e5 (commit)
via 1e2170d4461fe1feebfc5c5efa14dfc11f3d6455 (commit)
via 0bc62a1e4f6c041a4134e3303c22a0de36286b4f (commit)
via 6c953b73176e246783c87b3a7be08833af8a645d (commit)
from 6e5d72779f4cfbad2ad281b458914b8c0f914116 (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=cacf47a2354c547f40a0cbd6ad9aed248c216c0e
commit cacf47a2354c547f40a0cbd6ad9aed248c216c0e
Merge: 6e5d727 933c144
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 18:54:17 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 18:54:17 2015 -0400
Merge topic 'refactor-cmDefinitions-API' into next
933c144f cmDefinitions: Make ClosureKeys API vector-based.
1e2170d4 cmDefinitions: Inline GetClosureKeys implementation.
0bc62a1e cmDefinitions: Replace ClosureKeys recursion with looping.
6c953b73 cmDefinitions: Change LocalKeys to return a vector.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=933c144f1d2ff5d21b1e7fb41da83f9d47e740e5
commit 933c144f1d2ff5d21b1e7fb41da83f9d47e740e5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Apr 26 15:36:49 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:53:11 2015 +0200
cmDefinitions: Make ClosureKeys API vector-based.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index a543edf..0556654 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -121,7 +121,7 @@ void cmDefinitions::ClosureImpl(std::setstd::string
undefined,
}
//
-std::setstd::string cmDefinitions::ClosureKeys() const
+std::vectorstd::string cmDefinitions::ClosureKeys() const
{
std::setstd::string defined;
std::setstd::string undefined;
@@ -144,5 +144,5 @@ std::setstd::string cmDefinitions::ClosureKeys() const
}
up = up-Up;
}
- return defined;
+ return std::vectorstd::string(defined.begin(), defined.end());
}
diff --git a/Source/cmDefinitions.h b/Source/cmDefinitions.h
index 950970b..4664090 100644
--- a/Source/cmDefinitions.h
+++ b/Source/cmDefinitions.h
@@ -50,7 +50,7 @@ public:
cmDefinitions Closure() const;
/** Compute the set of all defined keys. */
- std::setstd::string ClosureKeys() const;
+ std::vectorstd::string ClosureKeys() const;
private:
// String with existence boolean.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 598c657..cbf32dd 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -94,7 +94,7 @@ public:
return this-VarStack.top().LocalKeys();
}
- std::setstd::string ClosureKeys() const
+ std::vectorstd::string ClosureKeys() const
{
return this-VarStack.top().ClosureKeys();
}
@@ -2496,8 +2496,7 @@ std::vectorstd::string cmMakefile
std::vectorstd::string res;
if ( !cacheonly )
{
-std::setstd::string definitions = this-Internal-ClosureKeys();
-res.insert(res.end(), definitions.begin(), definitions.end());
+res = this-Internal-ClosureKeys();
}
std::vectorstd::string cacheKeys =
this-GetState()-GetCacheEntryKeys();
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1e2170d4461fe1feebfc5c5efa14dfc11f3d6455
commit 1e2170d4461fe1feebfc5c5efa14dfc11f3d6455
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Apr 26 15:38:09 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:53:11 2015 +0200
cmDefinitions: Inline GetClosureKeys implementation.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index ec40edf..a543edf 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -125,14 +125,7 @@ std::setstd::string cmDefinitions::ClosureKeys() const
{
std::setstd::string defined;
std::setstd::string undefined;
- this-ClosureKeys(defined, undefined);
- return defined;
-}
-//
-void cmDefinitions::ClosureKeys(std::setstd::string defined,
-std::setstd::string undefined) const
-{
cmDefinitions const* up = this;
while (up)
@@ -151,4 +144,5 @@ void cmDefinitions::ClosureKeys(std::setstd::string
defined,
}
up = up-Up;
}
+ return defined;
}
diff --git a/Source/cmDefinitions.h b/Source/cmDefinitions.h
index d21ec23..950970b 100644
--- a/Source/cmDefinitions.h
+++ b/Source/cmDefinitions.h
@@
[CMake] C++Now / BoostCon / Boost 2.0
I will be giving a presentation at C++Now http://cppnow.org https://cppnow2015.sched.org all things boost - which will touch upon CMake/CTest/CDash. I have recommended CMake... for boost - like projects and would like to see it more widely accepted. http://rrsd.com/blincubator.com/tools_cmak/ I'm aware that in the past there was a large effort to switch boost to CMake from Boost Build which ended in failure. For Boost 2.0 https://cppnow2015.sched.org/event/d66a14e9cc28cffbf446b1fd2c3f4696#.VT-AV87_Suc I will promote the idea of boost libraries being less tightly coupled. Part of will be to propose that library authors be permitted to select their own build/test system. Testing of Boost would be just the union of the testing of all the individual libraries. Here are a few observations regarding CMake as it might relate to Boost. a) In the CMake section of the incubator page, I've advocated creating a library subdirectory named CMake which includes the cake scripts. The source files or not in this directory. The scripts contain relative path names to source files in the directory. This permits the CMake scripts to not be sprinkled all over the directory structure but rather in one place. I've used this and found it to work very well. b) I would like to see testing of boost libraries distributed to library users/testers and others, and have their test results posted on a library dashboard. This would provide a number of advantages. So I would like to be able to recommend CTest/CDash. I have made this setup work - but it doesn't just work. I would like to see: The CTest/CDash system has a sort of elaborate setup of experimental, nightly, etc. which ties certain test names to different test frequencies. This is too complex. Basically all we need is experimental which I would more likely call on demand. This is what users need. Download a library, build it, run test suite and post results. It's great that you guys run the public dashboard and I would like to encourage boost libraries developers to use it. I would like to see a few cosmetic changes but the idea is close to what I would like to see for Boost. I did meet a couple of you at CPPCon last september. If any of you expect go to C++Now please contact me with any information and/or advice you think might be useful to me. Robert Ramey -- View this message in context: http://cmake.3232098.n2.nabble.com/C-Now-BoostCon-Boost-2-0-tp7590405.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 28/04/15 12:23, Domen Vrankar a écrit : Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. Regards, Domen Hi, I'll resubmit the patches then. Best, Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.2.2-2239-g434c868
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 434c868fbb597a1b2694e4a2b25df6055c388035 (commit)
via 26155d19af233e19105250fab23ee38292f5cad6 (commit)
from f257a96641455634959ffef001040e03377e0282 (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=434c868fbb597a1b2694e4a2b25df6055c388035
commit 434c868fbb597a1b2694e4a2b25df6055c388035
Merge: f257a96 26155d1
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Tue Apr 28 09:37:17 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 09:37:17 2015 -0400
Merge topic 'if-IN_LIST' into next
26155d19 if: Implement new IN_LIST operator
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26155d19af233e19105250fab23ee38292f5cad6
commit 26155d19af233e19105250fab23ee38292f5cad6
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Tue Apr 28 15:10:11 2015 +0200
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Tue Apr 28 15:36:30 2015 +0200
if: Implement new IN_LIST operator
diff --git a/Help/command/if.rst b/Help/command/if.rst
index d50b14c..396becf 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -134,6 +134,9 @@ Possible expressions are:
Component-wise integer version number comparison (version format is
``major[.minor[.patch[.tweak]]]``).
+``if(variable|string IN_LIST variable)``
+ True if the given element is contained in the named list variable.
+
``if(DEFINED variable)``
True if the given variable is defined. It does not matter if the
variable is true or false just if it has been set. (Note macro
diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst
index aff696d..e59cce7 100644
--- a/Help/manual/cmake-policies.7.rst
+++ b/Help/manual/cmake-policies.7.rst
@@ -118,3 +118,4 @@ All Policies
/policy/CMP0058
/policy/CMP0059
/policy/CMP0060
+ /policy/CMP0061
diff --git a/Help/policy/CMP0061.rst b/Help/policy/CMP0061.rst
new file mode 100644
index 000..066b1c9
--- /dev/null
+++ b/Help/policy/CMP0061.rst
@@ -0,0 +1,14 @@
+CMP0061
+---
+
+Support new :command:`if` IN_LIST operator.
+
+CMake 3.3 adds support for the new IN_LIST operator.
+
+The ``OLD`` behavior for this policy is to ignore the IN_LIST operator.
+The ``NEW`` behavior is to interpret the IN_LIST operator.
+
+This policy was introduced in CMake version 3.3.
+CMake version |release| warns when the policy is not set and uses
+``OLD`` behavior. Use the :command:`cmake_policy` command to set
+it to ``OLD`` or ``NEW`` explicitly.
diff --git a/Help/release/dev/if-IN_LIST.rst b/Help/release/dev/if-IN_LIST.rst
new file mode 100644
index 000..9dd0725
--- /dev/null
+++ b/Help/release/dev/if-IN_LIST.rst
@@ -0,0 +1,5 @@
+if-IN_LIST
+--
+
+* Add a new IN_LIST operator to if() that evaluates true
+ if a given element is contained in a named list.
diff --git a/Source/cmConditionEvaluator.cxx b/Source/cmConditionEvaluator.cxx
index 0a71c60..74e8a11 100644
--- a/Source/cmConditionEvaluator.cxx
+++ b/Source/cmConditionEvaluator.cxx
@@ -15,7 +15,8 @@
cmConditionEvaluator::cmConditionEvaluator(cmMakefile makefile):
Makefile(makefile),
Policy12Status(makefile.GetPolicyStatus(cmPolicies::CMP0012)),
- Policy54Status(makefile.GetPolicyStatus(cmPolicies::CMP0054))
+ Policy54Status(makefile.GetPolicyStatus(cmPolicies::CMP0054)),
+ Policy61Status(makefile.GetPolicyStatus(cmPolicies::CMP0061))
{
}
@@ -676,6 +677,41 @@ bool cmConditionEvaluator::HandleLevel2(cmArgumentList
newArgs,
reducible, arg, newArgs, argP1, argP2);
}
+ if (argP1 != newArgs.end() argP2 != newArgs.end()
+ this-IsKeyword(IN_LIST, *argP1))
+{
+if(this-Policy61Status != cmPolicies::OLD
+ this-Policy61Status != cmPolicies::WARN)
+ {
+ bool result = false;
+
+ def = this-GetVariableOrString(*arg);
+ def2 = this-Makefile.GetDefinition(argP2-GetValue());
+
+ if(def2)
+{
+std::vectorstd::string list;
+cmSystemTools::ExpandListArgument(def2, list, true);
+
+result = std::find(list.begin(), list.end(), def) != list.end();
+}
+
+ this-HandleBinaryOp(result,
+reducible, arg, newArgs, argP1, argP2);
+ }
+ else if(this-Policy61Status == cmPolicies::WARN)
+{
+std::ostringstream e;
+e (this-Makefile.GetPolicies()-GetPolicyWarning(
+ cmPolicies::CMP0061)) \n;
+e IN_LIST will be interpreted as an operator
+ when the
[Cmake-commits] CMake branch, next, updated. v3.2.2-2262-g6e5d727
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 6e5d72779f4cfbad2ad281b458914b8c0f914116 (commit)
via 6034dc31bccb13b167ee7453bd3693c334e73c7e (commit)
via b2679bb29b33a1f828221c31e7553687bbe7ce5b (commit)
via 24db937ca324fa439f60a20758b29d3dd9b44bb4 (commit)
from dd4fb08a0bfc3179f8f7d1ff5c1e95a2101e04ac (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=6e5d72779f4cfbad2ad281b458914b8c0f914116
commit 6e5d72779f4cfbad2ad281b458914b8c0f914116
Merge: dd4fb08 6034dc3
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 18:35:00 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 18:35:00 2015 -0400
Merge topic 'simplify-cmDefinitions-Set' into next
6034dc31 cmDefinitions: Externalize the Set logic.
b2679bb2 cmDefinitions: Add an Erase method.
24db937c cmMakefile: Use the Internal class to enclose the VarStack.
diff --cc Source/cmMakefile.cxx
index 0935383,7180c6c..8754427
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@@ -53,32 -139,13 +139,30 @@@ public
};
// default is not to be building executables
-cmMakefile::cmMakefile(): Internal(new Internals)
+cmMakefile::cmMakefile(cmLocalGenerator* localGenerator)
+ : Internal(new Internals),
+LocalGenerator(localGenerator),
+StateSnapshot(localGenerator-GetGlobalGenerator()
+-GetCMakeInstance()-GetState())
{
- const cmDefinitions defs = cmDefinitions();
- const std::setstd::string globalKeys = defs.LocalKeys();
- this-Internal-VarStack.push(defs);
- this-Internal-VarInitStack.push(globalKeys);
- this-Internal-VarUsageStack.push(globalKeys);
+ this-Internal-PushDefinitions();
+ this-Internal-VarInitStack.push(std::setstd::string());
+ this-Internal-VarUsageStack.push(std::setstd::string());
this-Internal-IsSourceFileTryCompile = false;
+ if (this-LocalGenerator-GetParent())
+{
+cmMakefile* parentMf = this-LocalGenerator-GetParent()-GetMakefile();
+this-StateSnapshot =
+this-GetState()-CreateSnapshot(parentMf-StateSnapshot);
+}
+ else
+{
+this-StateSnapshot =
+this-GetState()-CreateSnapshot(this-StateSnapshot);
+}
+
+
// Initialize these first since AddDefaultDefinitions calls AddDefinition
this-WarnUnused = false;
this-CheckSystemVars = false;
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6034dc31bccb13b167ee7453bd3693c334e73c7e
commit 6034dc31bccb13b167ee7453bd3693c334e73c7e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Apr 25 16:36:48 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:32:42 2015 +0200
cmDefinitions: Externalize the Set logic.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index 58500c9..032a96e 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -11,6 +11,8 @@
*/
#include cmDefinitions.h
+#include assert.h
+
//
cmDefinitions::Def cmDefinitions::NoDef;
@@ -49,16 +51,7 @@ const char* cmDefinitions::Get(const std::string key)
void cmDefinitions::Set(const std::string key, const char* value)
{
Def def(value);
- if(this-Up || def.Exists)
-{
-// In lower scopes we store keys, defined or not.
-this-Map[key] = def;
-}
- else
-{
-// In the top-most scope we need not store undefined keys.
-this-Map.erase(key);
-}
+ this-Map[key] = def;
}
void cmDefinitions::Erase(const std::string key)
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 9da01db..7180c6c 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -78,7 +78,15 @@ public:
void RemoveDefinition(std::string const name)
{
-this-VarStack.top().Set(name, 0);
+if (this-VarStack.size() 1)
+ {
+ // In lower scopes we store keys, defined or not.
+ this-VarStack.top().Set(name, 0);
+ }
+else
+ {
+ this-VarStack.top().Erase(name);
+ }
}
std::setstd::string LocalKeys() const
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2679bb29b33a1f828221c31e7553687bbe7ce5b
commit b2679bb29b33a1f828221c31e7553687bbe7ce5b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Apr 25 16:33:26 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:29:21 2015 +0200
cmDefinitions: Add an Erase method.
diff --git a/Source/cmDefinitions.cxx
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
Why are we making the restriction more restrictive than it needs to be? We only need this for multiple targets and not within a single target. This is how I see it. 1. Using MAIN DEPENDENCY is a useful and desirable feature of FindCUDA. 2. A single input file can be used multiple time to generate different output files (think .cu to .ptx). This currently works without errors or warnings. 3. We add this check, and now projects that previously built without warnings must either: 3.a. Disable useful feature of MAIN DEPENDENCY 3.b. Turn policy off - the user may not even realize why this was triggered in the first place because this code was generated by FindCUDA. 3.c. User will need to go through and manually filter out which files can't have MAIN DEPENDENCY. 3.d FindCUDA disables MAIN DEPENDENCY by default to the detriment of all users. Ideally what should happen is: 1. MAIN DEPENDENCY issues cross targets should automatically be downgraded to DEPENDENCY with a warning. 2. MAIN DEPENDENCY within a target works as before. This will have the greatest backward compatibility and be of the most use to users. I'm also curious why specifying MAIN DEPENDENCY in make file generators has any special effect since according the documentation there be no functional difference. It seems like this is more a bug in how MAIN DEPENDENCY is being handled. Using warnings and errors to correct this seems a bit like the wrong solution. On Tue, Apr 28, 2015 at 1:10 AM Nils Gladitz nilsglad...@gmail.com wrote: On 04/27/2015 11:48 PM, James Bigler wrote: The problem is the current detection only barfs (unless I missed something - please correct if I'm wrong). What we need is detection and adaptation. Rather than telling the user, DON'T DO THAT! we should be helping the user out by saying, I know you wanted this to be attached as a MAIN_DEPENDENCY, but that doesn't work, so I'm going to help you out and disable this feature for this file. Then I can specify MAIN_DEPENDENCY and not worry about the collisions that cause problems. Yes, I prefer the deterministic barfing that diagnoses documented restrictions over elusive build failures. I am not opposed to your change if your implementation guarantees that the aforementioned build failures don't creep through again. If I understand correctly you would still output a warning diagnostic when degrading duplicate MAIN_DEPENDENCY? Not sure I would like that. Most CMake diagnostics generally imply something that the project developer can fix ... which isn't feasible if you make the behavior part of the design in FindCUDA.cmake. On the other hand the user may himself use MAIN_DEPENDENCY outside the scope of FindCUDA.cmake in which case silent degrading isn't optimal either ... but I guess I could live with that. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, master, updated. v3.2.2-938-gd1a74bb
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via d1a74bba1bba0c4381e7c3a6a93551320dc377ac (commit) from f0673c1022afdc9f9d91ea460efc6790b7aa6289 (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=d1a74bba1bba0c4381e7c3a6a93551320dc377ac commit d1a74bba1bba0c4381e7c3a6a93551320dc377ac Author: Kitware Robot kwro...@kitware.com AuthorDate: Wed Apr 29 00:01:05 2015 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Wed Apr 29 00:01:05 2015 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index d56ddf1..f76ba0d 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 2) -set(CMake_VERSION_PATCH 20150428) +set(CMake_VERSION_PATCH 20150429) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[cmake-developers] [CMake 0015538]: set_property(SOURCE ) not working for MASM assembly files within Visual Studio 2014 generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15538 == Reported By:Wolfgang Assigned To: == Project:CMake Issue ID: 15538 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-04-28 12:52 EDT Last Modified: 2015-04-28 12:52 EDT == Summary:set_property(SOURCE ) not working for MASM assembly files within Visual Studio 2014 generator Description: the generator now adds definitions and compiler flags to the masm command. Overwriting those parameters with SET_PROPERTY(SOURCE test.asm PROPERTY COMPILE_FLAGS my_asm_flags) and SET_PROPERTY(SOURCE test.asm PROPERTY COMPILE_DEFINITIONS my_definitions) is not respected == Issue History Date ModifiedUsername FieldChange == 2015-04-28 12:52 Wolfgang New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
Nils Gladitz wrote: On 04/28/2015 09:30 AM, Alan W. Irwin wrote: OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. Thanks, I implemented your suggestion: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853ef717;hp=397b6298602f1496d1b946f5db827f5807d6ed23 Thanks Nils, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
Andrey Pokrovskiy wrote: Hi, I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's dependencies. Some toolchain files have additional options (like API version, target architecture, linker type, etc.) which you need to pass to cmake command with -D in addition to the -DCMAKE_TOOLCHAIN_FILE= itself. There should be no need for that. With reference to what Brad wrote, you might find any of this interesting: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52129/focus=52142 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9578 Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] How to specify compiler only flags
On 04/28/2015 02:22 PM, Daniel Schepler wrote: As I understand it, configuration-specific properties are deprecated in favor of generator expressions. For example: target_compile_options(openjpeg PRIVATE $$CONFIG:Release:-ffast-math) Thanks, that helps. Perhaps not as simple as a global variable, but perhaps cleaner then too. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.2.2-2254-g1102fd7
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 1102fd70366672c8e0f3842f095bebda5ccbc8e9 (commit)
via 98048bd728af60b73d398350da50c8d6087b218a (commit)
from c82487f42eb97fcf0d0ed517f7724c8bc58cb082 (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=1102fd70366672c8e0f3842f095bebda5ccbc8e9
commit 1102fd70366672c8e0f3842f095bebda5ccbc8e9
Merge: c82487f 98048bd
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 18:17:19 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 18:17:19 2015 -0400
Merge topic 'refactor-cmDefinitions' into next
98048bd7 Revert topic.
diff --cc Source/cmMakefile.cxx
index 1853754,c77a90c..0935383
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@@ -51,150 -53,15 +53,32 @@@ public
};
// default is not to be building executables
-cmMakefile::cmMakefile(): Internal(new Internals)
+cmMakefile::cmMakefile(cmLocalGenerator* localGenerator)
+ : Internal(new Internals),
+LocalGenerator(localGenerator),
+StateSnapshot(localGenerator-GetGlobalGenerator()
+-GetCMakeInstance()-GetState())
{
- this-Internal-PushDefinitions();
- this-Internal-VarInitStack.push(std::setstd::string());
- this-Internal-VarUsageStack.push(std::setstd::string());
+ const cmDefinitions defs = cmDefinitions();
+ const std::setstd::string globalKeys = defs.LocalKeys();
+ this-Internal-VarStack.push(defs);
+ this-Internal-VarInitStack.push(globalKeys);
+ this-Internal-VarUsageStack.push(globalKeys);
this-Internal-IsSourceFileTryCompile = false;
+ if (this-LocalGenerator-GetParent())
+{
+cmMakefile* parentMf = this-LocalGenerator-GetParent()-GetMakefile();
+this-StateSnapshot =
+this-GetState()-CreateSnapshot(parentMf-StateSnapshot);
+}
+ else
+{
+this-StateSnapshot =
+this-GetState()-CreateSnapshot(this-StateSnapshot);
+}
+
+
// Initialize these first since AddDefaultDefinitions calls AddDefinition
this-WarnUnused = false;
this-CheckSystemVars = false;
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98048bd728af60b73d398350da50c8d6087b218a
commit 98048bd728af60b73d398350da50c8d6087b218a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Apr 29 00:16:20 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:16:29 2015 +0200
Revert topic.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index bf517e3..fe32dd5 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -11,105 +11,160 @@
*/
#include cmDefinitions.h
-#include assert.h
+//
+cmDefinitions::Def cmDefinitions::NoDef;
+
+//
+cmDefinitions::cmDefinitions(cmDefinitions* parent)
+ : Up(parent)
+{
+}
//
-std::pairconst char*, bool cmDefinitions::Get(const std::string key)
+void cmDefinitions::Reset(cmDefinitions* parent)
+{
+ this-Up = parent;
+ this-Map.clear();
+}
+
+//
+cmDefinitions::Def const
+cmDefinitions::GetInternal(const std::string key)
{
MapType::const_iterator i = this-Map.find(key);
- std::pairconst char*, bool result((const char*)0, false);
if(i != this-Map.end())
{
-result = std::make_pair(i-second.Exists ? i-second.c_str() : 0, true);
+return i-second;
+}
+ if(cmDefinitions* up = this-Up)
+{
+// Query the parent scope and store the result locally.
+Def def = up-GetInternal(key);
+return this-Map.insert(MapType::value_type(key, def)).first-second;
}
- return result;
+ return this-NoDef;
}
//
-void cmDefinitions::Set(const std::string key, const char* value)
+cmDefinitions::Def const
+cmDefinitions::SetInternal(const std::string key, Def const def)
{
- Def def(value);
- this-Map[key] = def;
+ if(this-Up || def.Exists)
+{
+// In lower scopes we store keys, defined or not.
+return (this-Map[key] = def);
+}
+ else
+{
+// In the top-most scope we need not store undefined keys.
+this-Map.erase(key);
+return this-NoDef;
+}
}
-void cmDefinitions::Erase(const std::string key)
Re: [CMake] How to specify compiler only flags
As I understand it, configuration-specific properties are deprecated in favor
of generator expressions. For example:
target_compile_options(openjpeg PRIVATE
$$CONFIG:Release:-ffast-math)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Orion Poplawski
[or...@cora.nwra.com]
Sent: Tuesday, April 28, 2015 1:15 PM
To: CMake Mailing List
Subject: [CMake] How to specify compiler only flags
I'm trying to patch the CMakeLists.txt for openjpeg. Currently it does:
# Do not use ffast-math for all build, it would produce incorrect results,
only set for release:
SET(CMAKE_C_FLAGS_RELEASE -ffast-math ${CMAKE_C_FLAGS_RELEASE})
Unfortunately, CMAKE_C_FLAGS are also used in link step, which for -ffast-math
causes problems for users of the shared library.
I'm unable to find an equivalent flag that is for compiling only. I see I can
set the COMPILE_FLAGS property for the library, but there does not appear to
be a COMPILE_FLAGS_RELEASE property that would only set it for the Release
build type.
Suggestions?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 04/28/2015 04:15 PM, Alan W. Irwin wrote:
The problem is I am reporting the problem second-hand, and I don't
have access to a Cygwin platform myself. But from the report I
received the incorrect warning message occurs each time a different
compiler is enabled.
The patch to plplot below removes most of the warnings for me.
-Brad
diff --git a/cmake/modules/language_support.cmake
b/cmake/modules/language_support.cmake
index 2cf5c95..333eb99 100644
--- a/cmake/modules/language_support.cmake
+++ b/cmake/modules/language_support.cmake
@@ -12,7 +12,8 @@ if(ENABLE_workaround_9220)
function(workaround_9220 language language_works)
#message(DEBUG: language = ${language})
set(text
- project(test C)
+ cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
+project(test C)
# Locations where PLplot cmake build system first looks for cmake modules.
set(CMAKE_MODULE_PATH
${PROJECT_SOURCE_DIR}/cmake/modules
@@ -26,7 +27,6 @@ if(NOT CMAKE_PLATFORM_INFO_DIR)
message(STATUS 'CMAKE_PLATFORM_INFO_DIR = \${CMAKE_PLATFORM_INFO_DIR}')
endif(NOT CMAKE_PLATFORM_INFO_DIR)
-cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
message(STATUS \CMAKE_GENERATOR = ${CMAKE_GENERATOR}\)
#enable_language(${language} OPTIONAL)
enable_language(${language})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 2015-04-28 16:44-0400 Brad King wrote: On 04/28/2015 04:15 PM, Alan W. Irwin wrote: The problem is I am reporting the problem second-hand, and I don't have access to a Cygwin platform myself. But from the report I received the incorrect warning message occurs each time a different compiler is enabled. The patch to plplot below removes most of the warnings for me. Hi Brad: That is a really interesting result. I notice your patch for PLplot simply makes sure that cmake_minimum_required(...) occurs before project(...) (for this part of PLplot). Just to confirm all of this in a simple way outside of PLplot, if the simple test I suggested has its two lines swapped so that project(...) occurs before cmake_minimum_required(...), does that also generate the spurious message on Cygwin? Assuming that simple confirmation of the required ordering of those two CMake commands (at least on the Cygwin platform if not others), I notice there is no mention of such ordering in the CMake documentation of cmake_minimum_required() and project(), and I hope you will be willing to fix that documentation issue with something like For best results it is highly recommended that the cmake_minimum_required command appear before the project command in the documentation of both commands. Also, a spurious warning is probably not that big a deal, but if you think the incorrect order of project(...) before cmake_minimum_required(...) could lead to more serious issues now or in the future as Platform code gets more and more complex, then I suggest you implement some code for one of those commands that enforces that order, subject, of course, to a policy so that you do not introduce backwards incompatibilities with this change. Since there are still some remaining spurious warnings on PLplot for you after you applied your patch, I took a look throughout our source code, and it turns out that misordering issue occurs a lot of different places (except for our top-level CMakeLists.txt which has the correct ordering). So I plan to address all of those ordering issues, and I hope that will eliminate all these spurious warnings for PLplot on Cygwin (and maybe make the PLplot build system more reliable on all platforms if potentially there are more serious issues if those two statements are misordered). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.2.2-2258-gdd4fb08
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 dd4fb08a0bfc3179f8f7d1ff5c1e95a2101e04ac (commit)
via a3358faca1aba179ce6670460f259ab247b44cd4 (commit)
via 23370344427ce8da470ff6266a675150457fdda2 (commit)
via b9f4dd39bb3878ef1fbb0b5b6bc23bab5425584d (commit)
from 1102fd70366672c8e0f3842f095bebda5ccbc8e9 (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=dd4fb08a0bfc3179f8f7d1ff5c1e95a2101e04ac
commit dd4fb08a0bfc3179f8f7d1ff5c1e95a2101e04ac
Merge: 1102fd7 a3358fa
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 18:27:22 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 18:27:22 2015 -0400
Merge topic 'clean-up-cmDefinitions' into next
a3358fac cmDefinitions: Inline SetInternal method.
23370344 cmDefinitions: Remove unused Set return value.
b9f4dd39 cmDefinitions: Remove unused method.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3358faca1aba179ce6670460f259ab247b44cd4
commit a3358faca1aba179ce6670460f259ab247b44cd4
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Apr 26 11:33:47 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:18:13 2015 +0200
cmDefinitions: Inline SetInternal method.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index d5f6ebc..abb46b3 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -39,9 +39,16 @@ cmDefinitions::GetInternal(const std::string key)
}
//
-cmDefinitions::Def const
-cmDefinitions::SetInternal(const std::string key, Def const def)
+const char* cmDefinitions::Get(const std::string key)
{
+ Def const def = this-GetInternal(key);
+ return def.Exists? def.c_str() : 0;
+}
+
+//
+void cmDefinitions::Set(const std::string key, const char* value)
+{
+ Def def(value);
if(this-Up || def.Exists)
{
// In lower scopes we store keys, defined or not.
@@ -55,19 +62,6 @@ cmDefinitions::SetInternal(const std::string key, Def
const def)
}
//
-const char* cmDefinitions::Get(const std::string key)
-{
- Def const def = this-GetInternal(key);
- return def.Exists? def.c_str() : 0;
-}
-
-//
-void cmDefinitions::Set(const std::string key, const char* value)
-{
- this-SetInternal(key, Def(value));
-}
-
-//
std::setstd::string cmDefinitions::LocalKeys() const
{
std::setstd::string keys;
diff --git a/Source/cmDefinitions.h b/Source/cmDefinitions.h
index 690df1f..83cd0d9 100644
--- a/Source/cmDefinitions.h
+++ b/Source/cmDefinitions.h
@@ -78,7 +78,6 @@ private:
// Internal query and update methods.
Def const GetInternal(const std::string key);
- Def const SetInternal(const std::string key, Def const def);
// Implementation of Closure() method.
struct ClosureTag {};
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23370344427ce8da470ff6266a675150457fdda2
commit 23370344427ce8da470ff6266a675150457fdda2
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Apr 25 16:29:54 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 29 00:18:13 2015 +0200
cmDefinitions: Remove unused Set return value.
diff --git a/Source/cmDefinitions.cxx b/Source/cmDefinitions.cxx
index 6a27659..d5f6ebc 100644
--- a/Source/cmDefinitions.cxx
+++ b/Source/cmDefinitions.cxx
@@ -45,13 +45,12 @@ cmDefinitions::SetInternal(const std::string key, Def
const def)
if(this-Up || def.Exists)
{
// In lower scopes we store keys, defined or not.
-return (this-Map[key] = def);
+this-Map[key] = def;
}
else
{
// In the top-most scope we need not store undefined keys.
this-Map.erase(key);
-return this-NoDef;
}
}
@@ -63,10 +62,9 @@ const char* cmDefinitions::Get(const std::string key)
}
//
-const char* cmDefinitions::Set(const std::string key, const char* value)
+void cmDefinitions::Set(const std::string key, const char* value)
{
- Def const def = this-SetInternal(key, Def(value));
- return def.Exists? def.c_str() : 0;
+ this-SetInternal(key, Def(value));
}
//
diff --git
[Cmake-commits] CMake branch, next, updated. v3.2.2-2237-gf257a96
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 f257a96641455634959ffef001040e03377e0282 (commit) via 853ef717aa4bc167bb0165f7fb20723901f37163 (commit) from d70c4bfbee1754595bde4ee0cc2f0e4efb35cebb (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=f257a96641455634959ffef001040e03377e0282 commit f257a96641455634959ffef001040e03377e0282 Merge: d70c4bf 853ef71 Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Tue Apr 28 04:48:13 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 04:48:13 2015 -0400 Merge topic 'CMP0026-doc-title' into next 853ef717 Help: Clarify policy CMP0026 title http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853ef717aa4bc167bb0165f7fb20723901f37163 commit 853ef717aa4bc167bb0165f7fb20723901f37163 Author: Nils Gladitz nilsglad...@gmail.com AuthorDate: Tue Apr 28 10:44:37 2015 +0200 Commit: Nils Gladitz nilsglad...@gmail.com CommitDate: Tue Apr 28 10:44:37 2015 +0200 Help: Clarify policy CMP0026 title Clarify that the policy only applies to build targets and not e.g. imported targets. Suggested-by: Alan W. Irwin diff --git a/Help/policy/CMP0026.rst b/Help/policy/CMP0026.rst index 177b655..4889249 100644 --- a/Help/policy/CMP0026.rst +++ b/Help/policy/CMP0026.rst @@ -1,7 +1,7 @@ CMP0026 --- -Disallow use of the LOCATION target property. +Disallow use of the LOCATION property for build targets. CMake 2.8.12 and lower allowed reading the LOCATION target property (and configuration-specific variants) to --- Summary of changes: Help/policy/CMP0026.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
On 04/28/2015 09:30 AM, Alan W. Irwin wrote: OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. Thanks, I implemented your suggestion: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853ef717;hp=397b6298602f1496d1b946f5db827f5807d6ed23 Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] Identify used source files
May be more clean and efficient to use CMake property SOURCES:
For example:
add_library (MY_LIB src1.cpp src2.cpp)
get_target_property (lib_sources MY_LIB SOURCES)
And variable lib_sources now contains list of sources associated with target.
On 28/04/15 10:30, Roman Wüger roman.wue...@gmx.at wrote:
If someone is interessted in this solution:
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs}
${multiValueArgs}${ARGN} )
foreach(file ${ARGN})
get_filename_component(tempPath ${file} DIRECTORY)
string(FIND ${file} ${CMAKE_BINARY_DIR}buildPathFoundPos)
string(FIND ${file} ${CMAKE_SOURCE_DIR}sourcePathFoundPos)
if ((NOT ${file} STREQUALIMPORTED) AND
(NOT ${file} STREQUAL MODULE)AND
(NOT ${file} STREQUAL STATIC)AND
(NOT ${file} STREQUAL SHARED)AND
(NOT ${file} STREQUAL WIN32)AND
${buildPathFoundPos} EQUAL -1)
if (${sourcePathFoundPos} EQUAL -1)
file(APPEND ${FilenameUsedFiles}
${CMAKE_CURRENT_SOURCE_DIR}/${file}\n)
else()
file(APPEND ${FilenameUsedFiles} ${file}\n)
endif()
endif()
endforeach()
endfunction(parseArguments)
function(add_library name)
parseArguments(${ARGN})
_add_library(${name} ${ARGN})
endfunction()
function(add_executable name)
parseArguments(${ARGN})
_add_executable(${name} ${ARGN})
endfunction()
Best Regards
Roman
Am 28.04.2015 um 07:00 schrieb Roman Wüger roman.wue...@gmx.at:
Hello,
is there a proper solution to get all used source files for all defined
librarys and executables?
My first idea was to overload the main functions such as add_executable()
and add_library() temporarily in the main CMakeLists.txt and write a text
file or whatever, but I thought there were a better way.
Did anybody know a better way?
Maybe CMake has a way to get a list of used files?
The reason is to clean a big old source tree.
Thanks in advance
Best regards
Roman
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] (no subject)
Hello guys,
I use multi-configuration generator (MSVC 2008) and I need to create
one solution containing two configurations for one library target N:
For build type Debug target N is compiled as static library
For build type Release target N is compiled as shared library
Something like this, but I know that I can't use CMAKE_BUILD_TYPE
variable when I use multi-configuration generator:
cmake_minimum_required (VERSION 2.8.11)
project (hello)
if(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_library(hello STATIC main.cpp)
elseif(${CMAKE_BUILD_TYPE} STREQUAL Release)
add_library(hello SHARED main.cpp)
endif()
I already used CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE
to distinguish some attributes between Debug and Release, but I can't
figure it out in case of the library type (SHARED vs STATIC).
Any ideas how to achieve it?
Thanks
Lukas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Generator Expressions in CPack (Module) variables
Hello Nils,
thank you for the pointers.
On 24/04/15 21:30, Nils Gladitz wrote:
On 24.04.2015 20:55, Gregor Jasny wrote:
Hello,
would it be possible to add generator expression support to CPack
so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
using the CPack module from within my CMakeLists.txt.
I'm trying to generate unique file names per architecture and
configuration but multi config generators like Xcode make this
harder than expected.
You should be able to do this without generator expressions and just
CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2].
If you really do require/want generator expressions you should be able
to combine that with file(GENERATE) and include().
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this
option is only added conditionally and omitted for Makefile builds:
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
if ( cmakeCfgIntDir *cmakeCfgIntDir cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}
Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG
is the right thing to do?
Thanks,
Gregor
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator Expressions in CPack (Module) variables
On 04/28/2015 10:57 AM, Gregor Jasny wrote:
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this
option is only added conditionally and omitted for Makefile builds:
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
if ( cmakeCfgIntDir *cmakeCfgIntDir cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}
Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG
is the right thing to do?
I don't know ... but as a local workaround you might be able to set
CPACK_BUILD_CONFIG before include(CPack) conditionally when using
single-configuration generators.
Assuming nothing else messes with CMAKE_BUILD_TYPE when using
multi-configuration generators e.g.:
if(CMAKE_BUILD_TYPE)
set(CPACK_BUILD_TYPE ${CMAKE_BUILD_TYPE})
endif()
include(CPack)
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
Hi Nils: Thanks for your quick reply. More below in context. On 2015-04-28 08:45+0200 Nils Gladitz wrote: On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. CMP0026 only applies to build targets. The location of build targets is still in flux during configuration which is why getting the location of those during configuration time is unsafe. For imported targets this does not apply since their location is fixed. OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. I took that summary line to mean exactly what it said and just plain missed the reference to build targets that is in the first paragraph of that documenation. For which configuration LOCATION returns isn't defined but I suppose that may not matter for pkg-config. Otherwise you may want to look into LOCATION_CONFIG. I don't understand exactly what you mean by configuration LOCATION returns. From what you said that term means something different from LOCATION_CONFIG and in any case is not relevant to my use case of generating pkg-config *.pc files with our build system, but I am nevertheless curious about what you meant.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
On 04/28/2015 09:30 AM, Alan W. Irwin wrote: I don't understand exactly what you mean by configuration LOCATION returns. From what you said that term means something different from LOCATION_CONFIG and in any case is not relevant to my use case of generating pkg-config *.pc files with our build system, but I am nevertheless curious about what you meant.) E.g. on windows with MSVC cmake target exports may refer to locations of both a Debug and a Release binary. LOCATION returns the path to one of those two (you don't know which). LOCATION_DEBUG and LOCATION_RELEASE would refer to the Debug and Release binary respectively. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator Expressions in CPack (Module) variables
2015-04-28 10:57 GMT+02:00 Gregor Jasny gja...@googlemail.com:
Hello Nils,
thank you for the pointers.
On 24/04/15 21:30, Nils Gladitz wrote:
On 24.04.2015 20:55, Gregor Jasny wrote:
Hello,
would it be possible to add generator expression support to CPack
so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
using the CPack module from within my CMakeLists.txt.
From my understanding $CONFIG is a build time value.
evaluating $CONFIG at CPack time may be hard because
one can simply call:
cpack -G generator
then CONFIG definition is implicit and only known when the build tool is
called...
I'm trying to generate unique file names per architecture and
configuration but multi config generators like Xcode make this
harder than expected.
You should be able to do this without generator expressions and just
CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2].
If you really do require/want generator expressions you should be able
to combine that with file(GENERATE) and include().
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this option
is only added conditionally and omitted for Makefile builds:
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
if ( cmakeCfgIntDir *cmakeCfgIntDir cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}
Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG is
the right thing to do?
If it is possible to always define it may be it could be done.
Beware of backward compatibility issue though.
--
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.2.2-2243-g47b1c21
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 47b1c217da98c778d5fe74c7545a14290d752a81 (commit) via 7244e8452fc9e99c613d8fb098903608d96cf73a (commit) via f693c136f94c8a21857b8bf4eff944ab57f73765 (commit) via 5cbedd6b8527dc265d50c877c1e4b3977a6dd23f (commit) from 434c868fbb597a1b2694e4a2b25df6055c388035 (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=47b1c217da98c778d5fe74c7545a14290d752a81 commit 47b1c217da98c778d5fe74c7545a14290d752a81 Merge: 434c868 7244e84 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:32:40 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:32:40 2015 -0400 Merge topic 'doc-CTEST_USE_LAUNCHERS-ninja' into next 7244e845 ctest: Consolidate documentation of CTEST_USE_LAUNCHERS (#15533) f693c136 Modules/CTest: Improve documentation formatting 5cbedd6b Modules/CTest: Use bracket comment for documentation block http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7244e8452fc9e99c613d8fb098903608d96cf73a commit 7244e8452fc9e99c613d8fb098903608d96cf73a Author: Brad King brad.k...@kitware.com AuthorDate: Mon Apr 27 10:34:24 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Apr 28 13:32:23 2015 -0400 ctest: Consolidate documentation of CTEST_USE_LAUNCHERS (#15533) The documentation of this variable in the CTest module is outdated and has been superseded by the ctest(1) manual. In particular, the latter mentions that it works with the Ninja generator as well as makefile generators. Remove the documentation from the CTest module and replace it with a link to the main variable documentation (which already references the ctest(1) manual). diff --git a/Help/manual/ctest.1.rst b/Help/manual/ctest.1.rst index d0ac28d..c91321b 100644 --- a/Help/manual/ctest.1.rst +++ b/Help/manual/ctest.1.rst @@ -372,6 +372,8 @@ Options .. include:: OPTIONS_HELP.txt +.. _`Dashboard Client`: + Dashboard Client @@ -749,8 +751,9 @@ Configuration settings include: initialized by the :command:`build_command` command ``UseLaunchers`` - For build trees generated by CMake using a Makefile generator - or the :generator:`Ninja` generator, specify whether the + For build trees generated by CMake using one of the + :ref:`Makefile Generators` or the :generator:`Ninja` + generator, specify whether the ``CTEST_USE_LAUNCHERS`` feature is enabled by the :module:`CTestUseLaunchers` module (also included by the :module:`CTest` module). When enabled, the generated build diff --git a/Modules/CTest.cmake b/Modules/CTest.cmake index fccef4f..8278c5c 100644 --- a/Modules/CTest.cmake +++ b/Modules/CTest.cmake @@ -40,21 +40,12 @@ While building a project for submission to CDash, CTest scans the build output for errors and warnings and reports them with surrounding context from the build log. This generic approach works for all build tools, but does not give details about the command invocation that -produced a given problem. One may get more detailed reports by adding:: +produced a given problem. One may get more detailed reports by setting +the :variable:`CTEST_USE_LAUNCHERS` variable:: set(CTEST_USE_LAUNCHERS 1) -to the ``CTestConfig.cmake`` file. When this option is enabled, the CTest -module tells CMake's Makefile generators to invoke every command in -the generated build system through a CTest launcher program. -(Currently the ``CTEST_USE_LAUNCHERS`` option is ignored on non-Makefile -generators.) During a manual build each launcher transparently runs -the command it wraps. During a CTest-driven build for submission to -CDash each launcher reports detailed information when its command -fails or warns. (Setting ``CTEST_USE_LAUNCHERS`` in ``CTestConfig.cmake`` is -convenient, but also adds the launcher overhead even for manual -builds. One may instead set it in a CTest dashboard script and add it -to the CMake cache for the build tree.) +in the ``CTestConfig.cmake`` file. #]===] #= http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f693c136f94c8a21857b8bf4eff944ab57f73765 commit f693c136f94c8a21857b8bf4eff944ab57f73765 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Apr 27 10:32:53 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Apr 28 13:32:23 2015 -0400 Modules/CTest: Improve documentation formatting Use inline
[Cmake-commits] CMake branch, master, updated. v3.2.2-935-g9de73d7
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 9de73d7ee51073841e0aea83096c187ea365532e (commit) via 8d9f39f4c324db01d5a60c5a783e1c44180c5c4c (commit) from c0989eaf2afeebaedfdec4d42fdeb344b867c4f8 (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=9de73d7ee51073841e0aea83096c187ea365532e commit 9de73d7ee51073841e0aea83096c187ea365532e Merge: c0989ea 8d9f39f Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:55 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:55 2015 -0400 Merge topic 'include-early-optional-handling' 8d9f39f4 include: Ask for permission, rather than forgiveness. --- Summary of changes: Source/cmIncludeCommand.cxx | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-931-g70d54b0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 70d54b03fd4bae28fd2ff7fe9f3ede1dc50a994a (commit) via ff183986df719bfee0abd1f8c1e09dc348f04bd5 (commit) from 5b8c5a6c0bc072ebb79c77f30d2b073d7b9fe4ec (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=70d54b03fd4bae28fd2ff7fe9f3ede1dc50a994a commit 70d54b03fd4bae28fd2ff7fe9f3ede1dc50a994a Merge: 5b8c5a6 ff18398 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:52 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:52 2015 -0400 Merge topic 'InstallRequiredSystemLibraries-fix-mbcs' ff183986 InstallRequiredSystemLibraries: Fix MBCS MFC detection (#15531) --- Summary of changes: Modules/InstallRequiredSystemLibraries.cmake |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-925-gdd675d4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via dd675d45faa10de5b9eb4be977e65eae9036bc48 (commit) via 7244e8452fc9e99c613d8fb098903608d96cf73a (commit) via f693c136f94c8a21857b8bf4eff944ab57f73765 (commit) via 5cbedd6b8527dc265d50c877c1e4b3977a6dd23f (commit) from 4541d1ca9a44ee5d79b641673e79947b16b79642 (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=dd675d45faa10de5b9eb4be977e65eae9036bc48 commit dd675d45faa10de5b9eb4be977e65eae9036bc48 Merge: 4541d1c 7244e84 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:46 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:46 2015 -0400 Merge topic 'doc-CTEST_USE_LAUNCHERS-ninja' 7244e845 ctest: Consolidate documentation of CTEST_USE_LAUNCHERS (#15533) f693c136 Modules/CTest: Improve documentation formatting 5cbedd6b Modules/CTest: Use bracket comment for documentation block --- Summary of changes: Help/manual/ctest.1.rst |7 ++- Modules/CTest.cmake | 114 --- 2 files changed, 54 insertions(+), 67 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-937-gf0673c1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f0673c1022afdc9f9d91ea460efc6790b7aa6289 (commit) via bf24b6c501f1f8c9146153038bb202ae246de7d0 (commit) from 9de73d7ee51073841e0aea83096c187ea365532e (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=f0673c1022afdc9f9d91ea460efc6790b7aa6289 commit f0673c1022afdc9f9d91ea460efc6790b7aa6289 Merge: 9de73d7 bf24b6c Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:57 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:57 2015 -0400 Merge topic 'deterministic-CTest-tests' bf24b6c5 Tests: Guard more CTest tests against parallel execution. --- Summary of changes: Tests/CMakeLists.txt |2 ++ Tests/RunCMake/ctest_memcheck/RunCMakeTest.cmake |2 ++ 2 files changed, 4 insertions(+) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-927-g248a58e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 248a58e790c57a6c8502e5acd0a42098c80fcfa4 (commit) via 4fc47424774657a44fc6ac118d1d1abb360db38c (commit) from dd675d45faa10de5b9eb4be977e65eae9036bc48 (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=248a58e790c57a6c8502e5acd0a42098c80fcfa4 commit 248a58e790c57a6c8502e5acd0a42098c80fcfa4 Merge: dd675d4 4fc4742 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:48 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:48 2015 -0400 Merge topic 'test-ExportImport-AIX-GCC' 4fc47424 Tests: Fix ExportImport on AIX with GCC --- Summary of changes: Tests/ExportImport/Import/A/CMakeLists.txt |1 + 1 file changed, 1 insertion(+) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-929-g5b8c5a6
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 5b8c5a6c0bc072ebb79c77f30d2b073d7b9fe4ec (commit) via 1b03332eeeff471ea6da498bfe64bda3296e9ac5 (commit) from 248a58e790c57a6c8502e5acd0a42098c80fcfa4 (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=5b8c5a6c0bc072ebb79c77f30d2b073d7b9fe4ec commit 5b8c5a6c0bc072ebb79c77f30d2b073d7b9fe4ec Merge: 248a58e 1b03332 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:50 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:50 2015 -0400 Merge topic 'doc-sizeof_void_p' 1b03332e Help: Clarify that CMAKE_SIZEOF_VOID_P is specific to the target machine --- Summary of changes: Help/variable/CMAKE_SIZEOF_VOID_P.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-933-gc0989ea
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via c0989eaf2afeebaedfdec4d42fdeb344b867c4f8 (commit) via c46490dad525e5f5e10eba12808718340ad40ace (commit) from 70d54b03fd4bae28fd2ff7fe9f3ede1dc50a994a (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=c0989eaf2afeebaedfdec4d42fdeb344b867c4f8 commit c0989eaf2afeebaedfdec4d42fdeb344b867c4f8 Merge: 70d54b0 c46490d Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:54 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:54 2015 -0400 Merge topic 'fix-osx-framework-detection' c46490da cmSystemTools: Fix IsPathToFramework implementation (#15535) --- Summary of changes: Source/cmSystemTools.cxx | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.2.2-921-g4541d1c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 4541d1ca9a44ee5d79b641673e79947b16b79642 (commit) via 75bd5ca06ac35be95dfb5bb9442dd9391fc43a5c (commit) from 397b6298602f1496d1b946f5db827f5807d6ed23 (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=4541d1ca9a44ee5d79b641673e79947b16b79642 commit 4541d1ca9a44ee5d79b641673e79947b16b79642 Merge: 397b629 75bd5ca Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:55:44 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Apr 28 13:55:44 2015 -0400 Merge topic 'fix-test-RunCMake.CTest-line-numbers' 75bd5ca0 Tests: Fix RunCMake.CTest to tolerate source line number changes --- Summary of changes: Tests/RunCMake/CTest/BeforeProject-stderr.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.2.2-2252-gc82487f
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 c82487f42eb97fcf0d0ed517f7724c8bc58cb082 (commit) via f0673c1022afdc9f9d91ea460efc6790b7aa6289 (commit) via 9de73d7ee51073841e0aea83096c187ea365532e (commit) via c0989eaf2afeebaedfdec4d42fdeb344b867c4f8 (commit) via 70d54b03fd4bae28fd2ff7fe9f3ede1dc50a994a (commit) via 5b8c5a6c0bc072ebb79c77f30d2b073d7b9fe4ec (commit) via 248a58e790c57a6c8502e5acd0a42098c80fcfa4 (commit) via dd675d45faa10de5b9eb4be977e65eae9036bc48 (commit) via 4541d1ca9a44ee5d79b641673e79947b16b79642 (commit) from 47b1c217da98c778d5fe74c7545a14290d752a81 (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=c82487f42eb97fcf0d0ed517f7724c8bc58cb082 commit c82487f42eb97fcf0d0ed517f7724c8bc58cb082 Merge: 47b1c21 f0673c1 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Apr 28 13:56:17 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Apr 28 13:56:17 2015 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 04/27/2015 05:53 PM, Alan W. Irwin wrote: Anybody here got a clue about what is going on? Please strip it down to a minimal example. That will either find the culprit or provide a test case we can use independently. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] What is the proper way to export targets that will be split into separate binary packages?
On 2015-04-28 11:57+0200 Nils Gladitz wrote:
On 04/28/2015 11:43 AM, Alan W. Irwin wrote:
@Nils: the origin of the code right below If COMPONENTS... is not
clear. Is that code that should be supplied by a package creator or
code that
should be implemented by every find_package user? And if it should be
supplied by a package creator, does the install(EXPORT...) signature
generate that code automatically, does one of the helper functions
that are available generate that code, or do I (as package creator)
have to supply that code some other way?
The package configuration file is normally handwritten (or handgenerated) by
the package creator. I assume you already have one? e.g. plplotConfig.cmake.
Yes, I did implement such a file a while back to bring the previous
crude export stuff (implemented years ago before the idea of cmake
packages were even thought of) into compliance with the idea of cmake
packages. However, now that you have reminded me of that file, it
turns out it is only slightly more than a placeholder. So clearly
some work is required to fully modernize this part of the PLplot build
system.
http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages
@Alex: Sorry I missed your reply until now.
@Alex or Nils:
The problem with the URL provided by Nils is only one library is used
in the example so I don't understand exactly what you guys are
suggesting for the multiple library/component case.
For example, are you recommending
install(TARGETS plplot1 EXPORT export_plplot ...)
[...]
install(TARGETS plplotN EXPORT export_plplot ...)
for N installed libraries followed by
install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot)
? That is the current pattern I am using with one overall export name
called export_plplot. Or would you recommend this different pattern
install(TARGETS plplot1 EXPORT export_plplot1 ...)
install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot)
[...]
install(TARGETS plplotN EXPORT export_plplotN ...)
install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot)
(i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures
with each pair having a unique export name)?
Yes, unique/distinct export names and export files.
That way the target export files can go into the respective distribution
package that they represent.
The umbrella package configuration file would be installed by your core
package and would then be able to pick up the currently available target
export files.
Thanks for that clarification.
You referred in a later post to the granularity required. To give you
some idea of the scope of the problem, there are currently ~30 PLplot
targets which are EXPORTed. I obviously do not want to set up 30
different package components to correspond to those individual targets
since that implies maintenance issues (for users to keep track of all
those possible components). On the other hand, the current
granularity requirements of the Linux packagers vary quite a lot
between distros (e.g., Debian packagers tend to split PLplot binary
packages differently than Fedora packagers) probably because upstream
PLplot has not given them any splitting guidance until now. So I will
have to think carefully about what component granularity we should
supply.
Anyhow, you have given me lots of food for thought here, and I
appreciate that!
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] Is there a way to avoid LOCATION property with Qt5?
The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. CMP0026 only applies to build targets. The location of build targets is still in flux during configuration which is why getting the location of those during configuration time is unsafe. For imported targets this does not apply since their location is fixed. For which configuration LOCATION returns isn't defined but I suppose that may not matter for pkg-config. Otherwise you may want to look into LOCATION_CONFIG. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.2.2-2235-gd70c4bf
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 d70c4bfbee1754595bde4ee0cc2f0e4efb35cebb (commit)
via 46f6a5f458d7d9ef074820d3e90960af2793bd33 (commit)
via 3a041c59495df26c2b7b0ee58069d27a03bd18ff (commit)
via ae6c8a9d68120229a2960a83b51241fdb926700a (commit)
via 86f3cd0f7e0e0a0db210b5ed3f01766624dbc67f (commit)
via a48aebcb67a66bd2fee1318bb971cc5e3b016410 (commit)
via e4c78b37cec74c505e8a4951276c17f7e64e5f67 (commit)
via 410f39a43ef3ad900bcaed15e6838f97f034f0e7 (commit)
via 397b6298602f1496d1b946f5db827f5807d6ed23 (commit)
from 69b8d8e4f6f6c3ad1520050ecd6bf355c8e8d3da (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=d70c4bfbee1754595bde4ee0cc2f0e4efb35cebb
commit d70c4bfbee1754595bde4ee0cc2f0e4efb35cebb
Merge: 69b8d8e 46f6a5f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 02:04:03 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Apr 28 02:04:03 2015 -0400
Merge topic 'cmState-CurrentDirs' into next
46f6a5f4 cmState: Store the Current directories.
3a041c59 Introduce cmState::Snapshot.
ae6c8a9d cmState: Store the Source and Binary directories.
86f3cd0f cmMakefile: Require the localGenerator in the constructor.
a48aebcb cmLocalGenerator: Require a parent in the constructor.
e4c78b37 cmMakefile: Inline SetHome* methods into last remaining caller.
410f39a4 cmMakefile: Delegate storage of Home dirs to the cmake class.
397b6298 CMake Nightly Date Stamp
diff --cc Source/cmMakefile.cxx
index b46c99f,0935383..1853754
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@@ -171,13 -53,32 +171,30 @@@ public
};
// default is not to be building executables
- cmMakefile::cmMakefile(): Internal(new Internals)
+ cmMakefile::cmMakefile(cmLocalGenerator* localGenerator)
+ : Internal(new Internals),
+ LocalGenerator(localGenerator),
+ StateSnapshot(localGenerator-GetGlobalGenerator()
+ -GetCMakeInstance()-GetState())
{
- const cmDefinitions defs = cmDefinitions();
- const std::setstd::string globalKeys = defs.LocalKeys();
- this-Internal-VarStack.push(defs);
- this-Internal-VarInitStack.push(globalKeys);
- this-Internal-VarUsageStack.push(globalKeys);
+ this-Internal-PushDefinitions();
+ this-Internal-VarInitStack.push(std::setstd::string());
+ this-Internal-VarUsageStack.push(std::setstd::string());
this-Internal-IsSourceFileTryCompile = false;
+ if (this-LocalGenerator-GetParent())
+ {
+ cmMakefile* parentMf = this-LocalGenerator-GetParent()-GetMakefile();
+ this-StateSnapshot =
+ this-GetState()-CreateSnapshot(parentMf-StateSnapshot);
+ }
+ else
+ {
+ this-StateSnapshot =
+ this-GetState()-CreateSnapshot(this-StateSnapshot);
+ }
+
+
// Initialize these first since AddDefaultDefinitions calls AddDefinition
this-WarnUnused = false;
this-CheckSystemVars = false;
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46f6a5f458d7d9ef074820d3e90960af2793bd33
commit 46f6a5f458d7d9ef074820d3e90960af2793bd33
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Apr 28 07:50:31 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Apr 28 07:57:21 2015 +0200
cmState: Store the Current directories.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 5d48f58..0935383 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1647,33 +1647,27 @@ void cmMakefile::AddSubDirectory(const std::string
srcPath,
void cmMakefile::SetCurrentSourceDirectory(const std::string dir)
{
- this-cmStartDirectory = dir;
- cmSystemTools::ConvertToUnixSlashes(this-cmStartDirectory);
- this-cmStartDirectory =
-cmSystemTools::CollapseFullPath(this-cmStartDirectory);
+ this-StateSnapshot.SetCurrentSourceDirectory(dir);
this-AddDefinition(CMAKE_CURRENT_SOURCE_DIR,
- this-cmStartDirectory.c_str());
+ this-StateSnapshot.GetCurrentSourceDirectory());
}
const char* cmMakefile::GetCurrentSourceDirectory() const
{
- return this-cmStartDirectory.c_str();
+ return this-StateSnapshot.GetCurrentSourceDirectory();
}
void cmMakefile::SetCurrentBinaryDirectory(const std::string dir)
{
- this-StartOutputDirectory = dir;
- cmSystemTools::ConvertToUnixSlashes(this-StartOutputDirectory);
- this-StartOutputDirectory =
-cmSystemTools::CollapseFullPath(this-StartOutputDirectory);
- cmSystemTools::MakeDirectory(this-StartOutputDirectory.c_str());
-
Re: [CMake] What is the proper way to export targets that will be split into separate binary packages?
On 04/28/2015 01:20 AM, Alan W. Irwin wrote: On 2015-04-24 12:33-0700 Alan W. Irwin wrote: This should be a pretty common issue on Linux since it is quite typical there that downstream packaging splits up binary results into different packages. Therefore, I assume there is a CMake solution to this issue, and I would appreciate those who know that solution to speak up. I'd go with what Alex suggested in his reply. In effect it is what e.g. Qt5 does (though they don't use cmake to generate the exports obviously and they provide additional package configuration files which you can omit). The umbrella configuration file can use the component specification given to find_package() to iterate over the required target export files. There is an example of this here (scroll down to If COMPONENTS are specified when the downstream uses[...]): http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
On 04/27/2015 11:48 PM, James Bigler wrote: The problem is the current detection only barfs (unless I missed something - please correct if I'm wrong). What we need is detection and adaptation. Rather than telling the user, DON'T DO THAT! we should be helping the user out by saying, I know you wanted this to be attached as a MAIN_DEPENDENCY, but that doesn't work, so I'm going to help you out and disable this feature for this file. Then I can specify MAIN_DEPENDENCY and not worry about the collisions that cause problems. Yes, I prefer the deterministic barfing that diagnoses documented restrictions over elusive build failures. I am not opposed to your change if your implementation guarantees that the aforementioned build failures don't creep through again. If I understand correctly you would still output a warning diagnostic when degrading duplicate MAIN_DEPENDENCY? Not sure I would like that. Most CMake diagnostics generally imply something that the project developer can fix ... which isn't feasible if you make the behavior part of the design in FindCUDA.cmake. On the other hand the user may himself use MAIN_DEPENDENCY outside the scope of FindCUDA.cmake in which case silent degrading isn't optimal either ... but I guess I could live with that. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] What is the proper way to export targets that will be split into separate binary packages?
On 04/28/2015 11:57 AM, Nils Gladitz wrote:
install(TARGETS plplot1 EXPORT export_plplot1 ...)
install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot)
[...]
install(TARGETS plplotN EXPORT export_plplotN ...)
install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot)
(i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures
with each pair having a unique export name)?
Yes, unique/distinct export names and export files.
Perhaps to clarify unique/distinct export files at the granularity you
actually require which doesn't necessarily mean one per target unless
you intend to package each target independently.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I am having a look now at the changes you made on the first patch (say
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
Instead of finding lintian and dpkg-deb in the check file
find_program(LINTIAN_EXECUTABLE lintian)
find_program(DPKGDEB_EXECUTABLE dpkg-deb)
why not returning the string NOTFOUND in eg. the functions run_lintian
lintian_output, like this:
set(${lintian_output} NOTFOUND PARENT_SCOPE)
One reason is that tests that don't have prerequisites met should not
even be executed in the first place.
The other reason is that if I had time I would rewrite and generalize
all CPack tests to meet those expectations.
Regards,
Domen
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? I currently don't have access to my computer so I'll send you that in about a week. BTW, I do not know what CPackDEB.cmake you are running. Is it pushed somehow? I was using master git branch with all your patches applied so it's the same code you have. I just remembered that I did an incremental build an not a fresh one so I'll have to test if it makes a difference after I get back. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] ExternalProject: how to avoid reinstalling after 'make clean'?
Hi Cedric,
This is something that ExternalProject cannot really do for you in an
automatic/safe way. When you do a make clean, you wipe out all knowledge about
the installed package.
However, you can implement this yourself: Before you do the
ExternalProject_Add(eigen ...) call, you can call find_package(eigen) and if
you find the package, you just skip the ExternalProject_Add.
Cheers,
Johannes
On Tuesday 28 April 2015 12:04:50 Cedric Doucet wrote:
Hello!
No one knows how to avoid spurious installations with external projects?
Thank you,
Cédric
- Mail original -
De: Cedric Doucet cedric.dou...@inria.fr
À: cmake@cmake.org
Envoyé: Vendredi 24 Avril 2015 11:35:54
Objet: ExternalProject: how to avoid reinstalling after 'make clean'?
Hello,
I use the ExternalProjet_Add function to download and install third-party
libraries.
Here is an example of a CMakeLists file containing such a call:
=
cmake_minimum_required (VERSION 2.6)
project (example CXX)
set(CMAKE_VERBOSE_MAKEFILE ON)
include(ProcessorCount)
ProcessorCount(N)
if(NOT N EQUAL 0)
set(CMAKE_BUILD_FLAGS -j${N})
endif()
include(ExternalProject)
set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR})
ExternalProject_Add(eigen
PREFIX ${EXTERNAL_DIR}/eigen
DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download
SOURCE_DIR ${EXTERNAL_DIR}/eigen/src
BINARY_DIR ${EXTERNAL_DIR}/eigen/build
STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp
INSTALL_DIR ${EXTERNAL_DIR}/eigen/install
URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz
URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55
CMAKE_ARGS -D CMAKE_INSTALL_PREFIX=INSTALL_DIR
)
=
Everything works fine, except after calling make clean.
Thanks to URL_MD5, the third-party library is not downloaded again.
However, configuration, build and install steps are performed again
whereas
the library has not been uninstalled during cleaning.
How could I tell to ExternalProject_Add not to configure/build/install my
library unless this library has been removed from my computer?
Thank you very much for your help!
Cédric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] What is the proper way to export targets that will be split into separate binary packages?
On 04/28/2015 11:43 AM, Alan W. Irwin wrote:
@Nils: the origin of the code right below If COMPONENTS... is not
clear. Is that code that should be supplied by a package creator or
code that
should be implemented by every find_package user? And if it should be
supplied by a package creator, does the install(EXPORT...) signature
generate that code automatically, does one of the helper functions
that are available generate that code, or do I (as package creator)
have to supply that code some other way?
The package configuration file is normally handwritten (or
handgenerated) by the package creator. I assume you already have one?
e.g. plplotConfig.cmake.
http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages
@Alex: Sorry I missed your reply until now.
@Alex or Nils:
The problem with the URL provided by Nils is only one library is used
in the example so I don't understand exactly what you guys are
suggesting for the multiple library/component case.
For example, are you recommending
install(TARGETS plplot1 EXPORT export_plplot ...)
[...]
install(TARGETS plplotN EXPORT export_plplot ...)
for N installed libraries followed by
install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot)
? That is the current pattern I am using with one overall export name
called export_plplot. Or would you recommend this different pattern
install(TARGETS plplot1 EXPORT export_plplot1 ...)
install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot)
[...]
install(TARGETS plplotN EXPORT export_plplotN ...)
install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot)
(i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures
with each pair having a unique export name)?
Yes, unique/distinct export names and export files.
That way the target export files can go into the respective distribution
package that they represent.
The umbrella package configuration file would be installed by your
core package and would then be able to pick up the currently available
target export files.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] What is the proper way to export targets that will be split into separate binary packages?
On 2015-04-28 08:56+0200 Nils Gladitz wrote:
On 04/28/2015 01:20 AM, Alan W. Irwin wrote:
On 2015-04-24 12:33-0700 Alan W. Irwin wrote:
This should be a pretty common issue on Linux since it is quite
typical there that downstream packaging splits up binary results into
different packages. Therefore, I assume there is a CMake solution to
this issue, and I would appreciate those who know that solution to
speak up.
I'd go with what Alex suggested in his reply.
In effect it is what e.g. Qt5 does (though they don't use cmake to generate
the exports obviously and they provide additional package configuration files
which you can omit).
The umbrella configuration file can use the component specification given to
find_package() to iterate over the required target export files.
There is an example of this here (scroll down to If COMPONENTS are specified
when the downstream uses[...]):
@Nils: the origin of the code right below If COMPONENTS... is not
clear. Is that code that should be supplied by a package creator or code that
should be implemented by every find_package user? And if it should be
supplied by a package creator, does the install(EXPORT...) signature
generate that code automatically, does one of the helper functions
that are available generate that code, or do I (as package creator)
have to supply that code some other way?
http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages
@Alex: Sorry I missed your reply until now.
@Alex or Nils:
The problem with the URL provided by Nils is only one library is used
in the example so I don't understand exactly what you guys are
suggesting for the multiple library/component case.
For example, are you recommending
install(TARGETS plplot1 EXPORT export_plplot ...)
[...]
install(TARGETS plplotN EXPORT export_plplot ...)
for N installed libraries followed by
install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot)
? That is the current pattern I am using with one overall export name
called export_plplot. Or would you recommend this different pattern
install(TARGETS plplot1 EXPORT export_plplot1 ...)
install(EXPORT export_plplot1 DESTINATION ${LIB_DIR}/cmake/plplot)
[...]
install(TARGETS plplotN EXPORT export_plplotN ...)
install(EXPORT export_plplotN DESTINATION ${LIB_DIR}/cmake/plplot)
(i.e., N pairs of install(TARGETS...) install(EXPORT...) signatures
with each pair having a unique export name)?
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ExternalProject: how to avoid reinstalling after 'make clean'?
Hello!
No one knows how to avoid spurious installations with external projects?
Thank you,
Cédric
- Mail original -
De: Cedric Doucet cedric.dou...@inria.fr
À: cmake@cmake.org
Envoyé: Vendredi 24 Avril 2015 11:35:54
Objet: ExternalProject: how to avoid reinstalling after 'make clean'?
Hello,
I use the ExternalProjet_Add function to download and install third-party
libraries.
Here is an example of a CMakeLists file containing such a call:
=
cmake_minimum_required (VERSION 2.6)
project (example CXX)
set(CMAKE_VERBOSE_MAKEFILE ON)
include(ProcessorCount)
ProcessorCount(N)
if(NOT N EQUAL 0)
set(CMAKE_BUILD_FLAGS -j${N})
endif()
include(ExternalProject)
set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR})
ExternalProject_Add(eigen
PREFIX ${EXTERNAL_DIR}/eigen
DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download
SOURCE_DIR ${EXTERNAL_DIR}/eigen/src
BINARY_DIR ${EXTERNAL_DIR}/eigen/build
STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp
INSTALL_DIR ${EXTERNAL_DIR}/eigen/install
URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz
URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55
CMAKE_ARGS -D CMAKE_INSTALL_PREFIX=INSTALL_DIR
)
=
Everything works fine, except after calling make clean.
Thanks to URL_MD5, the third-party library is not downloaded again.
However, configuration, build and install steps are performed again whereas
the library has not been uninstalled during cleaning.
How could I tell to ExternalProject_Add not to configure/build/install my
library unless this library has been removed from my computer?
Thank you very much for your help!
Cédric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
many places that you would use LOCATION you can use generator expressions http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html $TARGET_FILE_DIR:targetname On Tue, Apr 28, 2015 at 12:30 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Hi Nils: Thanks for your quick reply. More below in context. On 2015-04-28 08:45+0200 Nils Gladitz wrote: On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. CMP0026 only applies to build targets. The location of build targets is still in flux during configuration which is why getting the location of those during configuration time is unsafe. For imported targets this does not apply since their location is fixed. OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. I took that summary line to mean exactly what it said and just plain missed the reference to build targets that is in the first paragraph of that documenation. For which configuration LOCATION returns isn't defined but I suppose that may not matter for pkg-config. Otherwise you may want to look into LOCATION_CONFIG. I don't understand exactly what you mean by configuration LOCATION returns. From what you said that term means something different from LOCATION_CONFIG and in any case is not relevant to my use case of generating pkg-config *.pc files with our build system, but I am nevertheless curious about what you meant.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] Identify used source files
If someone is interessted in this solution:
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs}
${multiValueArgs}${ARGN} )
foreach(file ${ARGN})
get_filename_component(tempPath ${file} DIRECTORY)
string(FIND ${file} ${CMAKE_BINARY_DIR}buildPathFoundPos)
string(FIND ${file} ${CMAKE_SOURCE_DIR}sourcePathFoundPos)
if ((NOT ${file} STREQUALIMPORTED) AND
(NOT ${file} STREQUAL MODULE)AND
(NOT ${file} STREQUAL STATIC)AND
(NOT ${file} STREQUAL SHARED)AND
(NOT ${file} STREQUAL WIN32)AND
${buildPathFoundPos} EQUAL -1)
if (${sourcePathFoundPos} EQUAL -1)
file(APPEND ${FilenameUsedFiles}
${CMAKE_CURRENT_SOURCE_DIR}/${file}\n)
else()
file(APPEND ${FilenameUsedFiles} ${file}\n)
endif()
endif()
endforeach()
endfunction(parseArguments)
function(add_library name)
parseArguments(${ARGN})
_add_library(${name} ${ARGN})
endfunction()
function(add_executable name)
parseArguments(${ARGN})
_add_executable(${name} ${ARGN})
endfunction()
Best Regards
Roman
Am 28.04.2015 um 07:00 schrieb Roman Wüger roman.wue...@gmx.at:
Hello,
is there a proper solution to get all used source files for all defined
librarys and executables?
My first idea was to overload the main functions such as add_executable() and
add_library() temporarily in the main CMakeLists.txt and write a text file or
whatever, but I thought there were a better way.
Did anybody know a better way?
Maybe CMake has a way to get a list of used files?
The reason is to clean a big old source tree.
Thanks in advance
Best regards
Roman
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Identify used source files
If someone is interessted in this solution:
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs}
${multiValueArgs}${ARGN} )
foreach(file ${ARGN})
get_filename_component(tempPath ${file} DIRECTORY)
string(FIND ${file} ${CMAKE_BINARY_DIR}buildPathFoundPos)
string(FIND ${file} ${CMAKE_SOURCE_DIR}sourcePathFoundPos)
if ((NOT ${file} STREQUALIMPORTED) AND
(NOT ${file} STREQUAL MODULE)AND
(NOT ${file} STREQUAL STATIC)AND
(NOT ${file} STREQUAL SHARED)AND
(NOT ${file} STREQUAL WIN32)AND
${buildPathFoundPos} EQUAL -1)
if (${sourcePathFoundPos} EQUAL -1)
file(APPEND ${FilenameUsedFiles}
${CMAKE_CURRENT_SOURCE_DIR}/${file}\n)
else()
file(APPEND ${FilenameUsedFiles} ${file}\n)
endif()
endif()
endforeach()
endfunction(parseArguments)
function(add_library name)
parseArguments(${ARGN})
_add_library(${name} ${ARGN})
endfunction()
function(add_executable name)
parseArguments(${ARGN})
_add_executable(${name} ${ARGN})
endfunction()
Best Regards
Roman
Am 28.04.2015 um 07:00 schrieb Roman Wüger roman.wue...@gmx.at:
Hello,
is there a proper solution to get all used source files for all defined
librarys and executables?
My first idea was to overload the main functions such as add_executable() and
add_library() temporarily in the main CMakeLists.txt and write a text file or
whatever, but I thought there were a better way.
Did anybody know a better way?
Maybe CMake has a way to get a list of used files?
The reason is to clean a big old source tree.
Thanks in advance
Best regards
Roman
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
