From kde-buildsystem  Wed May 03 18:37:40 2006
From: ralf.habacker () freenet ! de (Ralf Habacker)
Date: Wed, 03 May 2006 18:37:40 +0000
To: kde-buildsystem
Subject: config.h.cmake issue ?
Message-Id: <4458F874.7090500 () freenet ! de>
X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=116644625832847

David Faure schrieb:
> On Wednesday 03 May 2006 15:32, Ralf Habacker wrote:
>   
>> 	#cmakedefine HAVE_PCREPOSIX 1
>>
>> The problem is that if someone forgets to add this constants the resulting errors are hards to detect. 
>>     
>
> We could fix this by using #if HAVE_FOO and #if !HAVE_FOO instead of ifdef,
> then we would have compiler warnings when HAVE_FOO isn't defined (due to forgetting
> to add it to config-foo.h, or due to forgetting to include config-foo.h in the cpp file).
>
> But for this we need a #cmakedefine equivalent that sets 0 or 1, instead of "undef or 1".
> Could this be done?
>
>   
>> Another example I encountered was the preparation of the CMakeLists.txt for a dbus test build.
>> I took the config.h.cmake from kdecore and added it to the dbus sources. 
>> Now I had to disable all not required #cmakedefine by hand, which wasn't very easy to detect. 
>> And if I had forgotten one, this was only detected by an compiler error, so this ends up in an iterative process until i had fixed this area.    
>>     
>
> I can't see why you started from the huge, monolithic, unsplit, config.h.cmake from kdecore...
> I would have collected the HAVE_ needed by the code, and put those into config.h.cmake.
>
>   
>> Now imagine there is an developer, who adds stuff to a package which uses cmake and it new to cmake.
>> He adds and Find....cmake from another package and is thinking, thats all, but unfortunally he had to add
>> the #cmakedefine by hand, which will be probably forgotten after a time not working with the build system.   
>>     
> I don't really agree, since this is also how it worked with autoconf, you had to add something to config.h.in.
>
>   
I tried to give some experience from a good scons/bksys user, who tried 
to apply cmake to a new project by extracting already available parts 
from an available project, in this example kdelibs. The problems I 
encountered may not fit to good autotools user, but may be similar for 
people using other not mainly unix based build systems. While getting 
this experience I recognized that the most annyoing problem is the dual 
location of include header defines. This does not mean that #ifdef HAVE_ 
is bad.
Your comments shows me that a tool like autoheader is missing in cmake, 
maybe extended by a feature, that adds for example the related  check to 
CMakeLists.txt or similar. For my opinion this would help new users very 
much to start a new project.
>> macro_optional_find_package(PCRE,HAVE_PCREPOSIX)
>>     
> That's really too simplified, there could be multiple defines to make, and it doesn't say where the output should go....
> I think what you want is more like 
>
>   macro_optional_find_package(PCRE)
>   add_define( ${CMAKE_CURRENT_BINARY_DIR}/global.h PCRE_FOUND HAVE_PCREPOSIX )
>
> which would add #define HAVE_PCREPOSIX 1 in global.h (and create that file if necessary)
> if PCRE_FOUND is true  [and 0 otherwise, if we agree about switching to #if - but this should
> probably be an option to add_define]. 
> It would also have to check if global.h already defines it to the right value, to avoid 
> making unnecessary changes to the global.h file.
>
>   
PCRE_FOUND is an implementation detail of macro_optional_find_package. 
Wouldn't it be better to be at the same level for adding the define like 
shown below ?

  macro_optional_find_package(PCRE)
  add_package_define(PCRE HAVE_PCREPOSIX ${CMAKE_CURRENT_BINARY_DIR}/global.h )

  Internal it uses PCRE_FOUND, but that is an information which is not required on the function level  

to set raw defines the following function could be used

  add_define(MYVAR HAVE_PCREPOSIX ${CMAKE_CURRENT_BINARY_DIR}/global.h )


Ralf