[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-buildsystem
Subject: config.h.cmake issue ?
From: ralf.habacker () freenet ! de (Ralf Habacker)
Date: 2006-05-03 18:37:40
Message-ID: 4458F874.7090500 () freenet ! de
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic