Re: [cmake-developers] find_package module-only policy
On 2/27/2012 3:17 PM, Alexander Neundorf wrote: Anything left I should do before merging into next ? The documentation of find_package() may need some modifications, I thought you may want to have a look at that ? I reverted FindPackage_ImprovedErrorMessages from next and replaced it with find_package-report-CONFIGS-error containing only the bugfix. I also removed the topics FindPackage_CONFIG_MODE_MODULE_MODE FindPackage_CONFIG_MODULEKeywordsFirst FindPackage_ImprovedErrorMessages FindPackage_MODULE_MODE_Policy from the stage (I have backups locally). This makes room for the new changes we've discussed in this thread without mixing them up with the original proposal. I replaced the FindPackage_ModeWarning topic on the stage with a rewritten one that makes (almost) the same net change. I just tweaked the documentation of find_package a bit and wrapped a couple long lines in the source code. The new sequence of commits makes each part of the change much clearer and easier to review. However, I'm not yet prepared to merge this to next. I'm going to make more significant edits to the proposed changes and post them as a separate topic and then report back here. -Brad -- 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] CMakeFindPackageMode.cmake: fix 32/64bit detection if `file' is a symlink
I understand the get_filename_component call here, but it does not really need to use CACHE does it? On Fri, Feb 24, 2012 at 10:37 AM, Brad King wrote: > On 2/23/2012 4:39 PM, Yury G. Kudryashov wrote: >> >> From: "Yury G. Kudryashov" > > > Applied, thanks: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19ab5819 > > -Brad > > -- > > 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 -- 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] Nightly Binary not building on windows
The nightly binary for CMake is not building because of a test failure: http://open.cdash.org/testDetails.php?test=136868750&build=2046004 CMake Error at CMakeLists.txt:52 (message): Subversion_VERSION_SVN has unexpected content Call Stack (most recent call first): CMakeLists.txt:74 (check_version_string) The following tests FAILED: 185 - CMakeOnly.AllFindModules (Failed) Any ideas? -Bill -- 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 2/2] Remove cmProperty.{h,cxx}
What's the motivation here?
This will likely conflict (logically, at compile time) with the
recently merged-to-next topic for the target-include-directories...
On Sat, Feb 25, 2012 at 3:07 AM, Yury G. Kudryashov
wrote:
> From: "Yury G. Kudryashov"
>
> 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::map
> {
> 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
--
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 2/2] Remove cmProperty.{h,cxx}
David Cole wrote: > What's the motivation here? The motivation was to remove a class that has no useful methods. The only useful method was AppendProperty, and it can be easily implemented in cmPropertyMap. > > This will likely conflict (logically, at compile time) with the > recently merged-to-next topic for the target-include-directories... I'd move AddStringToProperty to cmPropertyMap (say, cmPropertyMap::PrependProperty). I'll prepare a patch in a few days (rather busy now). -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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] CMakeFindPackageMode.cmake: fix 32/64bit detection if `file' is a symlink
On 2/28/2012 11:35 AM, David Cole wrote: I understand the get_filename_component call here, but it does not really need to use CACHE does it? I didn't notice that option there. Fixed. Thanks, -Brad -- 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] Nightly Binary not building on windows
2012/2/28 Bill Hoffman : > The nightly binary for CMake is not building because of a test failure: > > http://open.cdash.org/testDetails.php?test=136868750&build=2046004 > > > CMake Error at CMakeLists.txt:52 (message): > Subversion_VERSION_SVN has unexpected content > Call Stack (most recent call first): > CMakeLists.txt:74 (check_version_string) > > The following tests FAILED: > 185 - CMakeOnly.AllFindModules (Failed) This commit cffce2ffb366cd5c598f56e8f0789124a6d1b7a9 added at least this check_version_string(SUBVERSION Subversion_VERSION_SVN) Subversion_VERSION_SVN seems empty (from the error message)? The module is named "FindSubversion.cmake" make be check_version_string(SUBVERSION Subversion_VERSION_SVN) should simply be: check_version_string(Subversion Subversion_VERSION_SVN) upper/lower case trouble? Mixed-case leads to trouble since (from FindSubversion.cmake) we have: # Subversion_FOUND - true if the command line client was found # SUBVERSION_FOUND - same as Subversion_FOUND, set for compatiblity reasons -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Nightly Binary not building on windows
On 2/28/2012 1:14 PM, Eric Noulard wrote: 2012/2/28 Bill Hoffman: The nightly binary for CMake is not building because of a test failure: http://open.cdash.org/testDetails.php?test=136868750&build=2046004 CMake Error at CMakeLists.txt:52 (message): Subversion_VERSION_SVN has unexpected content Call Stack (most recent call first): CMakeLists.txt:74 (check_version_string) The following tests FAILED: 185 - CMakeOnly.AllFindModules (Failed) This commit cffce2ffb366cd5c598f56e8f0789124a6d1b7a9 added at least this check_version_string(SUBVERSION Subversion_VERSION_SVN) Subversion_VERSION_SVN seems empty (from the error message)? The module is named "FindSubversion.cmake" make be check_version_string(SUBVERSION Subversion_VERSION_SVN) should simply be: check_version_string(Subversion Subversion_VERSION_SVN) upper/lower case trouble? Mixed-case leads to trouble since (from FindSubversion.cmake) we have: # Subversion_FOUND - true if the command line client was found # SUBVERSION_FOUND - same as Subversion_FOUND, set for compatiblity reasons OK, the problem is that svn is not working on the machine: $ /cygdrive/c/Program\ Files\ \(x86\)/Subversion/svn info svn: Can't determine the user's config path However, this should not be an error. That is the point of this test. Even if something is wrong, it should not error out. It should continue unless it is required. Perhaps the check_version_string function should be made aware that it should only error out if REQUIRED is set. -Bill -- 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] Nightly Binary not building on windows
On Tue, Feb 28, 2012 at 1:25 PM, Bill Hoffman wrote: > On 2/28/2012 1:14 PM, Eric Noulard wrote: >> >> 2012/2/28 Bill Hoffman: >>> >>> The nightly binary for CMake is not building because of a test failure: >>> >>> http://open.cdash.org/testDetails.php?test=136868750&build=2046004 >>> >>> >>> CMake Error at CMakeLists.txt:52 (message): >>> Subversion_VERSION_SVN has unexpected content >>> Call Stack (most recent call first): >>> CMakeLists.txt:74 (check_version_string) >>> >>> The following tests FAILED: >>> 185 - CMakeOnly.AllFindModules (Failed) >> >> >> This commit >> cffce2ffb366cd5c598f56e8f0789124a6d1b7a9 >> added at least this >> check_version_string(SUBVERSION Subversion_VERSION_SVN) >> >> Subversion_VERSION_SVN seems empty (from the error message)? >> >> The module is named "FindSubversion.cmake" make be >> >> check_version_string(SUBVERSION Subversion_VERSION_SVN) >> >> should simply be: >> >> check_version_string(Subversion Subversion_VERSION_SVN) >> >> upper/lower case trouble? >> >> Mixed-case leads to trouble since (from FindSubversion.cmake) we have: >> >> # Subversion_FOUND - true if the command line client was found >> # SUBVERSION_FOUND - same as Subversion_FOUND, set for compatiblity >> reasons >> > > OK, the problem is that svn is not working on the machine: > > $ /cygdrive/c/Program\ Files\ \(x86\)/Subversion/svn info > svn: Can't determine the user's config path > > > However, this should not be an error. That is the point of this test. Even > if something is wrong, it should not error out. It should continue unless > it is required. Perhaps the check_version_string function should be made > aware that it should only error out if REQUIRED is set. > > > -Bill > > > -- > > 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 Wait for Eike to reply here. He's been requiring version variables to be set if the package is found in this test. I'm sure he'll either patch this up so it works or exclude svn from the version variable test depending on how hard it is to detect this situation... Thx, David -- 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] How to handle package Config.cmake files with dependencies ?
On Monday 27 February 2012, Brad King wrote: > On 2/27/2012 3:37 PM, Michael Wild wrote: > > On 02/27/2012 09:15 PM, Alexander Neundorf wrote: > >> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE: > >> // Set a variable marking whether the package was found. > >> > >>std::string foundVar = this->Name; > >>foundVar += "_FOUND"; > >> > >> This means it is true in all cases that the Config.cmake file has been > >> found (and the version was compatible). > > The find_package command is acting as a primitive like find_library from > the point of view of setting Foo_DIR, and that can be tested directly to > see if the config file was found. That leaves room to change the way > we set Foo_FOUND. We could add a policy that in NEW behavior unsets > Foo_FOUND completely before loading FooConfig. After FooConfig has been > loaded it detects whether Foo_FOUND is now defined. If set, use that > value. If not set, set it to true as it is now. That will give the > FooConfig file a chance to set the result. Sounds good. Do you think that needs a policy ? The code currently does: // Set a variable marking whether the package was found. std::string foundVar = this->Name; foundVar += "_FOUND"; this->Makefile->AddDefinition(foundVar.c_str(), found? "1":"0"); (I forgot the last line in my initial mail). So the variable is set afterwards unconditionally. The only condition where it would make a difference is if inside a FooConfig.cmake file there would be a check whether Foo_FOUND is already TRUE. I can do that. > >> * how to handle COMPONENTS ? > > > > I like that proposal. I'm also quite unhappy with how components are > > handled in config-mode. > > With the approach I suggest above it will be up to FooConfig to determine > this. > > Another approach is to add an API to give FooConfigVersion access to the > list of desired components. If the package version file encodes a known > list of available components it would be able to report UNSUITABLE if a > requested component is missing. Then find_package would move on to > another candidate. This might confuse users that expect a particular > location to be found because it wouldn't report that it is missing a > component and instead silently ignore it. It is probably better to let > FooConfig report a message that says its Foo doesn't have the component. Yes, I agree that putting the component-handling into the version file sounds a bit unexpected. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Nightly Binary not building on windows
On 2/28/2012 1:38 PM, David Cole wrote: Wait for Eike to reply here. He's been requiring version variables to be set if the package is found in this test. I'm sure he'll either patch this up so it works or exclude svn from the version variable test depending on how hard it is to detect this situation... If the package is not required, then we can not error out if it finds a bad copy of some software and can't figure out the version number. No matter what find_package(foo) Can not cause an error at CMake time. -Bill -- 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] Nightly Binary not building on windows
On 2/28/2012 1:53 PM, Bill Hoffman wrote: No matter what find_package(foo) Can not cause an error at CMake time. That isn't the line causing the error. It's the AllFindModules test that wants to know that the returned version information is as expected. This is a real test failure because the FindSubversion module is not properly detecting the version number of svn. The Find module needs to be fixed for this case. -Brad -- 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] How to handle package Config.cmake files with dependencies ?
On 2/28/2012 1:48 PM, Alexander Neundorf wrote: Do you think that needs a policy ? I'm not sure. It's pretty obscure. The code currently does: // Set a variable marking whether the package was found. std::string foundVar = this->Name; foundVar += "_FOUND"; this->Makefile->AddDefinition(foundVar.c_str(), found? "1":"0"); (I forgot the last line in my initial mail). So the variable is set afterwards unconditionally. The only condition where it would make a difference is if inside a FooConfig.cmake file there would be a check whether Foo_FOUND is already TRUE. I can do that. Don't forget to unset the variable before loading the module so we know whether the module defined it. Thanks, -Brad -- 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] Nightly Binary not building on windows
On 2/28/2012 1:57 PM, Brad King wrote:
On 2/28/2012 1:53 PM, Bill Hoffman wrote:
No matter what
find_package(foo)
Can not cause an error at CMake time.
That isn't the line causing the error. It's the AllFindModules test
that wants to know that the returned version information is as expected.
This is a real test failure because the FindSubversion module is not
properly detecting the version number of svn. The Find module needs
to be fixed for this case.
-Brad
I disagree... :)
The test does this:
message(STATUS "module: ${module}")
include("${module}")
That should not error out if it finds a bad version of software that
gives a bogus version string. I thought you could include any module
and not get a cmake error at configure time unless you set required.
-Bill
--
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] Nightly Binary not building on windows
On 2/28/2012 2:09 PM, Bill Hoffman wrote:
On 2/28/2012 1:57 PM, Brad King wrote:
On 2/28/2012 1:53 PM, Bill Hoffman wrote:
That isn't the line causing the error. It's the AllFindModules test
that wants to know that the returned version information is as expected.
This is a real test failure because the FindSubversion module is not
properly detecting the version number of svn. The Find module needs
to be fixed for this case.
I disagree... :)
The test does this:
message(STATUS "module: ${module}")
include("${module}")
This is not the FindModulesExecuteAll test. It is a new test.
I see no such code in the test:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeOnly/AllFindModules/CMakeLists.txt;hb=cffce2ff
but I do see its equivalent:
message(STATUS " Checking Find${MODULE_NAME}")
find_package(${MODULE_NAME})
That should not error out if it finds a bad version of software that gives a
bogus version string.
That is not the code that is erroring out. It returns as expected.
> I thought you could include any module and not get a cmake error at configure
time unless you set required.
The CMakeLists.txt of the AllFindModules test is the code that
reports the error. The error is not coming from a module at all.
The Linux nightly fails the same way:
CMake Error at CMakeLists.txt:55 (message):
ImageMagick_FOUND is set but no version number is defined
Call Stack (most recent call first):
CMakeLists.txt:65 (check_version_string)
-- Configuring incomplete, errors occurred!
CMake Error at Test.cmake:12 (message):
CMake failed to configure AllFindModules
Note that the call stack mentions nothing of any Find module.
-Brad
--
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] find_package module-only policy
On 2/28/2012 8:24 AM, Brad King wrote:
I replaced the FindPackage_ModeWarning topic on the stage with a
[snip]
However, I'm not yet prepared to merge this to next. I'm going
to make more significant edits to the proposed changes and post
them as a separate topic and then report back here.
I pushed new topic
find_package-improve-messages
that shares the beginning of FindPackage_ModeWarning but then
makes slightly different changes:
- I improved detection of options that conflict with MODULE.
CONFIG and NO_MODULE are not the only conflicts. Other options
imply Config mode too.
- I added a test to check the major failure case message text
by actually comparing it to known output. This is a stronger
test than your FindPackageTest change and provides a reference
for the message text of each case right in the source tree
without running anything.
- I decided to drop the warning for MODULE or CONFIG keywords
without a sufficiently high minimum required CMake version.
We don't warn for other commands that have new options, and
the project could guard the use with its own test of the
CMake version without actually bumping the min req version
e.g. "if(NOT ${CMAKE_VERSION} VERSION_LESS 2.8.8)". We should
not warn in such cases.
- I changed the warning text and documentation text of the
CMAKE_FIND_PACKAGE_WARN_NO_MODULE variable to change the tone
from "less ambiguous" to "more specific."
- I really don't want to ever warn in the default mode when
falling back to Config mode. I think the new failure message
text and explicit mode keywords are sufficient to solve this
problem. Therefore CMAKE_FIND_PACKAGE_WARN_NO_MODULE will be
required to get the warning and 2.8.8 will not warn by default.
IMO this topic is ready to be merged to 'next' for testing.
-Brad
--
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] Two pull requests
Hi! I've published two branches on gitorious. First, I run spellcheck on some source files. git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git ready/fix-typos Next, I fixed some doxygen formatting. git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git ready/apidocs- fixes The last commit in this branch replaces all '///!' by '///'. This can potentially conflict with many topic branches. One of the ways to avoid such conflicts is to run `sed -e 's,///!,///' -i *.h` in each branch that conflicts with apidocs-fixes branch. P.S.: Do you accept gitorious pull requests, or should I send e-mails like this? I don't want to fill a bug report in mantis for each small fix. -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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] Two pull requests
On 2/28/2012 2:46 PM, Yury G. Kudryashov wrote: > I've published two branches on gitorious. Thanks for your work! First, I run spellcheck on some source files. git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git ready/fix-typos Please combine those commits and write a single commit message that briefly explains the tools you ran to find the errors. Next, I fixed some doxygen formatting. git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git ready/apidocs- fixes Please prefix the commit messages with "doxygen: " since all the changes are for Doxygen comment formatting. The last commit in this branch replaces all '///!' by '///'. This can potentially conflict with many topic branches. One of the ways to avoid such conflicts is to run `sed -e 's,///!,///' -i *.h` in each branch that conflicts with apidocs-fixes branch. I'd rather make that as a sweeping change and then rebase active topics on it. This is better done right after a release when there are no major topics underway. Let's drop that commit for now. P.S.: Do you accept gitorious pull requests, or should I send e-mails like this? I don't want to fill a bug report in mantis for each small fix. We accept any form of patch that comes in if it is easy to apply. Fetching real Git commits is a nice way to get them :) Thanks! -Brad -- 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] find_package module-only policy
On Tuesday 28 February 2012, Brad King wrote:
> On 2/28/2012 8:24 AM, Brad King wrote:
> > I replaced the FindPackage_ModeWarning topic on the stage with a
>
> [snip]
>
> > However, I'm not yet prepared to merge this to next. I'm going
> > to make more significant edits to the proposed changes and post
> > them as a separate topic and then report back here.
>
> I pushed new topic
>
>find_package-improve-messages
>
> that shares the beginning of FindPackage_ModeWarning but then
> makes slightly different changes:
>
> - I improved detection of options that conflict with MODULE.
> CONFIG and NO_MODULE are not the only conflicts. Other options
> imply Config mode too.
>
> - I added a test to check the major failure case message text
> by actually comparing it to known output. This is a stronger
> test than your FindPackageTest change and provides a reference
> for the message text of each case right in the source tree
> without running anything.
>
> - I decided to drop the warning for MODULE or CONFIG keywords
> without a sufficiently high minimum required CMake version.
> We don't warn for other commands that have new options, and
> the project could guard the use with its own test of the
> CMake version without actually bumping the min req version
> e.g. "if(NOT ${CMAKE_VERSION} VERSION_LESS 2.8.8)". We should
> not warn in such cases.
>
> - I changed the warning text and documentation text of the
> CMAKE_FIND_PACKAGE_WARN_NO_MODULE variable to change the tone
> from "less ambiguous" to "more specific."
>
> - I really don't want to ever warn in the default mode when
> falling back to Config mode. I think the new failure message
> text and explicit mode keywords are sufficient to solve this
> problem. Therefore CMAKE_FIND_PACKAGE_WARN_NO_MODULE will be
> required to get the warning and 2.8.8 will not warn by default.
I would prefer to warn, but it's ok.
> IMO this topic is ready to be merged to 'next' for testing.
Fine with me :-)
I'll delete my various findpackage-branches from stage then ?
Thanks
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy
On 2/28/2012 3:02 PM, Alexander Neundorf wrote: On Tuesday 28 February 2012, Brad King wrote: IMO this topic is ready to be merged to 'next' for testing. Fine with me :-) I've now merged it :) I'll delete my various findpackage-branches from stage then ? In an earlier message I reported that I deleted most of them. I just now deleted FindPackage_ModeWarning as well. I have backups of all of the topics just in case. -Brad -- 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] Nightly Binary not building on windows
Am Dienstag, 28. Februar 2012, 14:20:27 schrieb Brad King:
> On 2/28/2012 2:09 PM, Bill Hoffman wrote:
> > On 2/28/2012 1:57 PM, Brad King wrote:
> >> On 2/28/2012 1:53 PM, Bill Hoffman wrote:
> >> That isn't the line causing the error. It's the AllFindModules test
> >> that wants to know that the returned version information is as expected.
> >> This is a real test failure because the FindSubversion module is not
> >> properly detecting the version number of svn. The Find module needs
> >> to be fixed for this case.
At this point one could say that Subversion_FOUND should not be set if svn
can't do anything useful. But that would be totally unexpected. The question
is why svn is broken on this machine.
> This is not the FindModulesExecuteAll test. It is a new test.
> I see no such code in the test:
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeOnly/AllFindModules
> /CMakeLists.txt;hb=cffce2ff
>
> but I do see its equivalent:
>
>message(STATUS " Checking Find${MODULE_NAME}")
>find_package(${MODULE_NAME})
>
> > That should not error out if it finds a bad version of software that gives
> > a bogus version string.
> That is not the code that is erroring out. It returns as expected.
>
> > I thought you could include any module and not get a cmake error at
> > configure time unless you set required.
> The CMakeLists.txt of the AllFindModules test is the code that
> reports the error. The error is not coming from a module at all.
>
> The Linux nightly fails the same way:
>
> CMake Error at CMakeLists.txt:55 (message):
>ImageMagick_FOUND is set but no version number is defined
> Call Stack (most recent call first):
>CMakeLists.txt:65 (check_version_string)
>
>
> -- Configuring incomplete, errors occurred!
> CMake Error at Test.cmake:12 (message):
>CMake failed to configure AllFindModules
>
> Note that the call stack mentions nothing of any Find module.
The whole idea of this test is that I can immediately see if anything breaks
the version detection code. If there is a valid point in this machine being
breaking then I will just remove subversion from the detection. Like I removed
GNUplot once we found out that there are versions out there that simply don't
print out their version number.
Can anyone please run "mogrify -version" on magrathea? This would save me one
turnaround in adding debug code to the find module and back. There was a bug
papering over this which has been fixed and now made this public.
Eike
signature.asc
Description: This is a digitally signed message part.
--
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] Two pull requests
Brad King wrote: > On 2/28/2012 2:46 PM, Yury G. Kudryashov wrote: >> git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git >> ready/fix-typos > > Please combine those commits and write a single commit message > that briefly explains the tools you ran to find the errors. I've also renamed branch. git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git run-vim- spellcheck > >> Next, I fixed some doxygen formatting. >> git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git ready/apidocs- >> fixes > > Please prefix the commit messages with "doxygen: " since all the > changes are for Doxygen comment formatting. Done, new branch: git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git doxygen-fixes > >> The last commit in this branch replaces all '///!' by '///'. This can >> potentially conflict with many topic branches. One of the ways to avoid >> such conflicts is to run `sed -e 's,///!,///' -i *.h` in each branch that >> conflicts with apidocs-fixes branch. > > I'd rather make that as a sweeping change and then rebase active > topics on it. This is better done right after a release when > there are no major topics underway. Let's drop that commit > for now. OK, dropped. > >> P.S.: Do you accept gitorious pull requests, or should I send e-mails >> like this? I don't want to fill a bug report in mantis for each small >> fix. > > We accept any form of patch that comes in if it is easy to apply. > Fetching real Git commits is a nice way to get them :) It seems that merge requests are disabled in repository settings. -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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
Brad King wrote: > On 2/25/2012 3:19 AM, Yury G. Kudryashov wrote: >> Yury G. Kudryashov wrote: >> >>> From: "Yury G. Kudryashov" >>> >> Mailman says that the next patch is too big. The compressed version is >> attached. > > While building I get: This branch compiles with -Werror here: git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git add-const- qualifiers -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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] Nightly Binary not building on windows
On Tue, Feb 28, 2012 at 3:48 PM, Rolf Eike Beer wrote: > The whole idea of this test is that I can immediately see if anything breaks > the version detection code. Right. That's what I was trying to explain. > If there is a valid point in this machine being > breaking then I will just remove subversion from the detection. Like I removed > GNUplot once we found out that there are versions out there that simply don't > print out their version number. > > Can anyone please run "mogrify -version" on magrathea? This would save me one > turnaround in adding debug code to the find module and back. There was a bug > papering over this which has been fixed and now made this public. $ mogrify -version mogrify: Missing an image file name. It's installed by package ImageMagick-5.2.3-3mdk and like gnuplot has no option for version query. -Brad -- 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] Two pull requests
On 2/28/2012 4:02 PM, Yury G. Kudryashov wrote: git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git run-vim-spellcheck git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git doxygen-fixes Thanks. I'll look at those topics when I get a chance. We accept any form of patch that comes in if it is easy to apply. Fetching real Git commits is a nice way to get them :) It seems that merge requests are disabled in repository settings. That's intentional, so in that sense we do not support first-class pull requests. We want requests to come through this mailing list. Thanks, -Brad -- 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
On Tue, Feb 28, 2012 at 4:07 PM, Yury G. Kudryashov wrote: > This branch compiles with -Werror here: > git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git add-const- > qualifiers I still get warnings like: Source/cmCommand.h:99:16: warning: ‘virtual bool cmCommand::IsScriptable() const’ was hidden [-Woverloaded-virtual] Source/cmMacroCommand.cxx:53:16: warning: by ‘virtual bool cmMacroHelperCommand::IsScriptable()’ [-Woverloaded-virtual] Please add -Woverloaded-virtual and try again. Thanks, -Brad -- 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] [CMake 0013003]: Precompiled CPack update needed for compatibility with Xcode 4.3
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13003 == Reported By:Dave Whipp Assigned To: == Project:CMake Issue ID: 13003 Category: CPack Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-02-28 20:49 EST Last Modified: 2012-02-28 20:49 EST == Summary:Precompiled CPack update needed for compatibility with Xcode 4.3 Description: When I attempt to use CPack to create a Mac application bundle it crashes attempting to find libraries/headers a directory tree location no longer used by Xcode (/Developer). I haven't tested many options, but the problem will occur every time it reaches the stage of creating the package using 'cpack -G DragNDrop'. I've been able to temporarily work around this issue by creating symbolic links from the location CPack is looking (/Developer/Headers) to the new location for Xcode 4.3 (/Applications/Xcode.app/Contents/Developer/Headers). If it matters, the specific program that I'm building is ParaView 3.14.0, configured using CMake and compiled using the GNU C and C++ compilers (with Qt 4.8.0). Steps to Reproduce: After configuring using CMake and building with the GNU compilers, I attempt to create an application bundle by typing: 'cpack -G DragNDrop --config ParaView-3.14.0-Build/Applications/ParaView/CPackParaViewConfig.cmake' The process runs for about 10-15 minutes before crashing with the following error message: '... CPack: Create package CPack Error: Error executing: /bin/bash -c "/usr/bin/Rez /Developer/Headers/FlatCarbon/*.r '/Users/dwhipp/Build/_CPack_Packages/Darwin-i386/DragNDrop/sla.r' -a -o '/Users/dwhipp/Build/_CPack_Packages/Darwin-i386/DragNDrop/temp-udco.dmg'" CPack Error: Error adding SLA. ### /usr/bin/Rez - SysError 0 during open of "/Developer/Headers/FlatCarbon/*.r". Fatal Error! ### /usr/bin/Rez - Fatal Error, can't recover. /Developer/Headers/FlatCarbon/*.r: ### /usr/bin/Rez - Since errors occurred, /Users/dwhipp/Build/_CPack_Packages/Darwin-i386/DragNDrop/temp-udco.dmg's resource fork was not completely updated. /Developer/Headers/FlatCarbon/*.r: ### /usr/bin/Rez - SysError -43 during set file info. CPack Error: Problem compressing the directory CPack Error: Error when generating package: ParaView' The obvious issue is that /Developer/Headers does not exist for Xcode 4.3, as noted above (now located at /Applications/Xcode.app/Contents/Developer/Headers). == Issue History Date ModifiedUsername FieldChange == 2012-02-28 20:49 Dave Whipp New Issue == -- 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
