Re: problem setting CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX

On 29/01/2008, Brandon Van Every <bvanevery@...> wrote:
> On Jan 29, 2008 10:42 AM, Yogesh Marwaha <yogeshm.007@...> wrote:
> > Here is new CMakeLists.txt
> > ========================
> > project (eSpy)
> > cmake_minimum_required (VERSION 2.4.0)
> > if(NOT CMAKE_BUILD_TYPE)
> >     set (CMAKE_BUILD_TYPE Release)
> > endif(NOT CMAKE_BUILD_TYPE)
> > if(NOT CMAKE_INSTALL_PREFIX)
> >     set (CMAKE_INSTALL_PREFIX "/usr/local")
> > endif(NOT CMAKE_INSTALL_PREFIX)
> > find_package (Qt4 REQUIRED)
> > add_subdirectory (eSpy)
> > add_subdirectory (eSpyDLin)
> > ======================
> >
> > Now CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX are only set if not
> > previously set/defined.
> > Now no one should have any complaint. Right?
>
> CMAKE_INSTALL_PREFIX always has a default.  Your command above does nothing.

Yes, you are right. Sorry that i didn't checked it properly.

>
> Similarly, if(NOT CMAKE_BUILD_TYPE) is nonsensical.  From the CMake
> Useful Variables wiki entry: "Note that CMAKE_BUILD_TYPE is not
> initialized with a readable value at configuration time. This is
> because the user is free to select a build type at build time. Use

Initial Cache for CMakeSetup.exe

Hi,

is there a way to specify an initial cache when using CMakeSetup.exe 
(like ccmake -C defaultcache.txt on Unix)? Is there somewhere a 
documentation of CMakeSetup.exe commandline parameters?

Thanks and Cya,
Ed

--

-- 

Eduard Hein
Dipl.-Inform.
Software Development
Secure Computing®

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake

Re: Re: FindQt4 in 2.4.8 bug

Hi Bill,

> Can you add a :

Better let me start over,  I think I know what's going on now.

Maybe is the intended behaviour. If it is, I think is quite odd.

Consider the following simple script:

set ( var "whatever" CACHE PATH "" )
message ( STATUS "${var}" )

I would expect to see "whatever" as the value of var since it is being 
explicitely set, but that's not neccesarily what happens: if the cache 
*already* contains a value for var, say "xyz", then that value sticks and 
var is just never set to "whatever" unless FORCE is added (as I found out 
and reported eariler in this thread)

Is this the expected behaviour?

If it is, then it leads to a problem when SET is used for example like this:

set ( QT_INCLUDE_DIR ${qt4_include_dir}  CACHE PATH "" )

because if at some earlier run qt4 was actually not found, QT_INCLUDE_DIR 
gets set to NOTFOUND and once there it is never reset to the include path 
even if qt4 is properly found later. The only way out this tirany is to 
delete the cache and star over.

Win32 Executable.

Hi all,
I'm building a win32 application, and for that I wanted to build the
application as console application in debug mode and win32 application
in release mode.

ADD_EXECUTABLE takes care of /subsystem:windows or /subsystem:console
flag, depends on whether or not you provide WIN32 flag to
ADD_EXECUTABLE.

I switch between debug and release builds quite often. It is very
inconvenient to modify the add_executable call every now and then. Is
there any way i can specify the appropriate flags at once (like we do
for
TARGET_LINK_LIBRARIES with debug and optimized flags).?

Surya

Re: Re: Re: FindQt4 in 2.4.8 bug

Fernando Cacciola wrote:
> Hi Bill,
> 
>> Can you add a :
> 
> Better let me start over,  I think I know what's going on now.
> 
> Maybe is the intended behaviour. If it is, I think is quite odd.
> 
> 
> Consider the following simple script:
> 
> set ( var "whatever" CACHE PATH "" )
> message ( STATUS "${var}" )
> 
> I would expect to see "whatever" as the value of var since it is being 
> explicitely set, but that's not neccesarily what happens: if the cache 
> *already* contains a value for var, say "xyz", then that value sticks 
> and var is just never set to "whatever" unless FORCE is added (as I 
> found out and reported eariler in this thread)
> 
> Is this the expected behaviour?
> 
> If it is, then it leads to a problem when SET is used for example like 
> this:
> 
> set ( QT_INCLUDE_DIR ${qt4_include_dir}  CACHE PATH "" )
> 
> because if at some earlier run qt4 was actually not found, 
> QT_INCLUDE_DIR gets set to NOTFOUND and once there it is never reset to 

Re: Re: Re: FindQt4 in 2.4.8 bug

Quoting Bill Hoffman <bill.hoffman@...>:
> OK, I get it now...   So, the FIND_* stuff will set a value if it is
> NOTFOUND.  However, the set command will not.  I am thinking it should.
>     I am not sure what that will break, but it would be consistent with
> FIND_*.
>
> This should not be a problem if you start from a clean build tree for
> FindQt4.cmake, as QT_INCLUDE_DIR will never get put in the cache as
> NOTFOUND by the current FindQt4.cmake.   So, I think this is something
> we can fix in CMake 2.6.    Feel free to create a feature request, "set
> CACHE should set NOTFOUND variables".

