[cmake-developers] [CMake 0013241]: WriteBasicConfigVersionFile produces bad files without CMAKE_SIZEOF_VOID_P
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13241 == Reported By:Brad King Assigned To:Alex Neundorf == Project:CMake Issue ID: 13241 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: assigned Target Version: CMake 2.8.9 == Date Submitted: 2012-05-21 11:49 EDT Last Modified: 2012-05-21 11:49 EDT == Summary:WriteBasicConfigVersionFile produces bad files without CMAKE_SIZEOF_VOID_P Description: Modules/BasicConfigVersion-*.cmake.in contain the code # check that the installed version has the same 32/64bit-ness as the one which is currently searching: if(NOT "${CMAKE_SIZEOF_VOID_P}" STREQUAL "@CMAKE_SIZEOF_VOID_P@") math(EXPR installedBits "@CMAKE_SIZEOF_VOID_P@ * 8") set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)") set(PACKAGE_VERSION_UNSUITABLE TRUE) endif() When this is configured with an empty CMAKE_SIZEOF_VOID_P the resulting file breaks. This breaks find_package calls that load the version file with an outright error instead of reporting an unsuitable version. == Issue History Date ModifiedUsername FieldChange == 2012-05-21 11:49 Brad King New Issue 2012-05-21 11:49 Brad King Status new => assigned 2012-05-21 11:49 Brad King Assigned To => Alex Neundorf == -- 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 0013240]: update documentation for FindPythonLibs.cmake
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=13240 == Reported By:Zack Galbreath Assigned To: == Project:CMake Issue ID: 13240 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-21 11:21 EDT Last Modified: 2012-05-21 11:21 EDT == Summary:update documentation for FindPythonLibs.cmake Description: A CMake user approached me with the problem that they couldn't change which installed version of Python was picked up by CMake. This is actually possible, but they were confused because the variables mentioned in the documentation do not include the ones that you actually need to change (the cache variables). Steps to Reproduce: N/A Additional Information: Attached is a patch to update the documentation, informing users on how to change which installed version of Python is found by CMake. == Issue History Date ModifiedUsername FieldChange == 2012-05-21 11:21 Zack Galbreath New Issue 2012-05-21 11:21 Zack Galbreath File Added: 0001-Improve-documentation-for-FindPythonLibs.patch == -- 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 0013239]: Not all Fortran dependencies are recognized.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13239 == Reported By:C.M. Assigned To: == Project:CMake Issue ID: 13239 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-21 11:09 EDT Last Modified: 2012-05-21 11:09 EDT == Summary:Not all Fortran dependencies are recognized. Description: Pre-processor dependencies in FORTRAN using include files are not recognized if specified as #include <...> which (at least for several Fortran preprocessors is a valid syntax), e.g. http://www2.fz-juelich.de/jsc/docs/vendordocs/NAGWare_f95 /html/fpp.html#INCEXTERNAL Steps to Reproduce: Generate any Fortran file and insert an include statement #include into it. Check the "*.depend" files. The include file is not listed. Using #include "file" does however list the dependency correctly. Additional Information: Reason for this behavior is the flex rule in cmDependsFortranLexer.in.l line 73-90 and 111 which allows strings only as "" or ''. Adding here a third string rule for <...> does quick fix the problem. However, one probably should create a new string type and add/change the CPP_INCLUDE parser rule in cmDependsFortranParser.y as well to not allow all strings to be <>. == Issue History Date ModifiedUsername FieldChange == 2012-05-21 11:09 C.M. 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
[cmake-developers] [CMake 0013238]: set_tests_properties not documented
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=13238 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 13238 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-05-21 10:55 EDT Last Modified: 2012-05-21 10:55 EDT == Summary:set_tests_properties not documented Description: it would be nice if all properties of set_tests_properties would be documented. It looks like the following are not documented: $ grep "key ==" Source/CTest/cmCTestTestHandler.cxx if ( key == "WILL_FAIL" ) if ( key == "ATTACHED_FILES" ) if ( key == "ATTACHED_FILES_ON_FAIL" ) if ( key == "RESOURCE_LOCK" ) if ( key == "TIMEOUT" ) if ( key == "COST" ) if ( key == "REQUIRED_FILES" ) if ( key == "RUN_SERIAL" ) if ( key == "FAIL_REGULAR_EXPRESSION" ) if ( key == "PROCESSORS" ) if ( key == "DEPENDS" ) if ( key == "ENVIRONMENT" ) if ( key == "LABELS" ) if ( key == "MEASUREMENT" ) if ( key == "PASS_REGULAR_EXPRESSION" ) if ( key == "WORKING_DIRECTORY" ) == Issue History Date ModifiedUsername FieldChange == 2012-05-21 10:55 Mathieu MalaterreNew 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
Re: [cmake-developers] conditionals in generator expressions
On 05/19/2012 04:45 PM, Alexander Neundorf wrote: > On Thursday 17 May 2012, David Cole wrote: >> I don't think this conditional stuff in generator expressions is a good >> idea at all. > > Me too ;-) The goal is to allow per-configuration/per-language/per-xyz values to appear in places like the INCLUDE_DIRECTORIES property of a target. Unlike COMPILE_DEFINITIONS the *order* of include directories matters. Therefore we cannot have a separate INCLUDE_DIRECTORIES_ property because there is no well-defined way to integrate its entries with those of the main property. There was discussion of this back when Stephen first brought up his patch for per-target include directories. The solution is to have a single property only and put the condition in the value. Since the configuration is not known until generate time any condition based on the configuration must be evaluated at generate time. We need to have generate-time evaluation of a condition stored in a value of a property. This touches on a declarative specification. The closest we have to this now is the "debug" and "optimized" keywords of tll(). -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] Some dashboard warnings and errors
2012/5/21 Brad King : > On 05/21/2012 03:50 AM, Eric Noulard wrote: >> My merge of "stage/CPack-activateRPM-DEB-onMacOS" to next yesterday raised >> some warning on this dashboard: >> http://open.cdash.org/viewBuildError.php?type=1&buildid=2293803 >> >> the warning are right, the static method call *is always true* but >> shall I really try to avoid such warning? >> The always true may become "some day" not always true but I wanted to have >> CPackGeneratorFactory be coded in a uniform way. >> >> What shall I do with that? > > Try this: > > diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx > b/Source/CPack/cmCPackGeneratorFactory.cxx > index dbfdbbc..37ff460 100644 > --- a/Source/CPack/cmCPackGeneratorFactory.cxx > +++ b/Source/CPack/cmCPackGeneratorFactory.cxx > @@ -40,6 +40,10 @@ > > #include "cmCPackLog.h" > > +#if defined(__BORLANDC__) > +# pragma warn -8008 /* condition is always true */ > +#endif > + > //-- > cmCPackGeneratorFactory::cmCPackGeneratorFactory() > { Ok just pushed that: Merge topic 'CPack-activateRPM-DEB-onMacOS' into next 801ea70 Calm down Borland compiler warning about "always true" >> Then the same set of commits may be responsible for that: >> http://open.cdash.org/buildSummary.php?buildid=2294180 >> >> but I can't find a reason for all 192 failing tests, can anyone enlight me? >> The only thing I see is >> >> "[flag] ArgumentExpansion Failed Passed 900ms Completed (SEGFAULT)" >> >> I cannot imagine why my change would generate such SEGFAULT series ... > > The same machine passed its nightly build so something local must have > gone wrong for the continuous. I don't think it's related to your change. ok then. Thanks Brad. -- 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] Some dashboard warnings and errors
On 05/21/2012 03:50 AM, Eric Noulard wrote: > My merge of "stage/CPack-activateRPM-DEB-onMacOS" to next yesterday raised > some warning on this dashboard: > http://open.cdash.org/viewBuildError.php?type=1&buildid=2293803 > > the warning are right, the static method call *is always true* but > shall I really try to avoid such warning? > The always true may become "some day" not always true but I wanted to have > CPackGeneratorFactory be coded in a uniform way. > > What shall I do with that? Try this: diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx b/Source/CPack/cmCPackGeneratorFactory.cxx index dbfdbbc..37ff460 100644 --- a/Source/CPack/cmCPackGeneratorFactory.cxx +++ b/Source/CPack/cmCPackGeneratorFactory.cxx @@ -40,6 +40,10 @@ #include "cmCPackLog.h" +#if defined(__BORLANDC__) +# pragma warn -8008 /* condition is always true */ +#endif + //-- cmCPackGeneratorFactory::cmCPackGeneratorFactory() { > Then the same set of commits may be responsible for that: > http://open.cdash.org/buildSummary.php?buildid=2294180 > > but I can't find a reason for all 192 failing tests, can anyone enlight me? > The only thing I see is > > "[flag] ArgumentExpansion Failed Passed 900ms Completed (SEGFAULT)" > > I cannot imagine why my change would generate such SEGFAULT series ... The same machine passed its nightly build so something local must have gone wrong for the continuous. I don't think it's related to your change. -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] Some dashboard warnings and errors
Hi all, My merge of "stage/CPack-activateRPM-DEB-onMacOS" to next yesterday raised some warning on this dashboard: http://open.cdash.org/viewBuildError.php?type=1&buildid=2293803 the warning are right, the static method call *is always true* but shall I really try to avoid such warning? The always true may become "some day" not always true but I wanted to have CPackGeneratorFactory be coded in a uniform way. What shall I do with that? Then the same set of commits may be responsible for that: http://open.cdash.org/buildSummary.php?buildid=2294180 but I can't find a reason for all 192 failing tests, can anyone enlight me? The only thing I see is "[flag] ArgumentExpansion Failed Passed 900ms Completed (SEGFAULT)" I cannot imagine why my change would generate such SEGFAULT series ... -- 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