[cmake-developers] Remove cmProperty class

2012-02-25 Thread Yury G. Kudryashov
The cmProperty class is used only in cmPropertyMap, and it seems easier to
implement this logic in cmPropertyMap.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [PATCH 1/2] Drop cmProperty class

2012-02-25 Thread Yury G. Kudryashov
From: Yury G. Kudryashov urkud.ur...@gmail.com

This class contains nothing but name (already stored in cmPropertyMap key) and
value (string).
---
 Source/cmProperty.cxx |   40 
 Source/cmProperty.h   |   24 ++--
 Source/cmPropertyDefinition.h |1 +
 Source/cmPropertyMap.cxx  |   28 
 Source/cmPropertyMap.h|5 ++---
 Source/cmTestGenerator.cxx|2 +-
 6 files changed, 14 insertions(+), 86 deletions(-)

diff --git a/Source/cmProperty.cxx b/Source/cmProperty.cxx
index 3b37cf3..e69de29 100644
--- a/Source/cmProperty.cxx
+++ b/Source/cmProperty.cxx
@@ -1,40 +0,0 @@
-/*
-  CMake - Cross Platform Makefile Generator
-  Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
-
-  Distributed under the OSI-approved BSD License (the License);
-  see accompanying file Copyright.txt for details.
-
-  This software is distributed WITHOUT ANY WARRANTY; without even the
-  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-  See the License for more information.
-*/
-#include cmProperty.h
-#include cmSystemTools.h
-
-void cmProperty::Set(const char *name, const char *value)
-{
-  this-Name = name;
-  this-Value = value;
-  this-ValueHasBeenSet = true;
-}
-
-void cmProperty::Append(const char *name, const char *value, bool asString)
-{
-  this-Name = name;
-  if(!this-Value.empty()  *value  !asString)
-{
-this-Value += ;;
-}
-  this-Value += value;
-  this-ValueHasBeenSet = true;
-}
-
-const char *cmProperty::GetValue() const
-{
-  if (this-ValueHasBeenSet)
-{
-return this-Value.c_str();
-}
-  return 0;
-}
diff --git a/Source/cmProperty.h b/Source/cmProperty.h
index e0fcd63..a2b3219 100644
--- a/Source/cmProperty.h
+++ b/Source/cmProperty.h
@@ -12,30 +12,10 @@
 #ifndef cmProperty_h
 #define cmProperty_h
 
-#include cmStandardIncludes.h
-
-class cmProperty 
+namespace cmProperty
 {
-public:
   enum ScopeType { TARGET, SOURCE_FILE, DIRECTORY, GLOBAL, CACHE,
TEST, VARIABLE, CACHED_VARIABLE };
-
-  // set this property
-  void Set(const char *name, const char *value);
-
-  // append to this property
-  void Append(const char *name, const char *value, bool asString = false);
-
-  // get the value
-  const char *GetValue() const;
-
-  // construct with the value not set
-  cmProperty() { this-ValueHasBeenSet = false; };
-
-protected:
-  std::string Name;
-  std::string Value;
-  bool ValueHasBeenSet;
-};
+}
 
 #endif
diff --git a/Source/cmPropertyDefinition.h b/Source/cmPropertyDefinition.h
index f68db87..898e13b 100644
--- a/Source/cmPropertyDefinition.h
+++ b/Source/cmPropertyDefinition.h
@@ -13,6 +13,7 @@
 #define cmPropertyDefinition_h
 
 #include cmProperty.h
