[CMake] Removing unused variables from the cache

Hi, Is it possible to remove variables from the cache ? For example: OPTION( BUILD_X "Descr" OFF ) IF ( BUILD_X ) SET( SOME_OPTION "Hello world" CACHE) ELSEIF (BUILD_X) UNSET( SOME_OPTION ) ENDIF ( BUILD_X ) Peter -- Peter Soetens -- FMTC --

Re: [CMake] Removing unused variables from the cache

Quoting Brad King <[EMAIL PROTECTED]>: If BUILD_X is on and SOME_OPTION is set by the user, then BUILD_X is turned off, and then back on the user may expect SOME_OPTION to have retained its value. You can convert it to an INTERNAL cache entry so that it does not show up in the GUI when it is no

[CMake] Setting the cmake compiler...

er: "/home/sspr/src/orocos-components/build2/g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name. [...] That's just what I did[2] ! Why did [1] and [2] occur ? Both seem as bugs to me... Peter -- Peter Soetens

Re: [CMake] Setting the cmake compiler...

Quoting Brad King <[EMAIL PROTECTED]>: Any time you change the compiler you have to wipe out the build tree and start from scratch. Try running CMake like this instead: $ rm -rf build; mkdir build; cd build $ CC=gcc CXX=g++ cmake .. I had read this comment before, but I couldn't believe it

Re: [CMake] Setting the cmake compiler...

it for him INTERNAL: The user can *not* see this variable in the GUI. ...and cache anything that is not calculated. Deprecate all other SET options. I happen to know that the ecos buildsystem uses such definitions to create a build configuration. It works. I've added a 'note' to the

[CMake] resetting CHECK_INCLUDE_FILE

f CHECK_INCLUDE_FILE such that it is done every time ?? Thanks, Peter -- Peter Soetens -- FMTC -- <http://www.fmtc.be> ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] resetting CHECK_INCLUDE_FILE

t macro covers my needs, although the -NOTFOUND thing is not yet documented... Thanks anyway, Peter -- Peter Soetens -- FMTC -- <http://www.fmtc.be> ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] HowTo 'Getting Started Cross compilation with cmake' needed

file-Conventions > > I think, most people expect this as common standard, or not? This is a major issue (read:disagreement) on this list. I expected this as well, but the cmake team has their own reasoning. > > For me, cmake is a good tool, but if more project chan

[CMake] SET_SOURCE_FILES_PROPERTIES in subdir

is 'local'. Peter -- Peter Soetens -- FMTC -- <http://www.fmtc.be> ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] SET_SOURCE_FILES_PROPERTIES in subdir

Quoting Alexander Neundorf <[EMAIL PROTECTED]>: Von: Peter Soetens <[EMAIL PROTECTED]> Hi, I'm having this situation: a source file property is set in a subdir (GENERATED true), but when the source file property is read again in the root directory, it is no longer present

Re: [CMake] Re: How to update a variable inside a subfolder?

Quoting kitts <[EMAIL PROTECTED]>: On Monday 29 Jan 2007 IST, Alan W. Irwin wrote: BTW, my understanding of why variables set in subdirectories do not propagate to parent directories is the CMake developers are using this rule to (rightly) limit variable scope to make it more difficult to have c

[CMake] cmake does not run ldconfig => not found errors

orba.so.1.2.0 => not found ---> this library is present in /usr/local/lib and built/installed in the same cmake project... After running ldconfig as root, the lib is found. Peter -- Peter Soetens -- FMTC -- <http://www.fmtc.be> ___

Re: [CMake] problem with Xerces-C++ 2.7

Quoting Pierre Malarme <[EMAIL PROTECTED]>: I have a problem using Xerces-C++ with cmake. I'm on Mac OS X 10.4.8 with an Intel Core 2 Duo. I try to compile a parser.cpp file with nothing more that includes that i need. When i do so, i have this error message in return : [...] My FindXer

Re: [CMake] Proposal for full CMake cross compiler support

y the build environment and find things not present on the target and vice versa. The FIND_X macro is better suited for 'host environment' detection, as it allows you to tweak paths. So you should only use that one. An improved version of FIND would detect that CMAKE_CROSS_COMPILE has been set and skip the default paths right away. > > What do you think of this approach? Is it suitable for thinking about as > a generic CMake solution for any cross platform compiler? > > Comments welcome. Better late than never ! Peter -- Peter Soetens -- FMTC -- <http://www.fmtc.be> ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake