[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: CMake KDE release
From: Alexander Neundorf <neundorf () kde ! org>
Date: 2006-01-29 17:30:50
Message-ID: 200601291830.51048.neundorf () kde ! org
[Download RAW message or body]
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 */
)
Except of getting used to this style I don't see a problem here.
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.
Bye
Alex
--
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org - http://www.kde.org
alex AT neundorf.net - http://www.neundorf.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic