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
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