Let's say a library is optional. A current script cannot see the  
difference anymore between "library not found on earlier run" and "I  
did not search for it, yet". SET is well-documented about CACHE and  
FORCE behaviour. Don't break that as you can always use
  if (NOT DEFINED VAR)
    set (VAR "foo" CACHE ...... FORCE)

HS

Re: Re: Re: FindQt4 in 2.4.8 bug

Hendrik Sattler wrote:
> Quoting Bill Hoffman <bill.hoffman@...>:
>> OK, I get it now...   So, the FIND_* stuff will set a value if it is
>> NOTFOUND.  However, the set command will not.  I am thinking it should.
>>     I am not sure what that will break, but it would be consistent with
>> FIND_*.
>>
>> This should not be a problem if you start from a clean build tree for
>> FindQt4.cmake, as QT_INCLUDE_DIR will never get put in the cache as
>> NOTFOUND by the current FindQt4.cmake.   So, I think this is something
>> we can fix in CMake 2.6.    Feel free to create a feature request, "set
>> CACHE should set NOTFOUND variables".
> 
> Let's say a library is optional. A current script cannot see the 
> difference anymore between "library not found on earlier run" and "I did 
> not search for it, yet". SET is well-documented about CACHE and FORCE 
> behaviour. Don't break that as you can always use
>  if (NOT DEFINED VAR)
>    set (VAR "foo" CACHE ...... FORCE)
> 

But:

find_library(FOO_VAR foo)

This will set FOO_VAR (in the cache) if it is not set, or if the value 
has -NOTFOUND in it.

However,

Re: Re: Re: FindQt4 in 2.4.8 bug

Quoting Bill Hoffman <bill.hoffman@...>:

> Hendrik Sattler wrote:
>> Quoting Bill Hoffman <bill.hoffman@...>:
>>> OK, I get it now...   So, the FIND_* stuff will set a value if it is
>>> NOTFOUND.  However, the set command will not.  I am thinking it should.
>>>    I am not sure what that will break, but it would be consistent with
>>> FIND_*.
>>>
>>> This should not be a problem if you start from a clean build tree for
>>> FindQt4.cmake, as QT_INCLUDE_DIR will never get put in the cache as
>>> NOTFOUND by the current FindQt4.cmake.   So, I think this is something
>>> we can fix in CMake 2.6.    Feel free to create a feature request, "set
>>> CACHE should set NOTFOUND variables".
>>
>> Let's say a library is optional. A current script cannot see the   
>> difference anymore between "library not found on earlier run" and   
>> "I did not search for it, yet". SET is well-documented about CACHE   
>> and FORCE behaviour. Don't break that as you can always use
>> if (NOT DEFINED VAR)
>>   set (VAR "foo" CACHE ...... FORCE)
>>
>
> But:
>
> find_library(FOO_VAR foo)
>
> This will set FOO_VAR (in the cache) if it is not set, or if the value
> has -NOTFOUND in it.
>

Re: Re: Re: FindQt4 in 2.4.8 bug

Quoting Bill Hoffman <bill.hoffman@...>:

> Hendrik Sattler wrote:
>> Quoting Bill Hoffman <bill.hoffman@...>:
>>> OK, I get it now...   So, the FIND_* stuff will set a value if it is
>>> NOTFOUND.  However, the set command will not.  I am thinking it should.
>>>    I am not sure what that will break, but it would be consistent with
>>> FIND_*.
>>>
>>> This should not be a problem if you start from a clean build tree for
>>> FindQt4.cmake, as QT_INCLUDE_DIR will never get put in the cache as
>>> NOTFOUND by the current FindQt4.cmake.   So, I think this is something
>>> we can fix in CMake 2.6.    Feel free to create a feature request, "set
>>> CACHE should set NOTFOUND variables".
>>
>> Let's say a library is optional. A current script cannot see the   
>> difference anymore between "library not found on earlier run" and   
>> "I did not search for it, yet". SET is well-documented about CACHE   
>> and FORCE behaviour. Don't break that as you can always use
>> if (NOT DEFINED VAR)
>>   set (VAR "foo" CACHE ...... FORCE)
>>
>
> But:
>
> find_library(FOO_VAR foo)
>
> This will set FOO_VAR (in the cache) if it is not set, or if the value
> has -NOTFOUND in it.
>

Re: Re: Re: FindQt4 in 2.4.8 bug

Hendrik Sattler wrote:

>> But:
>>
>> find_library(FOO_VAR foo)
>>
>> This will set FOO_VAR (in the cache) if it is not set, or if the value
>> has -NOTFOUND in it.
>>
>> However,
>>
>> set(FOO_VAR somevalue CACHE STRING "")
>>
>> Will only set FOO_VAR if it has no value at all.  Seems a bit 
>> inconsistent.
> 
> So you want to give NOTFOUND an even more special status than all the 
> other negative variable values? This is not even close to being 
> backwards-compatible. And you can always check for NOTFOUND and use 
> FORCE. I don't see the problem that qualifies for changing SET in an 
> incompatible way.
> 

OK, I am not that stuck on the idea.

-Bill