[CMake] #cmakedefine and the #if vs #ifdef argument

[Mike Jackson]

Sometimes I'll do something like the following:

 set (FOO_SOMETHING_SUPPORT 0)
OPTION (USE_SOMETHING "blah blah" ON)
if (USE_SOMETHING)
 set (FOO_SOMETHING_SUPPORT 1)
endif()

then in my .h.in file I'll have:

#define FOO_SOMETHING_SUPPORT @ FOO_SOMETHING_SUPPORT@

That is just one way to do what you want. Others will chime in with more ideas.

Mike

On Thu, Jun 11, 2009 at 10:02 PM, Hostile Fork<hostilefork at gmail.com> wrote:
> On Jun 11, 2009, at 14:47 , Pau Garcia i Quiles wrote:
>>
>> #define VAR_THAT_IS_ON @VAR_THAT_IS_ON@
>> #define VAR_THAT_IS_OFF @VAR_THAT_IS_OFF@
>>
>> If you call CMake with 'cmake -DVAR_THAT_IS_ON=1 -DVAR_THAT_IS_OFF=0',
>> it will produce:
>>
>> #define VAR_THAT_IS_ON 1
>> #define VAR_THAT_IS_OFF 0
>
> Hello Pau, thanks for the quick response...
>
> This approach would work if I were using STRING.  However, the variables in
> question were created using "option", and are BOOL...which seems preferable.
>  Yet this gives rise to some very unusual behavior in how they substitute
> using @VAR at .
>
> Anything equivalent to 'off' (e.g. "0", "off", "falSE", "NO") produces an
> all-caps "OFF".  So that means I get:
>
>        #define VAR_THAT_IS_OFF OFF
>
> If using the command line ("-DVAR_THAT_IS_ON=[stuff]"), then any stuff
> equivalent to 'on' (e.g. "1", "Yes", "oN", "True") is forced to ON.  So that
> seemed pretty symmetric:
>
>        #define VAR_THAT_IS_ON ON
>
> I was tempted to just '#define OFF 0' and '#define ON 1' in my file and move
> on.  But when using the interactive mode ("cmake -i") it did something
> unusual... it preserved the specific string you had used to specify 'on'.
>  So you get a wide variety of possibilities, such as:
>
>        #define VAR_THAT_IS_ON 1
>        #define VAR_THAT_IS_ON on
>        #define VAR_THAT_IS_ON On
>        #define VAR_THAT_IS_ON oN
>        #define VAR_THAT_IS_ON ON
>        #define VAR_THAT_IS_ON yes
>        #define VAR_THAT_IS_ON Yes
>        #define VAR_THAT_IS_ON yEs
>        ...
>        #define VAR_THAT_IS_ON true
>        ...
>        #define VAR_THAT_IS_ON TRUe
>        #define VAR_THAT_IS_ON TRUE
>
> (Note: strings that aren't allowed signifiers of ON/OFF are treated as off.
>  So entering "banana" in the interactive mode will get you an all-caps OFF
> in the substitution.)
>
> The command line does not do the case standardization for variables declared
> as "BOOL", only those made using option.  So if you say:
>
>        set(VAR_BOOL OFF CACHE BOOL "A boolean variable")
>
> Then supplying '-DVAR_BOOL=oN' on the command line will substitute to 'oN'
> and not 'ON'.  Changing this to an option gets the normalization back:
>
>        option(VAR_BOOL "A boolean variable")
>
>
> ==> SOURCE INVESTIGATION <==
>
> Since I'm curious about CMake and understanding what it does, I looked into
> the source.  I gather the short answer is that any current appearance of
> standardization for boolean substitution is unintentional.
>
> I'm not sure how valuable establishing such a standard would be... since it
> could apply only to 'option' variables (and those 'set' variables that were
> declared to be in the cache and BOOL).  Though it doesn't look too hard to
> do.  All cached variables seem to be added through
> cmCacheManager::AddCacheEntry:
>
>
>  http://public.kitware.com/cgi-bin/viewcvs.cgi/Source/cmCacheManager.cxx?revision=1.112&root=CMake&view=markup
>
> So a quick hack would be to change the start of that function to:
>
>        CacheEntry& e = this->Cache[key];
>        e.Properties.SetCMakeInstance(this->CMakeInstance);
>        if ( value )
>                {
>                if ( type == cmCacheManager::BOOL )
>                        e.Value = cmSystemTools::IsOn(value) ? "ON" : "OFF";
>                else
>                        e.Value = value;
>                e.Initialized = true;
>                }
>        else
>                ...
>
> But you're still stuck with having to #define ON and OFF... which I don't
> particularly care for.  So perhaps a parameter to configure_file would help?
>  It could tell CMake to turn '#cmakedefine VAR_THAT_IS_OFF' into  '#define
> VAR_THAT_IS_OFF 0'.  Or rather than a parameter, there might just a new
> keyword (such as '#cmakedefine01 VAR_THAT_IS_OFF'.)
>
> Any thoughts?
>
> ---Brian
> _______________________________________________
> 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
>