Re: [CMake] cmake 2.6.3 RC 5
Brad King wrote: Alexander Neundorf wrote: So, I think it would be nice if find_package(NO_MODULE) would restore the FIND_QUIETLY variable to the state it was before (as I'm doing here manually). Good idea. I don't think we make any guarantee either way about the value of this variable *after* a call, but we do document how it is set *inside* the find-module (which is the case after the call in your example), so we should preserve it. I've added this to my todo-list. Fortunately fixing it won't break your work-around. Done. Please try it from CVS HEAD. -Brad /cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v -- Source/cmFindPackageCommand.cxx new revision: 1.50; previous revision: 1.49 /cvsroot/CMake/CMake/Source/cmFindPackageCommand.h,v -- Source/cmFindPackageCommand.h new revision: 1.26; previous revision: 1.25 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
On Wednesday 03 December 2008, Bill Hoffman wrote: I have a release candidate (RC 5) for 2.6.3 ready for CMake. I just built kdelibs and kdepimlibs svn trunk with current 2-6 branch of cmake and didn't notice obvious problems. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
On Monday 08 December 2008, Alexander Neundorf wrote:
On Wednesday 03 December 2008, Bill Hoffman wrote:
I have a release candidate (RC 5) for 2.6.3 ready for CMake.
I just built kdelibs and kdepimlibs svn trunk with current 2-6 branch of
cmake and didn't notice obvious problems.
Just a small thing:
I'm slowly converting a few of the FindFoo-modules from kdelibs to the new
Config-style.
E.g. for automoc4 our FindAutomoc4.cmake looks (basically) like:
set(_FIND_QUIETLY ${Automoc4_FIND_QUIETLY})
find_package(Automoc4 QUIET NO_MODULE)
set(Automoc4_FIND_QUIETLY ${_FIND_QUIETLY})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Automoc4 DEFAULT_MSG AUTOMOC4_EXECUTABLE)
The slightly ugly thing is the saving and restoring of the
Automoc4_FIND_QUIETLY variable.
I want to call find_packlage( NO_MODULE) with quiet, otherwise the user sees
the verbose built-in error message if no Config-file was found. But I don't
want this, since I just want the standard error message from
FindPackageHandleStandardArgs.cmake and even if the Config-mode fails, I
could still have my own handling and do some other searching.
Because of this I want to use QUIET for the NO_MODULE, but still want to
_FIND_QUIETLY variable as the user put it for the outer FindFoo.cmake file.
So, I think it would be nice if find_package(NO_MODULE) would restore the
FIND_QUIETLY variable to the state it was before (as I'm doing here
manually).
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
Alexander Neundorf wrote:
Just a small thing:
I'm slowly converting a few of the FindFoo-modules from kdelibs to the new
Config-style.
E.g. for automoc4 our FindAutomoc4.cmake looks (basically) like:
set(_FIND_QUIETLY ${Automoc4_FIND_QUIETLY})
find_package(Automoc4 QUIET NO_MODULE)
set(Automoc4_FIND_QUIETLY ${_FIND_QUIETLY})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Automoc4 DEFAULT_MSG AUTOMOC4_EXECUTABLE)
The slightly ugly thing is the saving and restoring of the
Automoc4_FIND_QUIETLY variable.
I want to call find_packlage( NO_MODULE) with quiet, otherwise the user sees
the verbose built-in error message if no Config-file was found. But I don't
want this, since I just want the standard error message from
FindPackageHandleStandardArgs.cmake and even if the Config-mode fails, I
could still have my own handling and do some other searching.
Because of this I want to use QUIET for the NO_MODULE, but still want to
_FIND_QUIETLY variable as the user put it for the outer FindFoo.cmake file.
So, I think it would be nice if find_package(NO_MODULE) would restore the
FIND_QUIETLY variable to the state it was before (as I'm doing here
manually).
Good idea. I don't think we make any guarantee either way about the
value of this variable *after* a call, but we do document how it is set
*inside* the find-module (which is the case after the call in your
example), so we should preserve it.
I've added this to my todo-list. Fortunately fixing it won't break your
work-around.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
2.6.3R5 behaving a little strangely on one of my test projects. I have a program that generates cpp files from some input file. My program also outputs a dependency file which I parse into a CMake readable format. The basic setup creates a cmake script using configure_file with all the commands to build my cpp and dependency files. A custom target executes the cmake script during build. Also during configuration the dependency file that was generated by the build tool is included into CMake to define source level dependencies. I'm using VS 2005 32/64 on WinXP 64. VS is set to build projects in parallel. In 2.6.2, this problem doesn't appear. In 2.6.3R5, if I hit rebuild some of the tools would start to complain about missing files as CMake starts to regenerate stuff in the middle of the build (or end of the project compilation). This only happens sometimes. If I do a clean followed by a build it works just fine. This is output from a project that completed successfully: Building Custom Rule C:/code/CMake-cuda-staging/src/CMakeLists.tx CMake is re-running because build system is out-of-date. -- Configuring done -- Generating done -- Build files have been written to: C:/code/CMake-cuda-staging/build-64 Compiling... Output from a project that failed Building Custom Rule C:/code/CMake-cuda-staging/src/CMakeLists.txt CMake is re-running because build system is out-of-date. CMake Error: Could not open file for write in copy operation C:/code/CMake-cuda-staging/build-64/src/cuda/test_generated_test_bin.cu.cpp.cmake.tmp CMake Error: : System Error: Invalid argument CMake Error at CMake/cuda/FindCUDA.cmake:609 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMake/cuda/FindCUDA.cmake:685 (CUDA_add_custom_commands) src/CMakeLists.txt:21 (CUDA_ADD_EXECUTABLE) CMake Error: Could not open file for write in copy operation C:/code/CMake-cuda-staging/build-64/src/cuda/cuda_compile_generated_test_bin.cu.cpp.cmake.tmp CMake Error: : System Error: Invalid argument CMake Error at CMake/cuda/FindCUDA.cmake:609 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMake/cuda/FindCUDA.cmake:709 (CUDA_add_custom_commands) src/CMakeLists.txt:44 (CUDA_COMPILE) -- Configuring incomplete, errors occurred! Project : error PRJ0019: A tool returned an error code from Building Custom Rule C:/code/CMake-cuda-staging/src/CMakeLists.txt Another: Building Custom Rule C:/code/CMake-cuda-staging/src/CMakeLists.txt CMake is re-running because build system is out-of-date. -- Configuring done CMake Error: Unable to open check cache file for write. C:/code/CMake-cuda-staging/build-64/CMakeFiles/cmake.check_cache Project : error PRJ0019: A tool returned an error code from Building Custom Rule C:/code/CMake-cuda-staging/src/CMakeLists.txt I'm guessing there is a race condition involving the cmake state that wasn't there with the last release. I can share the project I'm working on, but you would need a NVIDIA card that supports CUDA and the CUDA toolkit. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake 2.6.3 RC 5
I have a release candidate (RC 5) for 2.6.3 ready for CMake. Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-5* The changes from 2.6.2 to 2.6.3 are as follows: Changes in CMake 2.6.3 RC 5 - add EXCLUDE, INCLUDE to ctest_test command in ctest -S scripts - Set CMAKE_SYSTEM in ctest -S scripts by reading CMakeDetermineSystem - Fix for GetLibraryNamesInternal called on imported target issue on osx - Add FortranCInterface.cmake module to discover Fortran/C interfaces - Fix Fortran compiler specified with -D issue - Add support for the MS masm and masm64 assemblers, works with nmake/make - Improvments to FindQt4.cmake - InstallRequiredSystemLibraries fix for win64 - Fix flags for Sun Fortran, and g77 - Fix imported library issue with OSX - Fix -D and CACHE FORCE issue - Have kwsys submit dashboards to cdash.org Changes in CMake 2.6.3 RC 4 - Fix for SccProvider in visual studio - fix for missing package_source target - FindQt4 QT_PHONON_MODULE_DEPENDS fixes - Fixes for GetPrerequisites.cmake system libraries on Mac and UNIX - Merge in kwsys Haiku DynaimcLoader change Changes in CMake 2.6.3 RC 3 - Merge in CMakeLists.txt curl Haiku change Changes in CMake 2.6.3 RC 2 - Merge in more Haiku changes Changes in CMake 2.6.3 RC 1 - Better reporting when nmake compiler environment is not correct - Fix bug #5936 set locale when running cvs and svn - Teach find_library to find OpenBSD-style libs (issue #3470). - Fix lib/ to lib/64/ search path conversion - Fix CPack DESTDIR issue - Support longer command lines with windows nmake and make - Fix bug with color check for dependency scanning - Use new link info during dependency scanning - Fix find_* search order with path suffixes - Fix install with multiple configurations and makefiles. - Improve find_package interface for recursive find modules. - Fix build issues with older visual studio versions - Fix Xcode release builds - Put custom target sources in Xcode projects - Fix return value from cmake -E time commands - Fix documentation for cmake --debug-trycompile - Add Haiku support - Fix bug, allow enable_language to be called for C after CXX - Add FindCoin3D.cmake - Fix bug in FindGLUT.cmake - Better find of perl in FindPerlLibs.cmake - FindQt4 Fix #7784, Fix #7433 - FindQt4 refind qt when qmake changes - Fix to find wxWidgets_LIB_DIR for windows platform more generally. - Find ttkstup in FindTclStub.cmake - Skip a command if its arguments fail to parse - Fix convenience rule working directory - Add support for source code control and visual stuido - Add parenthetical expressions to if - Fix Rc command with -D options and nmake - Fix NSIS detection on windows 2000 - Display an error message in ccmake when there are errors -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
On Wednesday 03 December 2008 16:36:23 Bill Hoffman wrote: I have a release candidate (RC 5) for 2.6.3 ready for CMake. Did my PATCH: Bundle Generator need not require CPACK_BUNDLE_STARTUP_COMMAND ever get applied for 2.6.3? -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
Mike Arthur wrote: On Wednesday 03 December 2008 16:36:23 Bill Hoffman wrote: I have a release candidate (RC 5) for 2.6.3 ready for CMake. Did my PATCH: Bundle Generator need not require CPACK_BUNDLE_STARTUP_COMMAND ever get applied for 2.6.3? I don't think so... Is it in CVS CMake yet? What is the bug entry for it? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
2008/12/3 Bill Hoffman [EMAIL PROTECTED]: I have a release candidate (RC 5) for 2.6.3 ready for CMake. I think the following patch http://public.kitware.com/Bug/view.php?id=7904 deserve inclusion since it is fully backward compatible and adds a requested feature. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
