Problem with cmake's generated config.h

Alexander Neundorf neundorf at
Mon Apr 3 21:16:18 BST 2006

On Saturday 01 April 2006 11:49, Szombathelyi Gy├Ârgy wrote:
> Hi!
> I noticed a flaw with the generated config.h, when the appropriate config
> check is not in the top-level directory's CMakeLists.txt file, but in one
> of its sub-folders. For example: in kdebase/kioslaves/{pop3,smtp} there are
> config checks for the sasl2 library, but in config.h, the HAVE_LIBSASL2
> never defined. If I move the config check to the top-level CMakeLists.txt,
> the #define works correctly. The same applies to HAVE_LIBSMBCLIENT.
> I work-arounded this in kdeadmin/kuser, with creating a custom ku_config.h
> in the kuser directory. Is this a bug or feature of CMake?

kdebase/CMakeLists.txt contains the following code:

include (ConfigureChecks.cmake)
               ${CMAKE_CURRENT_BINARY_DIR}/config.h )
add_subdirectory( kioslave )

The instructions are executed in this order, so at the time when 
configure_file() is called the testsin kdebase/kioslaves/pop3 haven't been 
executed yet. Additionally variables are not propagated the directory tree 
up, i.e. variables defined in a child directory are not known in the parent 
So this is clearly a feature of cmake.

There are two ways how to achieve what we want:
1) put the checks in kdebase/ConfigureChecks.cmake -> simple, monolithic
2) keep the checks in kdebase/kioslaves/ and create specific configuration 
headers there:


#cmakedefine HAVE_LIBSASL2


and in CMakeLists.txt:

               ${CMAKE_CURRENT_BINARY_DIR}/config-kioslaves.h )

and include this file additionally in the sources.

It depends on what we want: modular configuration, which requires more work to 
implement (a lot of checking and recompiling) or keep with the monolithic 

Work: alexander.neundorf AT -
Home: neundorf AT                -
      alex AT               -

More information about the kde-core-devel mailing list