[CMake] Error out on installation when there is already an installation when setting directory permissions
This is a followup to http://www.cmake.org/pipermail/cmake/2011-April/044095.html: On 04/28/2011 01:51 PM, John R. Cary wrote: / This is in reference to // // iter.cary$ cmake --version // cmake version 2.8.3 // iter.cary$ uname -a // Linux iter.txcorp.com 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 // 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux // // // We have a situation where a package needs to be // rebuilt because some dependency is rebuilt. In // this case, trilinos needs rebuilding because it // depends on openmpi and the version of opempi gets // updated. // // Typically, these installations are in a common area, // but by different people. So one night Joe triggers // a build a trilinos. Then the next night a new version // of openmpi is available, so Mary triggers a build of // openmpi and then trilinos. // // In this situation, Mary's installation of trilinos // fails, because cmake's installation does not overwrite // some files: // // -- Installing: // /usr/local/contrib/trilinos-10.2.0-ser/include/Teuchos_DLLExportMacro.h // -- Up-to-date: // /usr/local/contrib/trilinos-10.2.0-ser/include/Teuchos_AbstractFactory.hpp // CMake Error at packages/teuchos/src/cmake_install.cmake:54 (FILE): // file INSTALL cannot set permissions on // // /usr/local/contrib/trilinos-10.2.0-ser/include/Teuchos_AbstractFactory.hpp // Call Stack (most recent call first): // packages/teuchos/cmake_install.cmake:48 (INCLUDE) // cmake_install.cmake:41 (INCLUDE) // // but then apparently tries to set the permissions anyway. But // since it did not overwrite, Mary does not own the files, and // so she cannot set the perms. The result being that the installation // errors out as above, possibly not completing, but at the very // least returning an error code that must be chased down. // // It seems to me that one should overinstall, even if the // file is there, if one is going to try to set permissions // afterwards. Is there a way to force such overinstallation // in cmake? Or perhaps not error out on a perm change if the // exising perms are okay? // // ThxJohn Cary / You might try make install CMAKE_INSTALL_ALWAYS=1, cf. [1]. Regards, Michael [1]http://www.cmake.org/Wiki/CMake_Useful_Variables Except that now I am at $ cmake --version cmake version 2.8.6 $ uname -a Linux zippy.txcorp.com 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux $ gcc --version gcc (GCC) 4.6.2 Using CMAKE_INSTALL_ALWAYS=1 works for files, but if there is a directory installed by a previous user, it does not: file INSTALL cannot set permissions on /internal/txphysics-r1533-ser/tests/txeedldata-tests/accepted_output Call Stack (most recent call first): tests/cmake_install.cmake:45 (INCLUDE) cmake_install.cmake:87 (INCLUDE) make: *** [install] Error 1 (/internal/txphysics-r1533-ser/tests/txeedldata-tests/accepted_output is a directory.) It seems that even with CMAKE_INSTALL_ALWAYS=1, previously installed directories are not removed before the new installation. Is there a way to make this happen? Thx.John -- 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] find_library finds same library over and again
Feels like I am doing something wrong.
Looking for multiple libraries:
$ cat CMakeLists.txt
set(mylibdir /contrib/netcdf-4.1.2-ser/lib)
foreach (name netcdf_c++ netcdff netcdf)
message(Looking for ${name} in ${mylibdir}.)
find_library(mylib NAMES ${name} PATHS ${mylibdir} NO_DEFAULT_PATH)
if (mylib)
message(Found: ${mylib}.)
list(APPEND mylibs ${mylib})
else ()
message(Not found.)
endif ()
endforeach ()
But continues to find the first each time:
$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Looking for netcdf_c++ in /contrib/netcdf-4.1.2-ser/lib.
Found: /contrib/netcdf-4.1.2-ser/lib/libnetcdf_c++.dylib.
Looking for netcdff in /contrib/netcdf-4.1.2-ser/lib.
Found: /contrib/netcdf-4.1.2-ser/lib/libnetcdf_c++.dylib.
Looking for netcdf in /contrib/netcdf-4.1.2-ser/lib.
Found: /contrib/netcdf-4.1.2-ser/lib/libnetcdf_c++.dylib.
CMake Warning (dev) in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as
cmake_minimum_required(VERSION 2.8)
should be added at the top of the file. The version specified may be
lower
if you wish to support older CMake versions for this project. For more
information run cmake --help-policy CMP.
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/cary
even though all libraries are present:
$ ls /contrib/netcdf-4.1.2-ser/lib
libnetcdf.7.dyliblibnetcdf_c++.alibnetcdff.dylib
libnetcdf.alibnetcdf_c++.dyliblibnetcdff.la
libnetcdf.dyliblibnetcdf_c++.lapkgconfig
libnetcdf.lalibnetcdff.5.dylib
libnetcdf_c++.4.dyliblibnetcdff.a
$ cmake --version
cmake version 2.8.5
$ uname -a
Darwin numbersix.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
?
John Cary
--
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] Dependent variable definitions disappear in fortran module files
This was in fact the case. Sorry not to report back...John On 10/4/11 6:09 AM, Brad King wrote: On 9/30/2011 1:15 PM, John R. Cary wrote: When I build the definitions from the dependency are missing from the .mod file: [snip] So something later in the cmake build seems to be removing these definitions. Perhaps another target compiles the/a source file producing the same .mod file but with different definitions later in the build? That may overwrite the .mod file with a different one. -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://www.cmake.org/mailman/listinfo/cmake
[CMake] Removing C-style comments from fortran include file?
I am using the cmakedefine mechanism for a fortran include file. If the variable is not defined, rather than /* #undef HAVE_PLASMASTATE */ I need ! #undef HAVE_PLASMASTATE Are there existing solutions? Thx...John Cary -- 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] Dependent variable definitions disappear in fortran module files
I have a library that depends on another library (netcdf). When I build the definitions from the dependency are missing from the .mod file: octet.cary$ grep -i nf_inq_varid ezcdf_attrib.mod octet.cary$ But if I just compile again, they are there: octet.cary$ /usr/bin/gfortran -DHAVE_CONFIG_H -fPIC -pipe -O3 -I/usr/local/contrib/netcdf-4.1.2-ser/include-c /home/research/cary/projects/facetsall/builds/fciowrappers-1.0.48-r124/ezcdf/ezcdf_attrib.f90 -o CMakeFiles/ezcdf.dir/ezcdf_attrib.f90.o octet.cary$ grep -i nf_inq_varid ezcdf_attrib.mod403 'nf_inq_varid' 'ezcdf_attrib' 'nf_inq_varid' 1 ((PROCEDURE404 'nf_inq_varids' 'ezcdf_attrib' 'nf_inq_varids' 1 ((PROCEDURE'nf_inq_vardimid' 0 402 'nf_inq_varid' 0 403 'nf_inq_varids' 0 404 So something later in the cmake build seems to be removing these definitions. Any idea how to keep them? Thx.John Cary -- 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] Why do jom/nmake generators require cl to build with mingw?
I was trying to configure a project to use jom or name with the mingw compilers. I was configuring with cmake \ -DCMAKE_INSTALL_PREFIX:PATH=C:/winsame/volatile-mingw/txphysics-r1504-ser \ -DCMAKE_BUILD_TYPE:STRING=RELEASE \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \ -DCMAKE_INSTALL_ALWAYS:BOOL=TRUE \ -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE \ -G 'NMake Makefiles' \ -DCMAKE_C_COMPILER:FILEPATH='mingw32-gcc' \ -DCMAKE_CXX_COMPILER:FILEPATH='mingw32-g++' \ -DCMAKE_Fortran_COMPILER:FILEPATH='mingw32-gfortran' \ C:/cygwin/home/user/vorpalall-mg/txphysics but got the warning, CMake Warning at CMakeLists.txt:10 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. and ultimately the error, CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU.cmake:60 (enable_language) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 (include) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 (INCLUDE) CMakeLists.txt:2 (PROJECT) So I did put cl in my path, and now it configures, but this seems strange. Is it necessary to still have cl when using mingw? ThxJohn Cary ___ 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] Why do jom/nmake generators require cl to build with mingw?
On 9/15/11 8:27 AM, John Drescher wrote: On Thu, Sep 15, 2011 at 8:08 AM, John R. Caryc...@txcorp.com wrote: I was trying to configure a project to use jom or name with the mingw compilers. I was configuring with cmake \ -DCMAKE_INSTALL_PREFIX:PATH=C:/winsame/volatile-mingw/txphysics-r1504-ser \ -DCMAKE_BUILD_TYPE:STRING=RELEASE \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \ -DCMAKE_INSTALL_ALWAYS:BOOL=TRUE \ -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE \ -G 'NMake Makefiles' \ -DCMAKE_C_COMPILER:FILEPATH='mingw32-gcc' \ -DCMAKE_CXX_COMPILER:FILEPATH='mingw32-g++' \ -DCMAKE_Fortran_COMPILER:FILEPATH='mingw32-gfortran' \ C:/cygwin/home/user/vorpalall-mg/txphysics but got the warning, CMake Warning at CMakeLists.txt:10 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. and ultimately the error, CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU.cmake:60 (enable_language) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 (include) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 (INCLUDE) CMakeLists.txt:2 (PROJECT) So I did put cl in my path, and now it configures, but this seems strange. Is it necessary to still have cl when using mingw? I thought jom and nmake Generators were both for Visual Studio. I seem to be able to use them in a cygwin shell, but only if I have cl and all the defines in my path, even if I never use cl in the compilation (because I def'd the compilers to be mingw...) Also, jom, cl, mingw, nmake all have the same (Windows) path concepts, instead of the cygwin paths. So I think they should work together, and I observe that they do. So not sure how to answer your question John ___ 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] How to create a 64-bit Windows build of cmake? Added for building vtk-5.0.0
To close out this thread, I think I can now explain what was
happening.
I was indeed getting a win64-release version of cmake, by
configuring in a Visual Studio Win64 command window with
cmake \
-G 'NMake Makefiles'
-DCMAKE_INSTALL_PREFIX:PATH=C:/winsame/contrib-vs9/cmake-2.8.5-ser \
-DCMAKE_BUILD_TYPE:STRING=RELEASE \
-DCMAKE_C_COMPILER:FILEPATH='cl' \
-DCMAKE_CXX_COMPILER:FILEPATH='cl'
path to source
then doing nmake; nmake package and using that package
to install cmake. This only problem was that the default
location came out as /Program Files/... instead of /Program
Files (x86)/..., but this was modified at installation time.
But then in configuring VTK, CMake was constructing the
libraries, such as cmVTK_WRAP_TCL2.dll, as Debug. The problem
was that the flag, -DCMAKE_BUILD_TYPE:STRING=RELEASE,
was not getting used by the TRY_COMPILE in
CMake/vtkCompileCMakeExtensions.cmake to configure
CMake/CMakeLists.txt.
CMake/vtkCompileCMakeExtensions.cmake, which is used by the
configuration of CMake/CMakeLists.txt. So now I send this
explicitly as shown in the patch below. All now configures
and builds.
So should CMake pass the flag, CMAKE_BUILD_TYPE, automatically
to try_compile? Or should the module do that? (It would seem
that CMake would have to send its build type to the module if
it were to load it, but it would have to respect the build type
if a built application were to load it.) Because I my
uncertainty, do not know whether to report this as a bug.
Thx..John Cary
cat vtk-5.0.0i.patch
diff -ruN vtk-5.0.0i/CMake/vtkCompileCMakeExtensions.cmake
vtk-5.0.0i-new/CMake/vtkCompileCMakeExtensions.cmake
--- vtk-5.0.0i/CMake/vtkCompileCMakeExtensions.cmake2011-03-25
18:03:24.0 -0600
+++ vtk-5.0.0i-new/CMake/vtkCompileCMakeExtensions.cmake
2011-08-04 07:18:16.0 -0600
@@ -19,9 +19,13 @@
IF(COMMAND VTK_WRAP_TCL2)
ELSE(COMMAND VTK_WRAP_TCL2)
MESSAGE(STATUS Compiling VTK CMake commands)
+ set(TRY_COMPILE_OTHER_FLAGS)
+ if (CMAKE_BUILD_TYPE)
+set(TRY_COMPILE_OTHER_FLAGS ${TRY_COMPILE_OTHER_FLAGS}
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE})
+ endif ()
TRY_COMPILE(${result_var} ${build_dir} ${source_dir}
VTK_LOADED_COMMANDS
-CMAKE_FLAGS -DVTK_BUILD_FROM_TRY_COMPILE:BOOL=TRUE
+CMAKE_FLAGS -DVTK_BUILD_FROM_TRY_COMPILE:BOOL=TRUE
${TRY_COMPILE_OTHER_FLAGS}
OUTPUT_VARIABLE VTK_COMPILE_CMAKE_EXTENSIONS_OUTPUT)
IF(${result_var})
MESSAGE(STATUS Compiling VTK CMake commands - done)
diff -ruN vtk-5.0.0i/Common/vtkPythonUtil.cxx
vtk-5.0.0i-new/Common/vtkPythonUtil.cxx
--- vtk-5.0.0i/Common/vtkPythonUtil.cxx 2011-03-25 18:03:25.0 -0600
+++ vtk-5.0.0i-new/Common/vtkPythonUtil.cxx 2011-08-04
07:13:41.0 -0600
@@ -27,6 +27,7 @@
#include vtkstd/map
#include vtkstd/string
+#include cstddef
#if defined ( _MSC_VER )
# define vtkConvertPtrToLong(x) ((long)(PtrToUlong(x)))
Date: Tue, 2 Aug 2011 09:42:07 -0400
From: David Cole david.c...@kitware.com
Subject: Re: [CMake] How to create a 64-bit Windows build of cmake?
To: John R. Cary c...@txcorp.com
Cc: cmake Mailing List cmake@cmake.org
Message-ID:
caadwe9wsd7btgpv7s6pzba0feysumq1hrv-ua1xthj9sdpo...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Try commenting out the one line that causes problems, then back up
from there, either commenting chunks out or adjusting CMake options
until those commands are not loaded.
On Tue, Aug 2, 2011 at 8:50 AM, John R. Cary c...@txcorp.com wrote:
Thanks for your response. ?This will definitely decrease my headpain.
It turns out that I need vtk-5.0.0, but right now I am not sure
that I need the wrapping code. ?Am checking on this.
Would it make sense to just not call vtkLoadCMakeExtensions.cmake?
ThxJohn Cary
On 8/2/11 5:00 AM, David Cole wrote:
On Tue, Aug 2, 2011 at 7:00 AM, David Coledavid.c...@kitware.com
?wrote:
On Mon, Aug 1, 2011 at 8:34 PM, John R. Caryc...@txcorp.com ?wrote:
I believe I have followed what I have found on the web for
building a Win64 version of CMake. ?I have downloaded the
win32 version and used it to configure the cmake source.
I used the Visual Studio 9 2008 Win64 generator.
However, when I then use that cmake to configure vtk (an
old version, 5.0.0) I get the much discussed error,
-- Loading VTK CMake commands
CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND):
?load_command Attempt to load the library
?C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll
?failed. ?Additional error info is:
?The application has failed to start because its side-by-side
configuration
?is incorrect. ?Please see the application event log or use the
command-line
?sxstrace.exe tool for more detail.
Call Stack (most recent call first):
?CMake/vtkLoadCMakeExtensions.cmake:27
(VTK_LOAD_SINGLE_CMAKE_EXTENSION)
?CMakeLists.txt:632
Re: [CMake] How to create a 64-bit Windows build of cmake?
Thanks for your response. This will definitely decrease my headpain. It turns out that I need vtk-5.0.0, but right now I am not sure that I need the wrapping code. Am checking on this. Would it make sense to just not call vtkLoadCMakeExtensions.cmake? ThxJohn Cary On 8/2/11 5:00 AM, David Cole wrote: On Tue, Aug 2, 2011 at 7:00 AM, David Coledavid.c...@kitware.com wrote: On Mon, Aug 1, 2011 at 8:34 PM, John R. Caryc...@txcorp.com wrote: I believe I have followed what I have found on the web for building a Win64 version of CMake. I have downloaded the win32 version and used it to configure the cmake source. I used the Visual Studio 9 2008 Win64 generator. However, when I then use that cmake to configure vtk (an old version, 5.0.0) I get the much discussed error, -- Loading VTK CMake commands CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND): load_command Attempt to load the library C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll failed. Additional error info is: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. Call Stack (most recent call first): CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION) CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS) CMake Error at CMake/vtkLoadCMakeExtensions.cmake:11 (MESSAGE): Loading VTK command VTK_WRAP_TCL2 - failed Call Stack (most recent call first): CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION) CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS) Using sxstrace shows INFO: Parsing Manifest File C:\winsame\cary\builds-vs9\composerall\vtk-5.0.0i\ser\CMake\cmVTK_WRAP_TCL2.dll. INFO: Manifest Definition Identity is (null). INFO: Reference: Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8 INFO: Resolving reference Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8. INFO: Resolving reference for ProcessorArchitecture amd64. which seems to indicate that even though I built cmake with the VS9-Win64 generator, cmake somehow created the dll as win32? Even though cmake says, -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/amd64/cl.exe showing that it found the 64-bit compiler? Any hints on what to do next? Thx...John Cary ___ 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 This is a problem with VTK 5.0, not a problem with CMake... Since VTK 5.0, the loaded custom CMake commands have been eliminated from VTK for just this reason. Can you use VTK 5.2, 5.4 or 6.5 instead...? (I'm not 100% sure exactly when that problem was fixed, but a more recent VTK should fix this issue.) make that 5.2, 5.4 or **5.6**... ___ 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] How to create a 64-bit Windows build of cmake?
I believe I have followed what I have found on the web for building a Win64 version of CMake. I have downloaded the win32 version and used it to configure the cmake source. I used the Visual Studio 9 2008 Win64 generator. However, when I then use that cmake to configure vtk (an old version, 5.0.0) I get the much discussed error, -- Loading VTK CMake commands CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND): load_command Attempt to load the library C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll failed. Additional error info is: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. Call Stack (most recent call first): CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION) CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS) CMake Error at CMake/vtkLoadCMakeExtensions.cmake:11 (MESSAGE): Loading VTK command VTK_WRAP_TCL2 - failed Call Stack (most recent call first): CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION) CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS) Using sxstrace shows INFO: Parsing Manifest File C:\winsame\cary\builds-vs9\composerall\vtk-5.0.0i\ser\CMake\cmVTK_WRAP_TCL2.dll. INFO: Manifest Definition Identity is (null). INFO: Reference: Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8 INFO: Resolving reference Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8. INFO: Resolving reference for ProcessorArchitecture amd64. which seems to indicate that even though I built cmake with the VS9-Win64 generator, cmake somehow created the dll as win32? Even though cmake says, -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/amd64/cl.exe showing that it found the 64-bit compiler? Any hints on what to do next? Thx...John Cary ___ 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] How to create a 64-bit Windows build of cmake?
On 8/1/11 7:04 PM, John Drescher wrote: On Mon, Aug 1, 2011 at 8:34 PM, John R. Caryc...@txcorp.com wrote: I believe I have followed what I have found on the web for building a Win64 version of CMake. I have downloaded the win32 version and used it to configure the cmake source. I used the Visual Studio 9 2008 Win64 generator. Last Friday I pulled in the cmake-git configured for 64 bit Visual Studio 2010 and generated. Thanks! I will try. I found http://www.vtk.org/Wiki/CMake/Git. So then I did: git clone git://cmake.org/cmake.git CMake cd CMake git checkout -b release origin/release Where do I find the cmake-git configured for 64 bit Visual Studio 2010? Opened the project it generated and built release. Then I built the package target and installed the package and I had a 64 bit version of cmake. Although with this said I have yet to see a reason to need CMake to be 64 bit except for the install location being Program Files instead of Program Files (x86). The only thing I see is the loading of dll's. Thx. John Cary ___ 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] TGZ installer following links
On 6/21/11 6:28 AM, Brad King wrote:
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
http://www.cmake.org/Bug/view.php?id=12284#c26931
CPack recursively collects all *files* in the installation tree and hands
them as individual paths to the archive tool. Therefore it walks through
the directory symlink and collects the files inside. This has existed in
every version of CPack both before and after the switch to libarchive.
Just in case anyone is interested, here is my workaround:
add_custom_target(bindist
COMMAND ${CMAKE_MAKE_PROGRAM} package
COMMAND tar czf ${FLAVOR_PACKAGE_NAME}.tar.gz -C
${CMAKE_BINARY_DIR}/_CPack_Packages/${CMAKE_SYSTEM_NAME}/TGZ
${FLAVOR_PACKAGE_NAME}
COMMAND rm
${CMAKE_BINARY_DIR}/_CPack_Packages/${CMAKE_SYSTEM_NAME}/TGZ/${FLAVOR_PACKAGE_NAME}.tar.gz
)
John
___
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] TGZ installer following links
On 6/16/11 2:15 PM, Eric Noulard wrote: I never used install(CODE ... but besides that this should work. did you have a look at the symlinks found in the CPack temp install dir: _CPack_Packages/xxx/TGZ/yyy are they local as they should be or are they pointing to some absolute path. They are correct in the directory: octet.cary$ pwd /home/research/cary/projects/composerall/builds/vorpalcomposer/ser/_CPack_Packages/Linux/TGZ octet.cary$ ls -ls vorpal-4.3.0-r17099-composer-r452-Linux-x86_64.orig/Contents/ total 24 0 lrwxrwxrwx 1 cary research 13 2011-06-17 04:31 current - Foo/current 4 drwxrwsr-x 4 cary research 4096 2011-06-17 04:31 Foo octet.cary$ as links, but untarring the tarball shows that they were tarred as directories, octet.cary$ ls -ls vorpal-4.3.0-r17099-composer-r452-Linux-x86_64/Contents/ total 32 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:39 current 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:38 Foo as if tar had been called with '-h'. Does CPack use tar? Is there any way to control the options that the tarring code is called with? ThxJohn Cary ___ 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] TGZ installer following links
I just found another person who had the same problem: http://www.cmake.org/pipermail/cmake/2007-July/015024.html Does not look like there was ever a response to this? John Cary On 6/17/11 8:46 AM, John R. Cary wrote: On 6/16/11 2:15 PM, Eric Noulard wrote: I never used install(CODE ... but besides that this should work. did you have a look at the symlinks found in the CPack temp install dir: _CPack_Packages/xxx/TGZ/yyy are they local as they should be or are they pointing to some absolute path. They are correct in the directory: octet.cary$ pwd /home/research/cary/projects/composerall/builds/vorpalcomposer/ser/_CPack_Packages/Linux/TGZ octet.cary$ ls -ls vorpal-4.3.0-r17099-composer-r452-Linux-x86_64.orig/Contents/ total 24 0 lrwxrwxrwx 1 cary research 13 2011-06-17 04:31 current - Foo/current 4 drwxrwsr-x 4 cary research 4096 2011-06-17 04:31 Foo octet.cary$ as links, but untarring the tarball shows that they were tarred as directories, octet.cary$ ls -ls vorpal-4.3.0-r17099-composer-r452-Linux-x86_64/Contents/ total 32 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:39 current 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:38 Foo as if tar had been called with '-h'. Does CPack use tar? Is there any way to control the options that the tarring code is called with? ThxJohn Cary ___ 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] TGZ installer following links
Attached is a minimal standalone example that illustrates the problem. If build dir is next to the directory resulting from untarring this, do cmake -DCMAKE_INSTALL_PREFIX=$HOME/tmp/cmtprefix ../cmt make all install # You will see that in the installation, the top cmtdir is a link: numbersix.cary$ ls -l $HOME/tmp/cmtprefix/cmtdir lrwxrwxr-x 1 cary research 10 Jun 17 11:16 /Users/cary/tmp/cmtprefix/cmtdir - bin/cmtdir # then do make package tar xzf cmt-1.1.1-Darwin.tar.gz # and you will see that the top-level cmtdir is a directory: numbersix.cary$ ls -l cmt-1.1.1-Darwin total 0 drwxrwxr-x 3 cary research 102 Jun 17 11:25 bin drwxrwxr-x 3 cary research 102 Jun 17 11:25 cmtdir such that two copies of the binary are installed. Thanks for your help! John Cary On 6/17/11 9:43 AM, Eric Noulard wrote: 2011/6/17 John R. Caryc...@txcorp.com: I just found another person who had the same problem: http://www.cmake.org/pipermail/cmake/2007-July/015024.html Does not look like there was ever a response to this? Yes you seem right now back in 2007 CPack TGZ wasn't using the same method to package TGZ.. but keep reading On 6/17/11 8:46 AM, John R. Cary wrote: On 6/16/11 2:15 PM, Eric Noulard wrote: I never used install(CODE ... but besides that this should work. did you have a look at the symlinks found in the CPack temp install dir: _CPack_Packages/xxx/TGZ/yyy are they local as they should be or are they pointing to some absolute path. They are correct in the directory: octet.cary$ pwd /home/research/cary/projects/composerall/builds/vorpalcomposer/ser/_CPack_Packages/Linux/TGZ octet.cary$ ls -ls vorpal-4.3.0-r17099-composer-r452-Linux-x86_64.orig/Contents/ total 24 0 lrwxrwxrwx 1 cary research 13 2011-06-17 04:31 current - Foo/current 4 drwxrwsr-x 4 cary research 4096 2011-06-17 04:31 Foo octet.cary$ as links, but untarring the tarball shows that they were tarred as directories, octet.cary$ ls -ls vorpal-4.3.0-r17099-composer-r452-Linux-x86_64/Contents/ total 32 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:39 current 4 drwxrwxr-x 5 cary research 4096 2011-06-17 07:38 Foo as if tar had been called with '-h'. Does CPack use tar? Is there any way to control the options that the tarring code is called with? No it does not use tar. CPack is using libarchive (http://code.google.com/p/libarchive/) [in fact there is a copy of libarchive inside cmake source). For TAR based archive (TGZ, TBZ2) the restricted pax is used: http://code.google.com/p/libarchive/wiki/ManPageLibarchiveFormats5 Moreover as noted before I do generate TGZ which includes symlinks without trouble so there must be something different in your case. Could you provide us a standalone minimal test case which exhibit the problem? cmt.tgz Description: GNU Zip compressed data ___ 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] TGZ installer following links
I am using the TGZ packager. My dist looks something like topdir nextdir link - nextdir/lowerdir lowerdir It seems that CPACK, instead of copying the link, follows the link so that I get two copies of lowerdir. Is this expected? Can I change this behavior? ThxJohn Cary ___ 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] TGZ installer following links
On 6/16/11 12:09 PM, Eric Noulard wrote:
2011/6/16 John R. Caryc...@txcorp.com:
I am using the TGZ packager.
Sorry, my error in not providing more complete info:
Which version of CMake/CPack ?
On which platform(s) ?
octet.cary$ cmake --version
cmake version 2.8.3
octet.cary$ uname -a
Linux octet.carys.home 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11
07:06:34 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
octet.cary$
Do you use CPack alone or CMake+CPack?
I have CPACK inside my CMakeLists.txt.
My dist looks something like
topdir
nextdir link - nextdir/lowerdir
lowerdir
It seems that CPACK, instead of copying the link, follows the link
so that I get two copies of lowerdir.
Is this expected?
I guess not, symlinks should be packaged just fine on platform where
it is supported.
Can I change this behavior?
Where does the symlinks comes from ?
In which CMake INSTALL commands are they found?
if (NOT Win32)
install(CODE
foreach (subdir foo bin current)
execute_process(COMMAND ln -s Bar/\${subdir} .
WORKING_DIRECTORY \${CMAKE_INSTALL_PREFIX}/${FLAVOR_INSTALL_ROOT}
)
endforeach ()
)
endif ()
I use CMake generated symlinks (for versioned shared libs) all the time
and this works well with CPack TGZs?
I am using links for a directory instead of a library.
May be you can provide us with a minimal example project exhibiting the issue
or at least send us your CPackConfig.cmake file.
If the above does not immediately suggest a solution to someone, I
will create a test case.
Thx for your help.John Cary
___
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] Error out on installation when there is already an installation
This is in reference to iter.cary$ cmake --version cmake version 2.8.3 iter.cary$ uname -a Linux iter.txcorp.com 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux We have a situation where a package needs to be rebuilt because some dependency is rebuilt. In this case, trilinos needs rebuilding because it depends on openmpi and the version of opempi gets updated. Typically, these installations are in a common area, but by different people. So one night Joe triggers a build a trilinos. Then the next night a new version of openmpi is available, so Mary triggers a build of openmpi and then trilinos. In this situation, Mary's installation of trilinos fails, because cmake's installation does not overwrite some files: -- Installing: /usr/local/contrib/trilinos-10.2.0-ser/include/Teuchos_DLLExportMacro.h -- Up-to-date: /usr/local/contrib/trilinos-10.2.0-ser/include/Teuchos_AbstractFactory.hpp CMake Error at packages/teuchos/src/cmake_install.cmake:54 (FILE): file INSTALL cannot set permissions on /usr/local/contrib/trilinos-10.2.0-ser/include/Teuchos_AbstractFactory.hpp Call Stack (most recent call first): packages/teuchos/cmake_install.cmake:48 (INCLUDE) cmake_install.cmake:41 (INCLUDE) but then apparently tries to set the permissions anyway. But since it did not overwrite, Mary does not own the files, and so she cannot set the perms. The result being that the installation errors out as above, possibly not completing, but at the very least returning an error code that must be chased down. It seems to me that one should overinstall, even if the file is there, if one is going to try to set permissions afterwards. Is there a way to force such overinstallation in cmake? Or perhaps not error out on a perm change if the exising perms are okay? ThxJohn Cary ___ 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] How do folks work with rpath on OS X using cmake?
Scenario: A library libA.dylib is found somewhere in the building of executable B. Doing the typical link, otool -L shows that B references: libA.dylib or possibly /A/prefix/lib/libA.dylib. I want B to run from either the build directory or the installation directory, which I want to be portable. A possible solution is to have libA.dylib encoded into B as: @rpath/libA.dylib and then to put @loader_path/ and /A/installdir/lib into the rpath of B, and finally to install libA.dylib alongside B. What is the best way to get this done using CMake? What other approaches are there to this basic problem? Thx.John Cary ___ 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] Determining what is inside a compiler wrapper
Due to ABI differences, over the years we have installed libraries under subdirs named after the compiler group (gcc, xlc, ...). For this we need to figure out what compiler might be inside a compiler wrapper (like CC on the cray, whatever in mpicc, etc.) Are there general strategies or modules for doing this? Thx...John Cary ___ 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] Auxiliary fortran link libraries?
Thanks for your response. More below. On 7/19/2010 9:06 AM, Brad King wrote: Can I force the addition of these libraries without referencing them explicitly? One workaround is to list a dummy .F file just to tell CMake that Fortran will be involved at link time. I call it a workaround because we are not really giving CMake enough information to solve this problem for us. What provides the lapack and blas libraries you're using? They come with the system. How are we as users supposed to know that they are Fortran-built libraries and not something provided by a project like CLAPACK. How do we know what Fortran compiler was used to build them (to know what mangling it uses)? If information like this is not available through some automatically detectable means then any solution will involve manual interference. So the lapack libraries are actually needed as a dependency of Trilinos, another C++ library, which does the calling of the symbols, and it must get those right, because if I add them to the link line, then all links and runs. Now I happen to know what those libraries were compiled with, and I passed the correct fortran, so I also know that what is here: numbersix.cary$ grep IMPLICIT CMakeFiles/CMakeFortranCompiler.cmake SET(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES gfortran) SET(CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES /usr/local/lib/gcc/x86_64-apple-darwin10/4.5.0;/usr/local/lib) So can I just INCLUDE CMakeFiles/CMakeFortranCompiler.cmake and then add these libraries to my target in cases where I know they are correct? Or perhaps the include is done automatically? Thanks.John Cary ___ 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] How does one find blas and lapack on OSX?
On 7/5/2010 9:37 AM, James C. Sutherland wrote: On Mon, Jul 5, 2010 at 9:34 AM, John Cary c...@txcorp.com mailto:c...@txcorp.com wrote: I have simply: FIND_PACKAGE(BLAS) FIND_PACKAGE(LAPACK) but cmake gives -- Looking for BLAS... - NOT found (Fortran not enabled) -- Looking for LAPACK... - NOT found (Fortran not enabled) Is this more complicated somehow? Be sure to include enable_language( Fortran ) in your project. James Thanks much. That worked. On another OS, I need to use clapack. Is there a way to find that instead? Thx...John Cary ___ 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] How does one find blas and lapack on OSX?
On 7/5/2010 10:54 AM, James C. Sutherland wrote: On Mon, Jul 5, 2010 at 10:44 AM, John R. Cary c...@txcorp.com mailto:c...@txcorp.com wrote: On 7/5/2010 9:37 AM, James C. Sutherland wrote: On Mon, Jul 5, 2010 at 9:34 AM, John Cary c...@txcorp.com mailto:c...@txcorp.com wrote: I have simply: FIND_PACKAGE(BLAS) FIND_PACKAGE(LAPACK) but cmake gives -- Looking for BLAS... - NOT found (Fortran not enabled) -- Looking for LAPACK... - NOT found (Fortran not enabled) Is this more complicated somehow? Be sure to include enable_language( Fortran ) in your project. James Thanks much. That worked. On another OS, I need to use clapack. Is there a way to find that instead? Thx...John Cary Look back in the mail list archives. There was a discussion on this a while back. If you search for CLAPACK in the archives it should come up. Thanks very much. In thinking about this, I realize that what I really need is to build with whatever lapack, blas was found by Trilinos, when I built it. Is there a standard way of doing this? I see that Trilinos puts some information in the installation directory iter.cary$ grep -i lapack TrilinosConfig.cmake SET(Trilinos_TPL_LIBRARIES /usr/lib64/liblapack.so;/usr/lib64/libblas.so) SET(Trilinos_TPL_LIST LAPACK;BLAS) Thanks...John Cary ___ 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] cmake on the BGP
Mathieu Malaterre wrote: On Tue, Sep 1, 2009 at 2:49 PM, Mathieu Malaterremathieu.malate...@gmail.com wrote: On Tue, Sep 1, 2009 at 2:41 PM, Brad Kingbrad.k...@kitware.com wrote: Mathieu Malaterre wrote: [ 4%] Built target cmsys Linking C shared module libcmsysTestDynload.so /usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../lib/crt1.o:(.rodata+0x4): undefined reference to `main' What does make VERBOSE=1 say? Clearly this linker line is missing the flag to make it a shared library instead of an executable. Copying from Darwin-xlC I get now: cat Linux-XL-CXX.cmake SET(CMAKE_SHARED_LIBRARY_C_FLAGS ) SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS ) SET(CMAKE_SHARED_LIBRARY_CXX_FLAGS ) SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS ) SET(CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS -qmkshrobj) I can verify that this made all work on intrepid.alcf.anl.gov. BTW - should a 'CXX.cmake' file include *_C_FLAGS? Curious about how these work. I assume that cmake does a mapping from the OS and compiler to a Platform file, but then there are also Compiler files. Could one put the above into Modules/Compiler/XL-CXX.cmake and have it work for all platforms? Thanks..John Cary -- Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303 c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572 ___ 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] cmake on the BGP
Brad King wrote: John R. Cary wrote: I am trying to build cmake on a Blue Gene P. Configuration starts with login1.surveyor$ ./bootstrap - CMake 2.6-4, Copyright (c) 2007 Kitware, Inc., Insight Consortium [snip] http://www.cmake.org/pipermail/cmake/2006-January/007917.html It should be very easy to add support to CMake. You would have to create a Linux-xlc.cmake file that will go in the Platforms directory of cmake. It would set all the correct flags for the compiler. If you want, I can help you create one, and I will add it to cmake. Was this ever done? Can I help with getting it done? I think it was done, at least partly. Please try CMake from CVS HEAD: cvs -d :pserver:anon...@www.cmake.org:/cvsroot/CMake co CMake If that doesn't work out of the box I'll be happy to help you contribute support. Great! I now have the cvs checkout. Error below indicates that it finds cc instead of xlc, which I can fix on the configure line via env CC=xlc_r CXX=xlC_r but then it still fails at the same place. Thx.John Cary cc -I/home/cary/projects/facetspkgs-surveyor/CMake/Source -I/home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk -DKWSYS_NAMESPACE=cmsys -c /home/cary/projects/facetspkgs-surveyor/CMake/Source/kwsys/System.c -o System.o xlC -I/home/cary/projects/facetspkgs-surveyor/CMake/Source -I/home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk cmake.o cmakemain.o cmakewizard.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmDocumentationFormatterText.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmInstallDirectoryGenerator.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGlobalGenerator.o cmLocalGenerator.o cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmBootstrapCommands.o cmCommands.o cmTarget.o cmTest.o cmCustomCommand.o cmDocumentVariables.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelper.o cmListFileLexer.o Directory.o Glob.o RegularExpression.o SystemTools.o ProcessUNIX.o String.o System.o -o cmake loading initial cache file /home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk/InitialCacheFlags.cmake -- The C compiler identification is GNU -- The CXX compiler identification is XL -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -- Check for working CXX compiler: /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -- broken CMake Error at Modules/CMakeTestCXXCompiler.cmake:30 (MESSAGE): The C++ compiler /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC is not able to compile a simple test program. It fails with the following output: Change Dir: /home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/gmake cmTryCompileExec/fast gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/gpfs/home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp' /home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk/cmake -E cmake_progress_report /home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp/CMakeFiles 1 Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -o CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c /home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp/testCXXCompiler.cxx Linking CXX executable cmTryCompileExec /home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -fPIC CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -o cmTryCompileExec -rdynamic /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0
Re: [CMake] cmake on the BGP
Brad King wrote: Be sure to create a fresh build tree when changing compilers. CMake cached the 'cc' (gnu) compiler it found the first time and did not pay attention to the environment later. Got it. Now 'rm -rf' on the build tree. /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC: 1501-216 (W) command option -dynamic is not recognized - passed to ld /usr/bin/ld: unrecognized option '-dynamic' It looks like support for the C compiler was added but not C++, and also that this combination is not well tested. I can help you finish adding support. Look in Modules/Platform at the files Linux.cmake Linux-XL-C.cmake The first contains default flags for Linux, which are for GCC. The second contains compiler-specific flags for the XL C compiler on Linux. Copy it to the file Linux-XL-CXX.cmake and change the ..._C_FLAGS variable names to ..._CXX_FLAGS. Also, please read through Linux.cmake and check for the options in the XL compiler documentation to see if other flags need to be changed. So do I understand correctly that one uses Linux-XL-CXX.cmake to override settings in Linux.cmake? Here is what I have now: login3.surveyor$ ls ../Modules/Platform/Linux-XL-C*.cmake ../Modules/Platform/Linux-XL-C.cmake ../Modules/Platform/Linux-XL-CXX.cmake login3.surveyor$ cat ../Modules/Platform/Linux-XL-C*.cmake SET(CMAKE_SHARED_LIBRARY_C_FLAGS ) SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS ) SET(CMAKE_SHARED_LIBRARY_C_FLAGS -DPIC) SET(CMAKE_SHARED_LIBRARY_CXX_FLAGS ) SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS ) SET(CMAKE_SHARED_LIBRARY_CXX_FLAGS -DPIC) The bootstrap make dies now at [ 5%] Building C object Source/kwsys/CMakeFiles/cmsysTestDynload.dir/testDynload.o Linking C shared module libcmsysTestDynload.so /usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../lib/crt1.o:(.rodata+0x4): undefined reference to `main' make[2]: *** [Source/kwsys/libcmsysTestDynload.so] Error 1 make[1]: *** [Source/kwsys/CMakeFiles/cmsysTestDynload.dir/all] Error 2 make: *** [all] Error 2 Can I turn off shared lib usage altogether? (Problematic on BGP). I did not see Suppose I get a CMake that has the above in its share dir, and I want to use my own Linux-XL-CXX.cmake. Can I simply put my file in my project's top CMake dir? Do I have to include it somehow? BTW, a platform/compiler combination is officially supported only if someone is contributing nightly testing to the dashboard: http://www.cdash.org/CDash/index.php?project=CMake After we get this working, do you have about an hour of spare computing time on a machine at night? If you can submit testing results then we can support this platform permanently. I think I will not be able to get permission to run nightly tests at this supercomputer center. My guess, however, is that VisualAge and XL are basically the same, and I could get VisualAge on my Linux box. John Cary -- Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303 c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572 ___ 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] pg compilers on the Cary XT4
which is basically Linux. Building a project with pgcc/pgCC. All flags are empty: CMAKE_CXX_COMPILER /opt/pgi/8.0.4/linux86-64/8.0-4/bin/pgCC CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELWITHDEBINFO Where should I add these? Another question: The default builds seem to be DEBUG, MINSIZEREL, RELEASE, RELWITHDEBINFO. Suppose I wanted to define a new kind of build, e.g., PERFORMANCE. How can I go about doing this? ThanksJohn Cary -- Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303 c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572 ___ 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] [New Module] FindHDF5.cmake
I am a real newbie here (exploring cmake) so my words should be taken
with a grain of salt. But we find (in our current autotools
setup), that it is good to have a flag that tells one whether the hdf5 was
compiled with --enable-parallel.
John Cary
Will Dicharry wrote:
Brad King wrote:
Will Dicharry wrote:
Sorry for the month of delay, but I've addressed Mike Jackson's
concerns
below and I think I'm close to having the HDF5 find module ready for
submission.
Excellent. I have a few comments from quickly glancing at them, but
I don't have time for thorough testing. Overall it looks good.
There are two modules attached to this message: The FindHDF5.cmake
module and an AdjustLibraryVariables.cmake module, which is essentially
a copy of what the FindQt4 module does. It seems useful enough to
incorporate into the CMake Modules, and I can maintain it if you need a
maintainer.
I'd like to choose a better name for AdjustLibraryVariables. Perhaps
SelectLibraryConfigurations? Does it have all the functionality
needed
to update FindQt4 to use it too (you don't need to do this but it should
be easy for the FindQt4 maintainer to do it)?
I agree, SelectLibraryConfigurations is better. I'll rename it. It
looks like I need to set ${basename}_LIBRARIES (plural) too in order
for the Qt4 module to use it, I'll go ahead and do that.
The find_path and find_library calls need some tweaking. Please read
the documentation of these commands to distinguish the cases of PATHS
and HINTS keywords. The PATHS should only be last-resort guesses.
The HINTS should be locations computed from the system, such as those
reported by the hdf5 compiler wrapper tools. Also, paths like
/usr/local/include
/usr/include
are searched automatically and need not be listed.
I'll clean that up, I think the only path I'm specifying that should
be in the PATH section is the $HOME/.local/ guess. It seems
everything else should be a HINT. Thanks for the tip.
How I addressed Mike Jackson's concerns is addressed in the module
documentation at the top of the file, please let me know if anyone has
any other concerns.
Try placing these modules in the CMake/Modules source tree and running
cmake --help-module FindHDF5
cmake --help-module AdjustLibraryVariables
to make sure the documentation formats correctly. Also, any macro in
the public interface of the module should be documented using a format
similar to the CMake command documentation.
What is the convention for keeping a macro out of the public interface?
Thanks for your help,
Will
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://www.cmake.org/mailman/listinfo/cmake
___
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] [New Module] FindHDF5.cmake
Will Dicharry wrote: Brad King wrote: John R. Cary wrote: Brad King wrote: John, how do autotools detect this? hdf5par=`grep HAVE_PARALLEL 1 $HDF5_INCDIR/H5config.h` I suppose there are other ways, but we have been doing this through several versions of hdf5. Great, thanks John. Will, you should be able to use the file(STRINGS) command to grep through H5config.h after finding it. John, What version of HDF5 are you using? It looks like H5config.h doesn't exists in 1.8.3. I found the H5_HAVE_PARALLEL definition in H5pubconf.h for HDF5 1.8.3. Hi Will, That looks better: Hi Will, That looks better: xena.cary$ cd hdf5-1.6.5/include xena.cary$ grep -i parallel H5pubconf.h /* Define if we have parallel support */ /* #undef H5_HAVE_PARALLEL */ xena.cary$ cd ../hdf5-1.8.2-ser/include -bash: cd: ../hdf5-1.8.2-ser/include: No such file or directory xena.cary$ cd ../../hdf5-1.8.2-ser/include xena.cary$ grep -i parallel H5pubconf.h /* Define if we have parallel support */ /* #undef H5_HAVE_PARALLEL */ xena.cary$ cd ../../hdf5-1.8.2-par/include xena.cary$ grep -i parallel H5pubconf.h /* Define if we have parallel support */ #define H5_HAVE_PARALLEL 1 available back through 1.6.5. I was probably doing something for much older versions, as I now see the full fragment: if test $ac_cv_have_hdf5 = yes; then if test -f $HDF5_INCDIR/H5config.h; then hdf5par=`grep HAVE_PARALLEL 1 $HDF5_INCDIR/H5config.h` elif test -f $HDF5_INCDIR/H5pubconf.h; then hdf5par=`grep HAVE_PARALLEL 1 $HDF5_INCDIR/H5pubconf.h` fi fi which agrees with yours. Best.John -- Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303 c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572 ___ 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] cmake on the BGP
I am trying to build cmake on a Blue Gene P. Configuration starts with login1.surveyor$ ./bootstrap - CMake 2.6-4, Copyright (c) 2007 Kitware, Inc., Insight Consortium C compiler on this system is: cc C++ compiler on this system is: xlC Makefile processor on this system is: gmake xlC is not GNU compiler xlC has STL in std:: namespace xlC has ANSI streams xlC has streams in std:: namespace xlC has sstream xlC has operator!=(string, char*) It ended with xlC -I/home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/Source -I/home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/Bootstrap.cmk cmake.o cmakemain.o cmakewizard.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmDocumentationFormatterText.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmInstallDirectoryGenerator.o cmGeneratedFileStream.o cmGlobalGenerator.o cmLocalGenerator.o cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmSourceFile.o cmSourceFileLocation.o cmSystemTools.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmBootstrapCommands.o cmCommands.o cmTarget.o cmTest.o cmCustomCommand.o cmDocumentVariables.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelper.o cmListFileLexer.o Directory.o Glob.o RegularExpression.o SystemTools.o ProcessUNIX.o String.o System.o -o cmake loading initial cache file /home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/Bootstrap.cmk/InitialCacheFlags.cmake -- The C compiler identification is GNU -- The CXX compiler identification is VisualAge -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -- Check for working CXX compiler: /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -- broken CMake Error at Modules/CMakeTestCXXCompiler.cmake:25 (MESSAGE): The C++ compiler /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC is not able to compile a simple test program. It fails with the following output: Change Dir: /home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/gmake cmTryCompileExec/fast gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/gpfs/home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/CMakeFiles/CMakeTmp' /home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/Bootstrap.cmk/cmake -E cmake_progress_report /home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/CMakeFiles/CMakeTmp/CMakeFiles 1 Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -o CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c /home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/CMakeFiles/CMakeTmp/testCXXCompiler.cxx Linking CXX executable cmTryCompileExec /home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC -fPIC CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -o cmTryCompileExec -rdynamic /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC: 1501-216 (W) command option -fPIC is not recognized - passed to ld /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC: 1501-216 (W) command option -dynamic is not recognized - passed to ld /usr/bin/ld: unrecognized option '-dynamic' /usr/bin/ld: use the --help option for usage information gmake[1]: *** [cmTryCompileExec] Error 1 gmake[1]: Leaving directory `/gpfs/home/cary/projects/facetspkgs-surveyor/builds/cmake-2.6.4/ser/CMakeFiles/CMakeTmp' gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (PROJECT) -- Configuring incomplete, errors occurred!