+#include cmStandardIncludes.h
 
 class cmPropertyDefinition 
 {
diff --git a/Source/cmPropertyMap.cxx b/Source/cmPropertyMap.cxx
index a4d0bf3..74bbec6 100644
--- a/Source/cmPropertyMap.cxx
+++ b/Source/cmPropertyMap.cxx
@@ -13,21 +13,6 @@
 #include cmSystemTools.h
 #include cmake.h
 
-cmProperty *cmPropertyMap::GetOrCreateProperty(const char *name)
-{
-  cmPropertyMap::iterator it = this-find(name);
-  cmProperty *prop;
-  if (it == this-end())
-{
-prop = (*this)[name];
-}
-  else
-{
-prop = (it-second);
-}
-  return prop;
-}
-
 void cmPropertyMap::SetProperty(const char *name, const char *value,
 cmProperty::ScopeType scope)
 {
@@ -54,8 +39,7 @@ void cmPropertyMap::SetProperty(const char *name, const char 
*value,
   (void)scope;
 #endif
 
-  cmProperty *prop = this-GetOrCreateProperty(name);
-  prop-Set(name,value);
+  (*this)[name] = value;
 }
 
 void cmPropertyMap::AppendProperty(const char* name, const char* value,
@@ -80,8 +64,12 @@ void cmPropertyMap::AppendProperty(const char* name, const 
char* value,
   (void)scope;
 #endif
 
-  cmProperty *prop = this-GetOrCreateProperty(name);
-  prop-Append(name,value,asString);
+  cmStdString old = (*this)[name];
+  if(!old.empty()  !asString)
+{
+old += ;;
+}
+  old += value;
 }
 
 const char *cmPropertyMap
@@ -118,6 +106,6 @@ const char *cmPropertyMap
   }
 return 0;
 }
-  return it-second.GetValue();
+  return it-second.c_str();
 }
 
diff --git a/Source/cmPropertyMap.h b/Source/cmPropertyMap.h
index 94275e2..add5aad 100644
--- a/Source/cmPropertyMap.h
+++ b/Source/cmPropertyMap.h
@@ -13,14 +13,13 @@
 #define cmPropertyMap_h
 
 #include cmProperty.h
+#include cmStandardIncludes.h
 
 class cmake;
 
