Re: [CMake] An observation about CTest
On 28. Jun, 2010, at 7:03 , Andreas Mohr wrote: Hello, On Sun, Jun 27, 2010 at 05:09:41PM -0400, cmake-requ...@cmake.org wrote: Your remarks focus on old-fashioned macros so it is possible you are not aware of functions? As far as I know, most or all macros can be replaced by functions which do have the nice property of not polluting the global namespace. So newly developed build systems should use functions wherever possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. That's all fine and dandy (and you've written some nice prose about it :), but I've just been reading man cmakecommands of Debian cmake 2.8.1-5(!) from top to bottom and bottom to top, and nowhere does it mention _any_ underlying difference between macros and functions. Not even I knew about this difference, despite having almost a month-full of rather very internal CMake experience (Google searches in the couple hundreds, vcproj2cmake adaptation of a _large_ project etc.). Suggestion for the sake of world peace: I'll submit a patch for that man page, ok? :) Andreas Mohr You are right, the docs don't mention that FUNCTION introduces a new scope, which should be fixed. But it should be clear from the traditional use of the names. Macros are textual replacements (just as in C), functions have their own local scope (again, just as in C). ___ 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] CPack custom page
Hi people, I'm trying to build a custom NSIS page that's shown at the end of the installer, after all files have been installed. The purpose is to set up a Windows service. I can do the code for installing the service, but I'm having some problems adding the custom page for it. And searching the net haven't given me any decent hits. Some pages say I should just hack the template file, but that doesn't give any clue what to put in the file. Can one of you point to example code that adds a custom page, please? Bo Thorsen. Monty Program AB. -- MariaDB: MySQL replacement Community developed. Feature enhanced. Backward compatible. ___ 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] [Eclipse CDT4 Generator] issue finding windres.exe
I'm using CMake, MinGW and Eclipse as described here http://www.cmake.org/Wiki/Eclipse_CDT4_Generator. In my project I need to compile a resource file, so I've used the add_custom_command() to achieve this. If I run make in MSYS it succeeds, but running from Eclipse causes a problem, since Eclipse cannot find windres.exe. How can I automatically provide a path to windres.exe during the project generation or are there any other solutions? Regards, Yegor ___ 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] [Eclipse CDT4 Generator] issue finding windres.exe
I'm using CMake, MinGW and Eclipse as described here http://www.cmake.org/Wiki/Eclipse_CDT4_Generator. In my project I need to compile a resource file, so I've used the add_custom_command() to achieve this. If I run make in MSYS it succeeds, but running from Eclipse causes a problem, since Eclipse cannot find windres.exe. How can I automatically provide a path to windres.exe during the project generation or are there any other solutions? Use the find_program command to find the full path to windres, then use the result of that statement rather than just the hardcoded windres as the executable for your custom command. find_program() still requires some valid PATH to search. If I manually add PATH=c:\mingw\bin to Eclipse environment variables, the windres.exe could be found without any problems. The best way where to let CMake specify RC compiler path during generator creation using cmake-gui. What about applying this patch: http://public.kitware.com/Bug/view.php?id=4068 Regards, Yegor ___ 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] rpath problems with kdevplatform
Andreas Pakulat wrote: On 26.06.10 13:26:29, Andreas Pakulat wrote: Ping? Any further ideas on this? Could someone at least point me to the source code in cmake that decides wether to add RPATH_REMOVE or RPATH_REPLACE to the cmake_install.cmake file? Look at cmInstallTargetGenerator::AddChrpathPatchRule. Its job is to generate the install-time script to fix up the RPATH in the installed binary. The default is *no* RPATH, unless the INSTALL_RPATH target property is set: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:INSTALL_RPATH Elsewhere in this thread (at least on the kde list) you mention this seems to be working for some targets and not others. Look for where the INSTALL_RPATH gets set on the targets where it is working. Found it already, I've patched a cmake checkout here to give some diagnostic output and looking at the differences its apparent that for kdevplatform the installation prefix is not added to the OrderRuntimeSearchPath list in cmComputeLinkInformation, but this is done for kdevelop targets. This has nothing to do with RPATH_REMOVE or RPATH_CHANGE calls during installation. The only time this code would be used with install-tree information is during the relink step used on non-ELF platforms used to build a new RPATH into the binaries for installation. The reason seems to be that when building kdevplatform there are no libraries in the install-prefix that the to-be-built targets link against. So it seems that this is rather a cmake bug, hence I'm cc'ing to the cmake list (and including all the quotes). @CMake-List readers: Am I right that cmake simply should add the install-prefix to the ORderRuntimeSearchPath at some point during initialization? No, this is intentional behavior. CMake sets the RPATH up in the build tree to help the binary find its dependencies at runtime. If it does not link to anything in prefix/lib then there will be no RPATH entry for it. That should help in this case (I didn't test this yet) As I said above it won't affect the install tree. See the INSTALL_RPATH target property. -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] Different configurations with Visual Studio
Hi, I am using CMake to generate Visual Studio project files, later also for CodeBlocks. It seems that CMake generates four different configurations for Visual Studio: Debug, Release, MinSizeRel and RelWithDebInfo. However, I need other configuations, Debug and Release, both for Win32 and MX3, in one project file. How do I change this? I tried this by changing *CMAKE_CONFIGURATION_TYPES *and CMAKE_BUILD_TYPES, e.g. SET(CMAKE_BUILD_TYPES Debug Release DebugMX31 ReleaseMX31) but I have the impression that these variables cannot be changed. -- Mark ___ 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] Different configurations with Visual Studio
On 28. Jun, 2010, at 15:17 , Mark Van Peteghem wrote:
Hi,
I am using CMake to generate Visual Studio project files, later also for
CodeBlocks.
It seems that CMake generates four different configurations for Visual
Studio: Debug, Release, MinSizeRel and RelWithDebInfo. However, I need other
configuations, Debug and Release, both for Win32 and MX3, in one project
file. How do I change this?
I tried this by changing *CMAKE_CONFIGURATION_TYPES *and CMAKE_BUILD_TYPES,
e.g.
SET(CMAKE_BUILD_TYPES Debug Release DebugMX31 ReleaseMX31)
but I have the impression that these variables cannot be changed.
--
Mark
You have to change CMAKE_CONFIGURATION_TYPES in the cache. Here is some
template I use:
# Xcode generator is buggy (linker flags are not inherited from compile flags
# and custom configurations don't work with shared libraries)
if(NOT CMAKE_GENERATOR STREQUAL Xcode)
set(CMAKE_C_FLAGS_SUPERDUPER --super --duper CACHE
STRING Flags used by the compiler during super-duper builds)
set(CMAKE_EXE_LINKER_FLAGS_SUPERDUPER --super --duper CACHE
STRING Flags used by the linker for executables during super-duper builds)
set(CMAKE_SHARED_LINKER_FLAGS_SUPERDUPER --super --duper CACHE
STRING Flags used by the linker for shared libraries during super-duper
builds)
set(CMAKE_MODULE_LINKER_FLAGS_SUPERDUPER --super --duper CACHE
STRING Flags used by the linker for loadable modules during super-duper
builds)
mark_as_advanced(CMAKE_C_FLAGS_COVERAGE CMAKE_EXE_LINKER_FLAGS_SUPERDUPER
CMAKE_SHARED_LINKER_FLAGS_SUPERDUPER CMAKE_MODULE_LINKER_FLAGS_SUPERDUPER)
# This variable is only set for multi-config IDE generators
if(CMAKE_CONFIGURATION_TYPES)
list(APPEND CMAKE_CONFIGURATION_TYPES SuperDuper)
list(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
set(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} CACHE STRING
Semicolon separated list of supported configuration types
[Debug|Release|MinSizeRel|RelWithDebInfo|SuperDuper]
FORCE)
endif()
endif()
HTH
Michael
___
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] An observation about CTest
On 06/28/2010 08:55 AM, Michael Wild wrote: On 28. Jun, 2010, at 7:03 , Andreas Mohr wrote: Hello, On Sun, Jun 27, 2010 at 05:09:41PM -0400, cmake-requ...@cmake.org wrote: Your remarks focus on old-fashioned macros so it is possible you are not aware of functions? As far as I know, most or all macros can be replaced by functions which do have the nice property of not polluting the global namespace. So newly developed build systems should use functions wherever possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. That's all fine and dandy (and you've written some nice prose about it :), but I've just been reading man cmakecommands of Debian cmake 2.8.1-5(!) from top to bottom and bottom to top, and nowhere does it mention _any_ underlying difference between macros and functions. As for me, I wouldn't say so. The documentation of MACRO() states: Note that the parameters to a macro and values such as ARGN are not variables in the usual CMake sense. They are string replacements much like the c preprocessor would do with a macro. If you want true CMake variables you should look at the function command. So, one could conclude that there's indeed a difference between macros and functions particularly in regard to variables, i.e. one of this thread's concerns. Not even I knew about this difference, despite having almost a month-full of rather very internal CMake experience (Google searches in the couple hundreds, vcproj2cmake adaptation of a _large_ project etc.). Suggestion for the sake of world peace: I'll submit a patch for that man page, ok? :) Andreas Mohr You are right, the docs don't mention that FUNCTION introduces a new scope, [...] They do, but not for FUNCTION() where such facts would be expected; it's rather hidden in the section of SET() w.r.t. PARENT_SCOPE: If PARENT_SCOPE is present, the variable will be set in the scope above the current scope. Each new directory *or function* creates a new scope. This command will set the value of a variable into the parent directory or calling function (whichever is applicable to the case at hand). [...] which should be fixed. [...] Yes, mentioning the scoping capabilities of FUNCTION() right in the latter's documentation, perhaps in connection with a reference to SET()'s PARENT_SCOPE option, would be adequate and helpful, IMO. Besides, ADD_SUBDIRECTORY()'s documentation doesn't note the introduction of a new scope, too. [...] But it should be clear from the traditional use of the names. Macros are textual replacements (just as in C), functions have their own local scope (again, just as in C). Regards, Michael ___ 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] rpath problems with kdevplatform
On 28.06.10 08:44:35, Brad King wrote: Andreas Pakulat wrote: On 26.06.10 13:26:29, Andreas Pakulat wrote: Ping? Any further ideas on this? Could someone at least point me to the source code in cmake that decides wether to add RPATH_REMOVE or RPATH_REPLACE to the cmake_install.cmake file? Look at cmInstallTargetGenerator::AddChrpathPatchRule. Its job is to generate the install-time script to fix up the RPATH in the installed binary. The default is *no* RPATH, unless the INSTALL_RPATH target property is set: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:INSTALL_RPATH Elsewhere in this thread (at least on the kde list) you mention this seems to be working for some targets and not others. Look for where the INSTALL_RPATH gets set on the targets where it is working. Let me clarify, I have two projects: kdevplatform and kdevelop. Both have multiple targets, in particular: kdevplatform - libfoo - libbar - fooplugin - barplugin kdevelop - anotherplugin - someexe Now libbar links against libfoo, fooplugin and barplugin both link again libfoo and libbar. someexe and anotherplugin too. When I now build kdevplatform I get Removed runtime path for each installed library/plugin. Whereas doing the same in kdevelop shows Set runtime path of, i.e. the rpath of all binaries are adjusted to use the install dir. Both projects are being installed to the same prefix, namely $HOME/kdevelop using -DCMAKE_INSTALL_PREFIX. Found it already, I've patched a cmake checkout here to give some diagnostic output and looking at the differences its apparent that for kdevplatform the installation prefix is not added to the OrderRuntimeSearchPath list in cmComputeLinkInformation, but this is done for kdevelop targets. This has nothing to do with RPATH_REMOVE or RPATH_CHANGE calls during installation. The only time this code would be used with install-tree information is during the relink step used on non-ELF platforms used to build a new RPATH into the binaries for installation. Well, as I said above I see those Removing/Changing messages which apparently (according to my grep) are coming from cmake_install.cmake. And thats how I found the places in the source code of CMake that computes the runtime path. The reason seems to be that when building kdevplatform there are no libraries in the install-prefix that the to-be-built targets link against. So it seems that this is rather a cmake bug, hence I'm cc'ing to the cmake list (and including all the quotes). @CMake-List readers: Am I right that cmake simply should add the install-prefix to the ORderRuntimeSearchPath at some point during initialization? No, this is intentional behavior. CMake sets the RPATH up in the build tree to help the binary find its dependencies at runtime. If it does not link to anything in prefix/lib then there will be no RPATH entry for it. But it does, except that the relevant libs/plugins are built as part of the project. That should help in this case (I didn't test this yet) As I said above it won't affect the install tree. See the INSTALL_RPATH target property. That property is not set (and the global variable CMAKE_INSTALL_RPATH) is empty too, nonetheless one project gets rpath info set in the installed plugins/executable the other one doesn't. Andreas -- You will be misunderstood by everyone. ___ 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] Better BlueGene/P and cross-compile support for CMake
Todd Gamblin wrote: So it's *probably* safe to set your CMAKE_FIND_ROOT_PATH to /bgsys/drivers/ppcfloor, but technically it's outside your definition above. [snip] Thinking about this some more, maybe you just don't *need* a find root on BG/P ... You can get all the system information you need from the MPI compiler We still need to hide the rest of the host system libraries from the find_* commands. CMAKE_FIND_ROOT_PATH in ONLY mode is the way to do that. The problem right now is really that the find_ commands ignore both PATHS and HINTS in a cross compile environment Huh? They are not ignored. However, all the values given are re-rooted under CMAKE_FIND_ROOT_PATH. This may have led you to believe they are ignored if you used full paths from the real root. Both PATHS and HINTS were developed for host-only builds and did not consider cross compiling. CMAKE_FIND_ROOT_PATH was developed specifically for cross compiling and simply re-roots *all* search paths computed by the normal mechanisms. Look at CMake's source file Source/cmFindCommon.cxx for the method cmFindCommon::RerootPaths. It is responsible for re-rooting all the search paths under CMAKE_FIND_ROOT_PATH. There is a #if 0 block at the top of the method that was left from debugging its original implementation. Build CMake with this changed to #if 1 to get detailed information about the list of paths considered *before* re-rooting. Note also that the method does *not* modify paths that already lie under the new root. Perhaps this information can aid your analysis of what happens. -Brad P.S. (FYI) PATHS are supposed to come from user-supplied locations HINTS are supposed to come from system locations. In that documentation, user is the author of the Find* module. PATHS are hard-coded last-ditch guesses of common install locations. They are searched after all other paths. HINTS are educated guesses based on information found from some other source on the actual system, like mpicc -show results. They are searched before normal system directories. ___ 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] No +DD64 compiler option for HP-UX on IA64
Sounds like the install of gcc is broken on this machine. Basically you are saying that gcc foo.c will fail on this machine. CMake assumes a working compiler. On Sun, Jun 27, 2010 at 9:37 PM, Won Kim wonda...@gmail.com wrote: Hello, I've been trying to set up CMake on different build machines. Everything went perfectly on Linux machines (32/64bit), however, CMake gave me the following error message during configuration on HP IA64. -- The C compiler identification is GNU -- Check for working C compiler: /usr/local/bin/gcc -- Check for working C compiler: /usr/local/bin/gcc -- broken CMake Error at .../cmake-2.8.1-HP-UX-9000_785/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler /usr/local/bin/gcc is not able to compile a simple test program. It fails with the following output: Change Dir: /data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp Run Build Command:/usr/local/bin/gmake cmTryCompileExec/fast /usr/local/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp' /data5/obmtp4/cmake-2.8.1-HP-UX-9000_785/bin/cmake -E cmake_progress_report /data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o /usr/local/bin/gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c /data5/obmtp4/tmp/ofsrc5_build/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec /data5/obmtp4/cmake-2.8.1-HP-UX-9000_785/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /usr/local/bin/gcc CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o cmTryCompileExec -Wl,+s,-E,+nodefaultrpath -Wl,+b/usr/lib ld: Can't find library or mismatched ABI for -lc Fatal error. So, I added the following two lines in HP-UX.cmake file to solve the problem: SET(CMAKE_C_COMPILER /usr/bin/cc) == Replace C compiler SET(CMAKE_C_FLAGS +DD64) == Added +DD64 compiler option for IA64. After inserting these lines, CMake could compile the sample C source file. To compare with other HP machine I tried the same in HP RISC machine, and it compiled fine without those lines. Is there anything that I need to set up before compiling on HP IA64 machine? Also, I wonder why CMake would not add +DD64 compile option automatically. If possible, I would prefer the way that CMake add necessary compile options by itself. Thank you very much, Won ___ 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] An observation about CTest
On 2010-06-28 07:03+0200 Andreas Mohr wrote: Hello, On Sun, Jun 27, 2010 at 05:09:41PM -0400, cmake-requ...@cmake.org wrote: Your remarks focus on old-fashioned macros so it is possible you are not aware of functions? As far as I know, most or all macros can be replaced by functions which do have the nice property of not polluting the global namespace. So newly developed build systems should use functions wherever possible, and certainly for old CMake-based build systems I am associated with I am trying to move to functions as time permits. That's all fine and dandy (and you've written some nice prose about it :), but I've just been reading man cmakecommands of Debian cmake 2.8.1-5(!) from top to bottom and bottom to top, and nowhere does it mention _any_ underlying difference between macros and functions. Look for scope within the documentation. In particular in the set command documentation you will find If PARENT_SCOPE is present, the variable will be set in the scope above the current scope. Each new directory or function creates a new scope. Note macros are not mentioned there so there is a clear difference between macros and functions that you were searching for. From experience that last sentence means that without PARENT_SCOPE (and without CACHE) variables set in directories are only available to that directory and sub-directories. I therefore have assumed (and IIRC this was mentioned when functions was first discussed on the list here) that without PARENT_SCOPE (and without CACHE), variables set in functions are only available to that function (and functions it calls?) The above documentation assumes everybody knows what is meant by scope, but an explicit paragraph about that somewhere in the documentation would be worthwhile. Also, I think there should be a sentence in the documentation of macros that deprecates them in favor of functions (because of the known scope issue with macros). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] Better BlueGene/P and cross-compile support for CMake
On Jun 28, 2010, at 8:03 AM, Brad King wrote: Todd Gamblin wrote: So it's *probably* safe to set your CMAKE_FIND_ROOT_PATH to /bgsys/drivers/ppcfloor, but technically it's outside your definition above. [snip] Thinking about this some more, maybe you just don't *need* a find root on BG/P ... You can get all the system information you need from the MPI compiler We still need to hide the rest of the host system libraries from the find_* commands. CMAKE_FIND_ROOT_PATH in ONLY mode is the way to do that. Agreed -- for now. See below. The problem right now is really that the find_ commands ignore both PATHS and HINTS in a cross compile environment Huh? They are not ignored. However, all the values given are re-rooted under CMAKE_FIND_ROOT_PATH. This may have led you to believe they are ignored if you used full paths from the real root. Both PATHS and HINTS were developed for host-only builds and did not consider cross compiling. CMAKE_FIND_ROOT_PATH was developed specifically for cross compiling and simply re-roots *all* search paths computed by the normal mechanisms. Ok, I think I see what the real problem here is for BG/P systems. CMake cross-compile support is assuming that there is only one (or maybe a few) directories where target software might be installed. On our BlueGene systems, there is one target environment directory, and, as I mentioned, even that is somewhat convoluted because it really contains binaries for *three* platforms (FEN, CN, and ION). Nearly all the BlueGene systems I've worked on also have shared filesystems that are accessible both from the FEN and the CN, and these filesystems are going to have CN (target) software installs that *shouldn't* be re-rooted. I need to be able to supply paths that look something like this: cmake -DMY_EXTERNAL_LIB_PREFIX=/usr/gapps/my_external_lib/bgp/1.2.1 Which is pretty much the way you'd specify a library in a nonstandard install location in a normal build, right? The problem is that right now this is all going to be re-rooted. Any suggestions on this? Is there some way to tell the cross-compile that certain things (like user-supplied paths) should *not* be re-rooted? -Todd Look at CMake's source file Source/cmFindCommon.cxx for the method cmFindCommon::RerootPaths. It is responsible for re-rooting all the search paths under CMAKE_FIND_ROOT_PATH. There is a #if 0 block at the top of the method that was left from debugging its original implementation. Build CMake with this changed to #if 1 to get detailed information about the list of paths considered *before* re-rooting. Note also that the method does *not* modify paths that already lie under the new root. Perhaps this information can aid your analysis of what happens. -Brad P.S. (FYI) PATHS are supposed to come from user-supplied locations HINTS are supposed to come from system locations. In that documentation, user is the author of the Find* module. PATHS are hard-coded last-ditch guesses of common install locations. They are searched after all other paths. HINTS are educated guesses based on information found from some other source on the actual system, like mpicc -show results. They are searched before normal system directories. ___ 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] Better BlueGene/P and cross-compile support for CMake
Todd Gamblin wrote: CMake cross-compile support is assuming that there is only one (or maybe a few) directories where target software might be installed. I view this as CMAKE_FIND_ROOT_PATH helping for platforms whose SDKs are organized that way. If there is no root and all the target library directories are mingled with those of other architectures then I agree CMAKE_FIND_ROOT_PATH should not be used. Instead the platform file should just provide CMAKE_SYSTEM_LIBRARY_PATH and similar variables without including UnixPaths.cmake. -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
Re: [CMake] Generating dependencies with gcc -M
On 06/28/2010 05:24 AM, Tom Birch wrote:
CMake's dependency scanner uses its own parser to scan for #include
directives, and then builds up the dependency tree this way. I know it's
possible to rig up an invocation of gcc -M to generate the correct
dependencies, and then feed this into the OBJECT_DEPENDS property of source
files, but that means that dependency generation would happen when running
'cmake .', not 'make'.
One compelling reason why dependency scanning is delayed until building
time is that it's taking dynamically generated files into account, i.e.
files not being present at configuration time. Look at the following
CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DYNDEP C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.h void f(void);\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c \#include \f.h\\nvoid f(){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c.in
\#include \f.h\\nint main(void){f(); return 0;}\n
)
ADD_CUSTOM_COMMAND(
OUTPUT main.c
COMMAND cp main.c.in main.c
DEPENDS ${CMAKE_BINARY_DIR}/main.c.in
)
INCLUDE_DIRECTORIES(.)
ADD_EXECUTABLE(main ${CMAKE_BINARY_DIR}/main.c ${CMAKE_BINARY_DIR}/f.c)
After cmaking, when running make, the dependency of main.c.o on f.h is
figured out, and this couldn't be achieved during the configuration as
main.c doesn't exist at that time.
I guess the bigger question here is: why doesn't cmake use gcc -M internally
when it's available? It's vastly superior to any homegrown parser, so why not
use it?
My assumption is: As gcc or other tools for dependency scanning like
makedepend are not available or desired on all systems supported by
CMake there's a need for an in-house solution, at least as fallback,
and if you once have to provide such a solution why not using it
thoroughly? Besides, this reduces the dependencies on external
programs - one of CMake's strengths.
Regards,
Michael
___
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 2.8.2 available for download
On behalf of myself, Ken, Bill, Brad, Alex, Zach and the rest of the
CMake team, we are pleased to announce that CMake 2.8.2 is
available for download at:
http://www.cmake.org/cmake/resources/software.html
Here are the changes for CMake 2.8.2:
No changes in CMake 2.8.2 since 2.8.2-rc4.
Changes in CMake 2.8.2-rc4 (since 2.8.2-rc3)
Bill Hoffman (1):
Fix for bug #10859, ctest exit exception incorrectly reported.
Brad King (3):
Run CMake.HTML test without net access (#10857)
Run CMake.HTML test with older xmllint (#10857)
CTest: Parse empty Git commits correctly
David Cole (2):
Qualify name of extraction location with ExternalProject name.
For VS10: Really use full path file names.
James Bigler (1):
Add support for the emulation version of the cudart library.
Mathieu Malaterre (1):
Cleanup FindOpenSSL. Add support for win64 installation.
Zach Mullen (1):
Parallel CTest hangs if serial test has depends
Changes in CMake 2.8.2-rc3 (since 2.8.2-rc2)
Brad King (1):
Preserve ENV{MAKEFLAGS} in CMake script mode
David Cole (4):
Remove Microsoft Visual Studio .NET from VS8 and VS9 find modules.
Use full path file names in generate.stamp.list.
Use full path file names to express dependencies.
Look in the ctest ini file for GitCommand.
James Bigler (2):
Fixed: CUDA_VERSION_MAJOR/MINOR now computed after first run.
CUDA_VERSION variable passed to REGEX needs quotes to work when not
defined.
Mathieu Malaterre (1):
Cleanup FindDCMTK (using foreach). Fix linking on win32 static libs.
Zach Mullen (2):
Do not exit if stoptime is passed.
Document ctest_build() TARGET option
Changes in CMake 2.8.2-rc2 (since 2.8.2-rc1)
Bill Hoffman (1):
Make sure libarchive uses cmzlib and not the system libz if found.
Brad King (12):
Use forward slashes for objects in response files
Use platform variable for response file flag
Use response file for objects on MinGW and MSYS
Generalize CTest.Update* test dashboard script helpers
ctest_update: Support custom Git update command
ctest_update: Support Git upstream branch rewrites
Fix CMake data and doc paths in Cygwin package
Document scope of source file properties
Run CTest.NoNewline test using built CMake
Tru64: Place cmOStringStream vtable uniquely (#10541)
Enable BootstrapTest on MSYS
Tru64: Use full-path include directives in Makefiles (#10569)
Christoph Watzl (1):
Fix nested source groups with VS 10 (#9863)
Clinton Stimpson (2):
Support pthreads on irix.
Remove macro for querying qmake for qmake variables.
David Cole (2):
Fix issue #10346. Error if SOURCE_DIR is empty.
Remove CTestTest3.
Zach Mullen (1):
Extra coverage glob should subtract the explicitly defined excluded
files
Changes in CMake 2.8.2-rc1 (since 2.8.1):
- Build on Tru64 (#10542)
- Build on mingw-w64
- Build on old Sun (#10550, #10543)
- CPack: Add native BZip2 support
- CPack: Set compression type in RPM spec (#10363)
- CPack: Try harder to initialize staging directory (#10793)
- CTest: Add --stop-time argument
- CTest: Cost data with '-j'
- CTest: Fix memory report
- CTest: Glob for uncovered files during coverage tests
- CTest: Option to specify cdash server
- CTest: PHP Coverage support
- CTest: Process tree kill for OpenBSD, FreeBSD, kFreeBSD, GNU/Hurd
- CTest: Report failure in Update.xml
- CTest: Submit author email in Update.xml
- CTest: Teach ctest_update about Git submodules
- CTest: Teach ctest_update to handle Git upstream branch rewrites
- Cygwin: Export all symbols with ENABLE_EXPORTS (#10122)
- Do not list file names during 'cmake -E tar xz'
- Documentation: Comply with XHTML 1.0 Strict
- Documentation: Fix typo in CMAKE_LIBRARY_PATH (#10291)
- Documentation: Fix typo in HAS_CXX docs (#10578)
- Documentation: More consistent command signatures
- Eclipse: Do not add INCLUDE to environment twice
- Enable extra CodeBlocks generator on Cygwin
- ExternalProject: Support .zip and .bz2 archives, MD5 verification
- ExternalProject: Reconfigure when args change (#10258)
- ExternalProject: Support Git, SVN username/password
- FindCurses: Fix for cygwin ncurses package
- FindHSPELL: Version support
- FindJava: Error if version is not found only when REQUIRED
- FindJava: Support runtime and development components (#9840)
- FindKDE4: Prefer kdeconfig results over system paths
- FindMPEG: Check for 'vo' library
- FindPNG: Support png 1.4 versioned lib names (#10551)
- FindPkgConfig: Add QUIET keyword to pkgconfig macros (see #10469)
- FindZLIB: GnuWin32 support, version support (#5588)
- FindwxWidget: Fix CXX flag parsing (#10209)
- Fix .pdb name attribute in VS project files (#10614)
- Fix CodeBlocks to work with Fortran-only
- Fix VS 2010 custom
[CMake] BundleUtilities and gp_file_type vs OpenMP
Hi,
I have an application that is using OpenMP. In windows, OpenMP need the
vcomp.dll.
While building my installer with CPack, I use the BundleUtilities and
fix_bundle to retrieve all the dlls. Unfortunately, the function
gp_file_type(${f} ${p} p_type) where ${p} = vcomp.dll, VComp file type is
consider a local libraries but the library is install from vcredist.exe.
The function verify_bundle_prerequisites return as 0 in result_val and info
var:
ERRORinfo='external prerequisites found:
f='D:/Michael/SVN/Ingenierie/Clients/Ireq/Neptune/trunk/build/Systems/Carto/Carto/release/Carto.exe'
external_prereqs='vcomp.dll'
Is there a clean way to correct this?
Thank's a lot!
Michaël
___
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] mixed C/C++ link errors on Solaris
I have a library 'bar' that is C++, but exports a C API. So, say, I have this CMakeLists.txt: add_library(bar bar.cpp) add_executable(foo foo.c) target_link_libraries(foo bar) On most platforms this is fine, but on Solaris it can't link due to unresolved externals. I can work around this by either a) linking foo as C++, or b) forcing bar to link to libCrun and libCstd. The first is obviously undesirable because it should be an implementation detail that bar uses C++; users of the library should not need to care. Has anyone run into this before? In particular, does anyone know of a nice, neat, canned solution for grabbing libCrun and libCstd in CMake? (Or is this a case to use 'target_link_libraries(bar -lCrun -lCstd)' instead of 'find_library(Cstd ...)', etc.?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Now I lay me back to sleep. The speaker's dull; the subject's deep. If he should stop before I wake, Give me a nudge for goodness' sake. -- Anonymous ___ 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] mixed C/C++ link errors on Solaris
Not familiar with your compiler, but a c++ main should be used to ensure all c++ static global objects are initialized properly. gcc does a good job at hiding this. Juan On Jun 28, 2010 6:46 PM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: I have a library 'bar' that is C++, but exports a C API. So, say, I have this CMakeLists.txt: add_library(bar bar.cpp) add_executable(foo foo.c) target_link_libraries(foo bar) On most platforms this is fine, but on Solaris it can't link due to unresolved externals. I can work around this by either a) linking foo as C++, or b) forcing bar to link to libCrun and libCstd. The first is obviously undesirable because it should be an implementation detail that bar uses C++; users of the library should not need to care. Has anyone run into this before? In particular, does anyone know of a nice, neat, canned solution for grabbing libCrun and libCstd in CMake? (Or is this a case to use 'target_link_libraries(bar -lCrun -lCstd)' instead of 'find_library(Cstd ...)', etc.?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Now I lay me back to sleep. The speaker's dull; the subject's deep. If he should stop before I wake, Give me a nudge for goodness' sake. -- Anonymous ___ 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
[Cmake-commits] CMake branch, master, updated. v2.8.1-1405-geb7e54f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via eb7e54fe006f5cbf7970c38626fbcd09d5ce8761 (commit) via f9116d0225f0c96a20b508510cffb621e116ac28 (commit) via 11756b9608c7cf59a832296790b6938614cd6597 (commit) via e010d1f688cac98f690e68f95f05c6763d806add (commit) via be4b3c905ee893f3e795ff01984e63065ed27229 (commit) via 7f662c5c629e768959a679bfd732c2799c324705 (commit) via 9d7fa8b59c8b6f164459f4e9a14e445f38e3964b (commit) via 5b3987bc4198e27f1ab060cd31a095ab1e532d32 (commit) via 23a8f31e3fd103a6da716055f4e9cae653b5f851 (commit) via 9949f9fbff2f635285857d2fa74fe769a11eb125 (commit) via a12da80c775fa3e7335f6935cf422da440d89783 (commit) from a55aee5cddc00c33536c957ec4c7732a6083047c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb7e54fe006f5cbf7970c38626fbcd09d5ce8761 commit eb7e54fe006f5cbf7970c38626fbcd09d5ce8761 Author: Brad King brad.k...@kitware.com Date: Mon Jun 28 10:34:04 2010 -0400 Begin post-2.8.2 development diff --git a/CMakeLists.txt b/CMakeLists.txt index 23dd2a5..d77c377 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -340,8 +340,8 @@ ENDMACRO (CMAKE_BUILD_UTILITIES) SET(CMake_VERSION_MAJOR 2) SET(CMake_VERSION_MINOR 8) SET(CMake_VERSION_PATCH 2) -SET(CMake_VERSION_TWEAK 0) -#SET(CMake_VERSION_RC 4) +#SET(CMake_VERSION_TWEAK 0) +#SET(CMake_VERSION_RC 1) # Releases define a tweak level. IF(DEFINED CMake_VERSION_TWEAK) --- Summary of changes: CMakeLists.txt |2 +- ChangeLog.manual | 83 +- 2 files changed, 83 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.1-1533-gf42285b
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f42285bcb9cb34146f239bc4d5928f538b421bac (commit)
via cea9389cc94e85d5d5fc705719147bc4ec7f92da (commit)
from 0deb08d6d05fae2662c28fa8172c74f2ded3f712 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f42285bcb9cb34146f239bc4d5928f538b421bac
commit f42285bcb9cb34146f239bc4d5928f538b421bac
Merge: 0deb08d cea9389
Author: Brad King brad.k...@kitware.com
Date: Mon Jun 28 11:45:11 2010 -0400
Merge branch 'FindMPI-BlueGene-L' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cea9389cc94e85d5d5fc705719147bc4ec7f92da
commit cea9389cc94e85d5d5fc705719147bc4ec7f92da
Author: Brad King brad.k...@kitware.com
Date: Mon Jun 28 11:42:34 2010 -0400
FindMPI: Trust mpicc -showme on BlueGene/L
Do not hard-code known BlueGene/L MPI libraries. We do not know their
location so the linker cannot find them without the proper -L search
path. The MPI compiler tells us about the libraries anyway, and if it
does not then the user can fix the problem locally by editing the
MPI_EXTRA_LIBRARY cache entry.
diff --git a/Modules/FindMPI.cmake b/Modules/FindMPI.cmake
index 481b0e9..ca9649a 100644
--- a/Modules/FindMPI.cmake
+++ b/Modules/FindMPI.cmake
@@ -332,12 +332,6 @@ else (MPI_COMPILE_CMDLINE)
set(MPI_LINK_FLAGS CACHE STRING MPI linking flags)
endif (MPI_INCLUDE_PATH AND MPI_LIBRARY)
-# on BlueGene/L the MPI lib is named libmpich.rts.a, there also these
additional libs are required
-if(${MPI_LIBRARY} MATCHES mpich.rts)
- set(MPI_EXTRA_LIBRARY ${MPI_EXTRA_LIBRARY} msglayer.rts devices.rts rts.rts
devices.rts)
- set(MPI_LIBRARY ${MPI_LIBRARY} msglayer.rts devices.rts rts.rts
devices.rts)
-endif(${MPI_LIBRARY} MATCHES mpich.rts)
-
# Set up extra variables to conform to
if (MPI_EXTRA_LIBRARY)
set(MPI_LIBRARIES ${MPI_LIBRARY} ${MPI_EXTRA_LIBRARY})
---
Summary of changes:
Modules/FindMPI.cmake |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
