Proposal: adding default_cmake_config and default_cmake_build functions to build.lunar

[Auke Kok]

On 05/21/2011 05:33 AM, Dennis Veatch wrote:
> Cmake can be run two ways;

when will the hurting stop? :D

some comments below...

> 1. as an in source build from the tld
> 2. as an out of source build, meaning; create a directory one level down from
> tld.
>
> There are some apps that require an out of source build such as kdelibs. When
> cmake is run and this requirement exists there will be a file/macro that lives
> in cmake/modules; MacroEnsureOutOfSourceBuild.cmake that checks from where
> cmake was called.
>
> When this macro is present this is what's supposed to happen when performed in
> the out of source build directory;
>
> 1. cmake is run and populates the CMakeCache.txt file with dependencies found
> and enables/disables those depending on your answers to the DEPENDS questions.
>
> 2. copies the updated CMakeCache.txt from the tld to the build directory.
>
> 3. all is good.

lol!

> This does not happen with those cmake apps without the above macro. Instead,
> the options you choose are not passed to the CMakeCache.txt file in the tld and
> copied to the out of source build directory.
>
> This was the problem I found with kdebindings; I would say no to qscintilla2
> and the make would fail. It was after comparing the tld CMakeCache.txt file
> with that in the out of source build directroy did I see it was not being
> changed. However, changing it to an in source build and the optional_depends
> functioned as it should. To reiterate, this is not a problem with those
> modules that contain this macro.
>
> So how do you know which build method should be used? Well you could untar the
> thing; cd to tld; do ccmake .; press c and see if it throws an error wanting
> an out of source build. That's a bit tedious.
>
> The default_cmake_config function takes care of that for us by checking to see
> if this marco exists and then does the appropriate type cmake. AFAIK any cmake
> based app needing this type of build should contain this macro in
> cmake/modules.
>
> I am sure just as there are exceptions to, oh, say "./configure" that do not
> follow "the standard" practices for autotools there maybe a few execptions
> with cmake. The configure from Cinelerra comes to mind on that point.
>
> Additionally after RTFM for cmake. It appears we call cmake with its options
> and source path slightly out of sequence and this proprosed function puts that
> in line with TFM.
>
> So all you need do with cmake based modules is add; default_cmake_build to
> BUILD and the type of build will be sorted out for you and here is what it
> looks;
>
> diff --git a/var/lib/lunar/functions/build.lunar
> b/var/lib/lunar/functions/build.lunar
> index 4efda36..8009384 100644
> --- a/var/lib/lunar/functions/build.lunar
> +++ b/var/lib/lunar/functions/build.lunar
> @@ -205,6 +205,31 @@ default_cvs_config() {
>                   $OPTS
>   }>  $C_FIFO 2>&1
>
> +# cmake can be run two ways: in source and out of source. The determinante
> method is
> +# to look for a cmake macro, if it exists then do out of source.
> +default_cmake_config() {
> +  debug_msg "default_cmake_config ($@)"
> +  verbose_msg "running \"default_cmake_config\""
> +  verbose_msg "running \"Determining if in source or out of source build is
> required\""
> +  verbose_msg "MODULE_PREFIX=\"$MODULE_PREFIX\""
> +
> +  if [ -e cmake/modules/MacroEnsureOutOfSourceBuild.cmake ]; then
> +  verbose_msg "running \"Out of source build is required, configuring\""
> +  OOSB_DIR="$SOURCE_DIRECTORY/$MODULE-oosb"&&
> +  mkdir $OOSB_DIR&&
> +  cd $OOSB_DIR&&
> +  cmake -DCMAKE_INSTALL_PREFIX=$MODULE_PREFIX  \
> +        -DCMAKE_BUILD_TYPE=RELEASE             \
> +        $OPTS                                  \
> +        $SOURCE_DIRECTORY
> +  else
> +  verbose_msg "running \"in source build configuration\""
> +  cmake -DCMAKE_INSTALL_PREFIX=$MODULE_PREFIX  \
> +        -DCMAKE_BUILD_TYPE=RELEASE             \
> +        $OPTS                                  \
> +        .
> +  fi

seems the indentation here is futzed up - can you fix that up?

I think you'll be fine with only 1 verbose_msg call in the entire 
function, the rest can become debug level messages.

Also, I don't like if-then statements that call the same external 
program (`cmake`) twice with almost the same arguments - can you reduce 
this to something like

if .... ; then
    set options for this case
else
    set different options
fi

cmake $options

?

> +}>  $C_FIFO 2>&1
>
>   default_make() {
>     debug_msg "default_make ($@)"
> @@ -223,6 +248,13 @@ default_game_build() {
>   }>  $C_FIFO 2>&1
>
>
> +default_cmake_build() {
> +  debug_msg "default_cmake_build ($@)"
> +  verbose_msg "running \"default_cmake_build\""
> +  default_cmake_config&&

throw in a free 0x20 will ya?

> +  default_make
> +}>  $C_FIFO 2>&1
> +
>   default_build() {
>     debug_msg "default_build ($@)"
>     verbose_msg "running \"default_build\""


other than that, looks like a decent addition that will hopefully make 
packaging of cmake applications a lot easier!

Auke