-class cmPropertyMap : public std::mapcmStdString,cmProperty
+class cmPropertyMap : public std::mapcmStdString,cmStdString
 {
 public:
-  cmProperty *GetOrCreateProperty(const char *name);
-
   void SetProperty(const char *name, const char *value, 
cmProperty::ScopeType scope);

[cmake-developers] [PATCH 2/2] Remove cmProperty.{h,cxx}

2012-02-25 Thread Yury G. Kudryashov
From: Yury G. Kudryashov urkud.ur...@gmail.com

After previous commit cmProperty.h contained only one enum. Move it to
cmPropertyMap.h.
---
 Source/CMakeLists.txt |2 --
 Source/cmDocumentation.h  |2 +-
 Source/cmProperty.h   |   21 -
 Source/cmPropertyDefinition.h |2 +-
 Source/cmPropertyMap.h|7 ++-
 bootstrap |1 -
 6 files changed, 8 insertions(+), 27 deletions(-)
 delete mode 100644 Source/cmProperty.cxx
 delete mode 100644 Source/cmProperty.h

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 0c420b9..e8404ff 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -225,8 +225,6 @@ SET(SRCS
   cmPolicies.cxx
   cmProcessTools.cxx
   cmProcessTools.h
-  cmProperty.cxx
-  cmProperty.h
   cmPropertyDefinition.cxx
   cmPropertyDefinition.h
   cmPropertyDefinitionMap.cxx
diff --git a/Source/cmDocumentation.h b/Source/cmDocumentation.h
index 11bef16..0bf3669 100644
--- a/Source/cmDocumentation.h
+++ b/Source/cmDocumentation.h
@@ -13,7 +13,7 @@
 #define _cmDocumentation_h
 
 #include cmStandardIncludes.h
-#include cmProperty.h
+#include cmPropertyMap.h
 #include cmDocumentationFormatter.h
 #include cmDocumentationFormatterHTML.h
 #include cmDocumentationFormatterDocbook.h
diff --git a/Source/cmProperty.cxx b/Source/cmProperty.cxx
deleted file mode 100644
index e69de29..000
diff --git a/Source/cmProperty.h b/Source/cmProperty.h
deleted file mode 100644
index a2b3219..000
--- a/Source/cmProperty.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
-  CMake - Cross Platform Makefile Generator
-  Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
-
-  Distributed under the OSI-approved BSD License (the License);
-  see accompanying file Copyright.txt for details.
-
-  This software is distributed WITHOUT ANY WARRANTY; without even the
-  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-  See the License for more information.
-*/
-#ifndef cmProperty_h
-#define cmProperty_h
-
-namespace cmProperty
-{
-  enum ScopeType { TARGET, SOURCE_FILE, DIRECTORY, GLOBAL, CACHE,
-   TEST, VARIABLE, CACHED_VARIABLE };
-}
-
-#endif
diff --git a/Source/cmPropertyDefinition.h b/Source/cmPropertyDefinition.h
index 898e13b..e1c2648 100644
--- a/Source/cmPropertyDefinition.h
+++ b/Source/cmPropertyDefinition.h
@@ -12,7 +12,7 @@
 #ifndef cmPropertyDefinition_h
 #define cmPropertyDefinition_h
 
-#include cmProperty.h
+#include cmPropertyMap.h
 #include cmStandardIncludes.h
 
 class cmPropertyDefinition 
diff --git a/Source/cmPropertyMap.h b/Source/cmPropertyMap.h
index add5aad..9759a27 100644
--- a/Source/cmPropertyMap.h
+++ b/Source/cmPropertyMap.h
@@ -12,11 +12,16 @@
 #ifndef cmPropertyMap_h
 #define cmPropertyMap_h
 
-#include cmProperty.h
 #include cmStandardIncludes.h
 
 class cmake;
 
+namespace cmProperty
+{
+  enum ScopeType { TARGET, SOURCE_FILE, DIRECTORY, GLOBAL, CACHE,
+   TEST, VARIABLE, CACHED_VARIABLE };
+}
+
 class cmPropertyMap : public std::mapcmStdString,cmStdString
 {
 public:
diff --git a/bootstrap b/bootstrap
index f5eacbd..327f6c8 100755
--- a/bootstrap
+++ b/bootstrap
@@ -188,7 +188,6 @@ CMAKE_CXX_SOURCES=\
   cmDocumentationFormatter \
   cmDocumentationFormatterText \
   cmPolicies \
-  cmProperty \
   cmPropertyMap \
   cmPropertyDefinition \
   cmPropertyDefinitionMap \
-- 
1.7.8

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [PATCH 1/2] cmPropertyDefinition::IsChained is const

2012-02-25 Thread Yury G. Kudryashov
From: Yury G. Kudryashov urkud.ur...@gmail.com

---
 Source/cmPropertyDefinition.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Source/cmPropertyDefinition.h b/Source/cmPropertyDefinition.h
index f68db87..58d1472 100644
--- a/Source/cmPropertyDefinition.h
+++ b/Source/cmPropertyDefinition.h
@@ -31,7 +31,7 @@ public:
   cmPropertyDefinition() { this-Chained = false; };
 
   // is it chained?
-  bool IsChained() {return this-Chained; };
+  bool IsChained() const { return this-Chained; };
 
   // Get the section if any
   const std::string GetDocumentationSection() const {
-- 
1.7.8

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] [PATCH 1/2] cmPropertyDefinition::IsChained is const

2012-02-25 Thread Yury G. Kudryashov
Yury G. Kudryashov wrote:

 From: Yury G. Kudryashov
 urkud.ur...@gmail.com
Mailman says that the next patch is too big. The compressed version is 
attached.
-- 
Yury G. Kudryashov,
mailto: ur...@mccme.ru

0002-Add-const-qualifier-to-some-cmCommand-members.patch.xz
Description: application/xz
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [PATCH] Drop if(...) check because condition is always true

2012-02-25 Thread Yury G. Kudryashov
From: Yury G. Kudryashov urkud.ur...@gmail.com

GetLocation returns std::string::c_str() which is never NULL
---
 Source/cmLocalGenerator.cxx |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index ffbeb48..ea48dd1 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1903,12 +1903,8 @@ bool cmLocalGenerator::GetRealDependency(const char* 
inName,
   case cmTarget::MODULE_LIBRARY:
   case cmTarget::UNKNOWN_LIBRARY:
 {
-// Get the location of the target's output file and depend on it.
-if(const char* location = target-GetLocation(config))
-  {
-  dep = location;
-  return true;
-  }
+dep = target-GetLocation(config);
+return true;
 }
 break;
   case cmTarget::UTILITY:
-- 
1.7.8

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [CMake] Code and API review request for Qt5 CMake files

2012-02-25 Thread Alexander Neundorf
On Friday 24 February 2012, Michael Hertling wrote:
 On 02/24/2012 03:34 PM, Stephen Kelly wrote:
...
  [...] (that is, find_package(Qt5 REQUIRED
  Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the
  Qt5Config file is found, whether the component is or not), [...]
 
 No: FIND_PACKAGE(Qt5 REQUIRED ...) is expected to bail out if any of
 the required components aren't found, so the value of the Qt5_FOUND
 variable doesn't matter in this case. BTW, note that FIND_PACKAGE()
 must not bail out if a component which the user hasn't requested is
 not found, regardless of the REQUIRED flag, unless the component is
 an immediate or mediate prerequisite of a required one.
 
 Regarding Qt5_FOUND, FIND_PACKAGE(Qt5 COMPONENTS ...), i.e. without
 REQUIRED, is more interesting, see [4]. In short: Qt5_FOUND indicates
 if Qt5 is basically present but says nothing about any component; the
 user must refer to the component-specific FOUND variables, and those
 must even be protected by the package-specific one:

Ah, yes, I remember this discussion.
I'd sum up the results as follows:

* Config-mode should behave the same way as Module-mode with regard to 
COMPONENTS (I think this still needs changes in the find_package() 
implementation)

* if REQUIRED is used, find_package(Foo COMPONENTS A B C) must only succeed if 
all listed components have been found

* if REQUIRED is not used, we still have two opinions:

1.) FOO_FOUND should be the major sign whether everything I wanted has been 
found or not. I.e. it is only set to TRUE if all listed components have been 
found. To check whether some of the components have been found, i.e. if 
FOO_FOUND==FALSE, I can check the per-component _FOUND variables.
The reasoning here is I want to use some parts of a big package, if they all 
are found, then I can use it, otherwise I can't use the package at all

2.) FOO_FOUND should only indicate that at least something of Foo has been 
found. To check which modules have been found, i.e. if FOO_FOUND==TRUE, I must 
check the per-component _FOUND variables.
The logic here is I want to use some parts of a big package, and I can use 
them independently from each other.

Both make sense.
I'd prefer the first one.

 
 FIND_PACKAGE(Qt5 COMPONENTS XYZ)
 IF(Qt5_FOUND AND Qt5_XYZ_FOUND)
 ...
 ENDIF()
 
 Referring to Qt5_XYZ_FOUND alone is not reliable because this variable
 wouldn't have received a definite value if Qt5Config.cmake hasn't been
 found by FIND_PACKAGE(). I.e., the user would refer to this variable's
 value before the FIND_PACKAGE() call; probably, that's not expected.
 
 Note that you should also think about handling components requested
 by the user but unknown to Qt5Config.cmake. Consider the following
 use case: One day, a component - aka module - XYZ is added to Qt5,
 and there's an application that can make use of it but needn't to:
 
 FIND_PACKAGE(Qt5 COMPONENTS XYZ)
 IF(Qt5_FOUND AND Qt5_XYZ_FOUND)
 
 ENDIF()
 
 What should happen if this application is configured against a Qt5
 installation which does not know XYZ yet? IMO, the user can expect
 that Qt5_XYZ_FOUND receives a definite value during the processing
 of Qt5Config.cmake in any case. I.e., the Qt5Config.cmake of a Qt5
 installation unaware of XYZ must nevertheless set Qt5_XYZ_FOUND to
 FALSE if XYZ has been requested by the user.
 
 For the latter, this means to refer only to components which have
 been requested explicitly with FIND_PACKAGE(), and to not rely on
 the assumption that any component is searched automatically, but
 that's another story...
 
  [...] I'm not sure
  it's a good idea, [...]
 
 Personally, I'm quite sure it is.
 
  [...] or at least it's more complicated. [...]
 
 Probably, but I think it's worth the effort, even for the reason alone
 that a comprehensive Qt5Config.cmake could handle the possibly subtle
 relations among Qt5 modules far better than distinct module-specific
 configuration files ever can.
 
  [...] At least, I think
  something like qt5_use_package is a better idea anyway.
 
 First of all, I definitely agree to your criticism of UseQt4.cmake in
 [5], and I appreciate your attempt to get rid of such a use file for
 Qt5. However, I'd choose a Qt5Config.cmake over qt5_use_package(),
 and my current vision for the former's usage is roughly, e.g.,
 
 FIND_PACKAGE(Qt5 REQUIRED Xml)
 SET_TARGET_PROPERTIES(t1 PROPERTIES
 COMPILE_DEFINITIONS ${Qt5_DEFINITIONS}
 INCLUDE_DIRECTORIES ${Qt5_INCLUDE_DIRS})  # If available one day.

I think something like this will be in 2.8.8.
See the target_include_directories() thread on the cmake developers list (but 
I didn't follow closely).

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


[CMake] Copy Files in Windows C Project

2012-02-25 Thread Alan Gutierrez
I was looking for a way to copy files into the Debug or Release directory of a 
Visual Studio 10 project, that might also work for other forms of project, like 
NMAKE. I ended up using add_custom_command.

My CMakeLists.txt at GitHub:

https://github.com/bigeasy/verity/blob/65830bff4a0a08785eb75f01451cb1a9ac16f456/CMakeLists.txt

Seems like a kludge to launch a program to copy a file. Copying a file seems 
like a common task in a project build. Is there a canonical way to do this?Or 
are there many ways and this is as good as any?

--
Alan Gutierrez - @bigeasy--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] dependency on header

2012-02-25 Thread Krzysztof
Does CMake know that if I include a header file in a source it should 
consider the source as dependent on the header? I mean, will CMake 
recompile the source when only the header changes or do I need 
explicitly tell CMake this in CMakeLists.txt?


--
Regards
Krzysztof J.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Code and API review request for Qt5 CMake files

2012-02-25 Thread Michael Hertling
On 02/25/2012 09:43 AM, Alexander Neundorf wrote:
 On Friday 24 February 2012, Michael Hertling wrote:
 On 02/24/2012 03:34 PM, Stephen Kelly wrote:
 ...
 [...] (that is, find_package(Qt5 REQUIRED
 Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if the
 Qt5Config file is found, whether the component is or not), [...]

 No: FIND_PACKAGE(Qt5 REQUIRED ...) is expected to bail out if any of
 the required components aren't found, so the value of the Qt5_FOUND
 variable doesn't matter in this case. BTW, note that FIND_PACKAGE()
 must not bail out if a component which the user hasn't requested is
 not found, regardless of the REQUIRED flag, unless the component is
 an immediate or mediate prerequisite of a required one.

 Regarding Qt5_FOUND, FIND_PACKAGE(Qt5 COMPONENTS ...), i.e. without
 REQUIRED, is more interesting, see [4]. In short: Qt5_FOUND indicates
 if Qt5 is basically present but says nothing about any component; the
 user must refer to the component-specific FOUND variables, and those
 must even be protected by the package-specific one:
 
 Ah, yes, I remember this discussion.
 I'd sum up the results as follows:
 
 * Config-mode should behave the same way as Module-mode with regard to 
 COMPONENTS (I think this still needs changes in the find_package() 
 implementation)

Which changes do you have in mind? AFAIK, config files and find modules
can perfectly behave the same - provided they're implemented correctly.

 * if REQUIRED is used, find_package(Foo COMPONENTS A B C) must only succeed 
 if 
 all listed components have been found

Perhaps, we can also include components which are immediate or mediate
prerequisites of the listed ones. The REQUIRED flag should ensure that
anything necessary to use the listed components is actually available.

 * if REQUIRED is not used, we still have two opinions:
 
 1.) FOO_FOUND should be the major sign whether everything I wanted has been 
 found or not. I.e. it is only set to TRUE if all listed components have been 
 found. To check whether some of the components have been found, i.e. if 
 FOO_FOUND==FALSE, I can check the per-component _FOUND variables.
 The reasoning here is I want to use some parts of a big package, if they all 
 are found, then I can use it, otherwise I can't use the package at all

If FOO_FOUND==FALSE and FIND_PACKAGE() did load a config file, none of
the per-component _FOUND variables has received a definite value, i.e.
you'd refer to the values they already had before the invocation of
FIND_PACKAGE().

 2.) FOO_FOUND should only indicate that at least something of Foo has been 
 found. To check which modules have been found, i.e. if FOO_FOUND==TRUE, I 
 must 
 check the per-component _FOUND variables.
 The logic here is I want to use some parts of a big package, and I can use 
 them independently from each other.
 
 Both make sense.
 I'd prefer the first one.

Presumably, you're not surprised that I move for the second. ;-)
One of my favorite points for the latter is the following use case:

Suppose there's a multi-component package FOO which provides some
required components and some optional ones. The user has three
distinct possibilities how those components can be requested:

(A) Request all of them with the REQUIRED flag: Bad, a missing optional
component would terminate the configuration although all is well.

(B) Request all of them without the REQUIRED flag: With your preference
(1), a missing optional component would result in FOO_FOUND==FALSE
although all is well. As for me, that's not what I'd expect if the
findings are certainly acceptable.

(C) Request the required components with REQUIRED and the optional ones
without this flag via a separate FIND_PACKAGE() invocation: If all
required components are found but an optional component is missing,
your preference (1) would result in FOO_FOUND==TRUE for the formers
and FOO_FOUND==FALSE for the latters. That's even more inconsistent
than (B), although the findings are likewise acceptable. Moreover,
there might be reasons why one doesn't want to use more than one
FIND_PACKAGE() call to request components which are going to be
used together; recall the example of package X with components
A and B and a possibly necessary -DX_WITH_B definition for A.

As a fourth possibility, one might drop the optional components from
the FIND_PACKAGE() call and rely on the assumption that unrequested
components are searched unaskedly by the config file / find module.
This should not be forced on the latter, and what should happen if
an optional component isn't known at all? Recall the example of Qt5
with a module XYZ added in a later release: An application willing
to use XYZ if available but configured against an earlier release
of Qt5 via FIND_PACKAGE(Qt5) would also refer to a Qt5_XYZ_FOUND
variable which has not - can't have - received a definite value.

IMO, the use case with mixed required and optional components points
out 

[Cmake-commits] CMake branch, next, updated. v2.8.7-2871-gddea27f

2012-02-25 Thread Björn Ricks
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  ddea27f456ba17430cf65324c1ff860b6d147122 (commit)
   via  0d2f5c8d6a3384816310aec2478cf9e3877e8569 (commit)
   via  f3fe73da548a90e6682fd6a650d923151950003d (commit)
  from  baf47101466b23d2c7544d67133d8709caf84963 (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=ddea27f456ba17430cf65324c1ff860b6d147122
commit ddea27f456ba17430cf65324c1ff860b6d147122
Merge: baf4710 0d2f5c8
Author: Björn Ricks bjoern.ri...@intevation.de
AuthorDate: Sat Feb 25 12:27:17 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 25 12:27:17 2012 -0500

Merge topic 'fix-macos-findprogramm-crash' into next

0d2f5c8 Fix crash if app bundle executeable couldn't be found
f3fe73d KWSys Nightly Date Stamp


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d2f5c8d6a3384816310aec2478cf9e3877e8569
commit 0d2f5c8d6a3384816310aec2478cf9e3877e8569
Author: Bjoern Ricks bjoern.ri...@intevation.de
AuthorDate: Sat Feb 25 18:20:36 2012 +0100
Commit: Bjoern Ricks bjoern.ri...@intevation.de
CommitDate: Sat Feb 25 18:20:36 2012 +0100

Fix crash if app bundle executeable couldn't be found

Fix a crash on Mac OS X if a programm can't be found as an
application bundle. CFRelease MUST NOT be called on a
NULL value.

See 
https://developer.apple.com/library/mac/documentation/CoreFOundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/doc/c_ref/CFRelease

diff --git a/Source/cmFindProgramCommand.cxx b/Source/cmFindProgramCommand.cxx
index 7c56ad7..00f5419 100644
--- a/Source/cmFindProgramCommand.cxx
+++ b/Source/cmFindProgramCommand.cxx
@@ -175,6 +175,8 @@ std::string 
cmFindProgramCommand::GetBundleExecutable(std::string bundlePath)
 
 // And finally to a c++ string
 executable = bundlePath + /Contents/MacOS/ + std::string(buffer);
+// Only release CFURLRef if it's not null
+CFRelease( executableURL );
 }
 
   // Any CF objects returned from functions with create or 
@@ -182,7 +184,6 @@ std::string 
cmFindProgramCommand::GetBundleExecutable(std::string bundlePath)
   CFRelease( bundlePathCFS );
   CFRelease( bundleURL );
   CFRelease( appBundle );
-  CFRelease( executableURL );
 #endif
 
   return executable;

---

Summary of changes:
 Source/cmFindProgramCommand.cxx   |3 ++-
 Source/kwsys/kwsysDateStamp.cmake |2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v2.8.7-2875-g4f279c6

2012-02-25 Thread Eric Noulard
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  4f279c603a4a1dca275d393286506f3054feadd2 (commit)
   via  b3851f504dc8404384aa14b62ca4765f3a4dc955 (commit)
  from  6cda64102debcd49b3d24aaf69a91a254d381f83 (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=4f279c603a4a1dca275d393286506f3054feadd2
commit 4f279c603a4a1dca275d393286506f3054feadd2
Merge: 6cda641 b3851f5
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Feb 25 13:21:33 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 25 13:21:33 2012 -0500

Merge topic 'CPack-fixCPackDMG-docLayout' into next

b3851f5 Fix CPack Drag and Drop generator documentation layout.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3851f504dc8404384aa14b62ca4765f3a4dc955
commit b3851f504dc8404384aa14b62ca4765f3a4dc955
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sat Feb 25 19:18:52 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Feb 25 19:18:52 2012 +0100

Fix CPack Drag and Drop generator documentation layout.

diff --git a/Modules/CPackDMG.cmake b/Modules/CPackDMG.cmake
index caa8dc8..e866bab 100644
--- a/Modules/CPackDMG.cmake
+++ b/Modules/CPackDMG.cmake
@@ -7,53 +7,53 @@
 ##end
 #
 ##variable
-#   CPACK_DMG_VOLUME_NAME - The volume name of the generated disk
-#   image. Defaults to CPACK_PACKAGE_FILE_NAME.
+#  CPACK_DMG_VOLUME_NAME - The volume name of the generated disk
+#  image. Defaults to CPACK_PACKAGE_FILE_NAME.
 ##end
 #
 ##variable
-#   CPACK_DMG_FORMAT - The disk image format. Common values are UDRO
-#   (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF
-#   bzip2-compressed). Refer to hdiutil(1) for more information on
-#   other available formats.
+#  CPACK_DMG_FORMAT - The disk image format. Common values are UDRO
+#  (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF
+#  bzip2-compressed). Refer to hdiutil(1) for more information on
+#  other available formats.
 ##end
 #
 ##variable
-#   CPACK_DMG_DS_STORE - Path to a custom .DS_Store file which e.g.
-#   can be used to specify the Finder window position/geometry and
-#   layout (such as hidden toolbars, placement of the icons etc.).
-#   This file has to be generated by the Finder (either manually or
-#   through OSA-script) using a normal folder from which the .DS_Store
-#   file can then be extracted.
+#  CPACK_DMG_DS_STORE - Path to a custom DS_Store file. This .DS_Store
+#  file e.g. can be used to specify the Finder window
+#  position/geometry and layout (such as hidden toolbars, placement of the
+#  icons etc.). This file has to be generated by the Finder (either manually or
+#  through OSA-script) using a normal folder from which the .DS_Store
+#  file can then be extracted.
 ##end
 #
 ##variable
-#   CPACK_DMG_BACKGROUND_IMAGE - Path to an image file which is to be
-#   used as the background for the Finder Window when the disk image
-#   is opened.  By default no background image is set. The background
-#   image is applied after applying the custom .DS_Store file.
+#  CPACK_DMG_BACKGROUND_IMAGE - Path to a background image file. This
+#  file will be used as the background for the Finder Window when the disk
+#  image is opened.  By default no background image is set. The background
+#  image is applied after applying the custom .DS_Store file.
 ##end
 #
 ##variable
-#   CPACK_COMMAND_HDIUTIL - Path to the hdiutil(1) command used to
-#   operate on disk image files on Mac OS X. This variable can be used
-#   to override the automatically detected command (or specify its
-#   location if the auto-detection fails to find it.)
+#  CPACK_COMMAND_HDIUTIL - Path to the hdiutil(1) command used to
+#  operate on disk image files on Mac OS X. This variable can be used
+#  to override the automatically detected command (or specify its
+#  location if the auto-detection fails to find it.)
 ##end
 #
 ##variable
-#   CPACK_COMMAND_SETFILE - Path to the SetFile(1) command used to set
-#   extended attributes on files and directories on Mac OS X. This
-#   variable can be used to override the automatically detected
-#   command (or specify its location if the auto-detection fails to
-#   find it.)
+#  CPACK_COMMAND_SETFILE - Path to the SetFile(1) command used to set
+#  extended attributes on files and directories on Mac OS X. This
+#  variable can be used to override the automatically detected
+#  command (or specify its location if the auto-detection fails to
+#  find it.)
 ##end
 #
 ##variable
-#   CPACK_COMMAND_REZ - Path to the Rez(1) command used to compile
-#   resources on 

[Cmake-commits] CMake branch, next, updated. v2.8.7-2882-g733a122

2012-02-25 Thread Eric Noulard
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  733a1221b1915df101eeb1a6f6d8dc0694f0b753 (commit)
   via  98d158376eacacd12a765675272268be27609192 (commit)
  from  da1e14700e6a9768a64730a64cd3d9e43d2e94f1 (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=733a1221b1915df101eeb1a6f6d8dc0694f0b753
commit 733a1221b1915df101eeb1a6f6d8dc0694f0b753
Merge: da1e147 98d1583
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Feb 25 17:29:12 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 25 17:29:12 2012 -0500

Merge topic 'CPack-cygwinGeneratorDoc' into next

98d1583 Provide template for CPack Cygwin generator specific variables.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98d158376eacacd12a765675272268be27609192
commit 98d158376eacacd12a765675272268be27609192
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sat Feb 25 23:26:41 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Feb 25 23:26:41 2012 +0100

Provide template for CPack Cygwin generator specific variables.

diff --git a/Modules/CPackCygwin.cmake b/Modules/CPackCygwin.cmake
new file mode 100644
index 000..7ed7f67
--- /dev/null
+++ b/Modules/CPackCygwin.cmake
@@ -0,0 +1,33 @@
+##section Variables specific to CPack Cygwin generator
+##end
+##module
+# - Cygwin CPack generator (Cygwin).
+# The following variable is specific to installers build on
+# and/or for Cygwin:
+##end
+#
+##variable
+#   CPACK_CYGWIN_PATCH_NUMBER - The Cygwin patch number.
+#   FIXME: This documentation is incomplete.
+##end
+##variable
+#   CPACK_CYGWIN_PATCH_FILE - The Cygwin patch file.
+#   FIXME: This documentation is incomplete.
+##end
+##variable
+#   CPACK_CYGWIN_BUILD_SCRIPT - The Cygwin build script.
+#   FIXME: This documentation is incomplete.
+##end
+
+#=
+# Copyright 2006-2012 Kitware, Inc.
+#
+# Distributed under the OSI-approved BSD License (the License);
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+#  License text for the above reference.)

---

Summary of changes:
 Modules/CPackCygwin.cmake |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 Modules/CPackCygwin.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v2.8.7-453-g08ff872

2012-02-25 Thread KWSys Robot
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  08ff8727afba8363455af36de5dcc78cfb209158 (commit)
  from  f3fe73da548a90e6682fd6a650d923151950003d (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=08ff8727afba8363455af36de5dcc78cfb209158
commit 08ff8727afba8363455af36de5dcc78cfb209158
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Sun Feb 26 00:01:05 2012 -0500
Commit: KWSys Robot kwro...@kitware.com
CommitDate: Sun Feb 26 00:05:05 2012 -0500

KWSys Nightly Date Stamp

diff --git a/Source/kwsys/kwsysDateStamp.cmake 
b/Source/kwsys/kwsysDateStamp.cmake
index 829c587..4e99678 100644
--- a/Source/kwsys/kwsysDateStamp.cmake
+++ b/Source/kwsys/kwsysDateStamp.cmake
@@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR  2012)
 SET(KWSYS_DATE_STAMP_MONTH 02)
 
 # KWSys version date day component.  Format is DD.
-SET(KWSYS_DATE_STAMP_DAY   25)
+SET(KWSYS_DATE_STAMP_DAY   26)

---

Summary of changes:
 Source/kwsys/kwsysDateStamp.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits