CMake KDE release

[Simon Hausmann]

On Sunday 29 January 2006 18:30, Alexander Neundorf wrote:
> On Sunday 29 January 2006 17:58, Simon Hausmann wrote:
> > On Sunday 29 January 2006 15:32, Alexander Neundorf wrote:
> > [...]
> >
> > >macro(GET_ABS_PATH _abs_filename _filename)
> > >     IF(${_filename} MATCHES "^/.+")
> > >        SET(${_abs_filename} ${_filename})
> > >     ELSE(${_filename} MATCHES "^/.+")
> > >        IF(${_filename} MATCHES "^[a-zA-Z]:\\\\")
> > >           SET(${_abs_filename} ${_filename})
> > >        ELSE(${_filename} MATCHES "^[a-zA-Z]:\\\\")
> > >           SET(${_abs_filename}
> > > ${CMAKE_CURRENT_SOURCE_DIR}/${_filename}) ENDIF(${_filename} MATCHES
> > > "^[a-zA-Z]:\\\\")
> > >     ENDIF(${_filename} MATCHES "^/.+")
> > >endmacro(GET_ABS_PATH)
> >
> > BTW, am I the only one who finds it insane that one has to repeat the
> > entire condition in the else and in the endif part of a condition?
> >
> > Is this a technical limitation of the cmake parser?
>
> I guess it has been a deliberate design decision
> (Many people also do the following:
> #ifdef HAVE_FOO
> ...
> #endif /* HAVE_FOO */
> )

Note that this is not required with the C/C++ preprocessor, unlike with cmake 
conditionals.

> Except of getting used to this style I don't see a problem here.

I can identify three problems:

1) It's inconsistent, see paragraph at the end of this mail. There's a reason 
why other programming languages avoid redundant terms unless they improve 
readability.

) It's error-prone. You can be sure that most people will frequently forget to 
adjust the else and endif part when changing a condition. It wonderfully 
combines with typos people are going to make in the repetitions:

IF (NOT APPLE AND WIN32 OR UNIX AND DEFINED HAVE_GETENV)
    add_foo_bar()
    IF (APPLE OR WIN32)
        baz()
    ENDIF (APPLE OR WIN32)
ELSE (NOT APPLE AND WIN32 OR UNIX AND DEFINED HAVE_GETVN)
    foo()
ENDIF (NOT APPLE AND WIN32 OR UNIX AND DEFINED HAVE_GETENV)

If I understand the mail at

	http://public.kitware.com/pipermail/cmake/2002-August/002942.html

correctly, then cmake doesn't even warn about the typo in the above construct 
because the condition in ELSE is actually evaluated! That's a recipe for 
bugs.

3) It makes the rules harder to read. Clearly

IF (NOT APPLE AND WIN32)
    foo()
ELSE IF (UNIX)
    bar()
ENDIF

is more readable than

IF (NOT APPLE AND WIN32)
    foo()
ELSE (NOT APPLE AND WIN32)
    IF (UNIX)
        bar()
    ENDIF (UNIX)
ENDIF (NOT APPLE AND WIN32)

> cmake is *no* programming language, and many things can be done cleaner in
> real programming languages (python, ruby, ...). It is a specialized
> configuration/macro language, designed to be able to specify software
> builds.

For someone trying to learn the KDE platform it does not matter whether the 
build system uses a full fledged programming language or just some 
descriptive configuration file syntax. What matters is that the syntax is 
intuitive and consistent. I don't believe the cmake way of repeating the 
condition in the else and endif part qualifies for that. Off-hand I can't 
think of any other programming language (or configuration/macro language as 
you said) that has a similar requirement for conditionals.


Simon