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 --
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
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
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
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
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
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
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
is 'local'.
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
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
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
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>
___
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
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
14 matches
Mail list logo