[CMake branch] Does not configure on Ubuntu 10.04 LTS

[bska]

This is on the CMake branch, currently being evaluated for inclusion into mainline OPM-Core (cf. issue #119). I am unable to perform even basic configuration on my current work station which runs Ubuntu 10.04 LTS (x86_64).

1. The FindBLAS.cmake macro that comes with CMake 2.8.0 (package version on Ubuntu 10.04) requires Fortran. I had to enable_languages (Fortran) in the CMakeLists.txt file.
2. The FindSUPERLU.cmake implementation in uses the cmake_push_check_state() macro (on line 69 as of commit 1a94211). As far as I can tell, the cmake_push_check_state() macro was not introduced until CMake 2.8.6. What is the minimum version of CMake required to configure the project?

[rolk]

I have not tried it on CMake less that 2.8.7. As much as I love my old Lucid, too, it becomes a question to which degree distributions which are close to expiry (on the deskop, at least) should be supported.

enable_languages(Fortran) can of course be done, but this precludes building the package unless a Fortran toolchain is available (or we could make it optional, which is only half bad).

Perhaps a better solution is to create a 'compatibility' directory which gets included if an older CMake is found, which has macros that "monkey-patch" the installation?

[bska]

I don't know how to resolve the issue, but I thought I'd mention that CentOS 5 (and 6, for that matter) come with CMake 2.6.4 rather than anything from the 2.8.x series. This may be an issue for those who use RHEL. On the other hand, building a more recent cmake binary is trivial so the impact might not be too heavy.

[blattms]

On Tue, Jan 22, 2013 at 03:39:41AM -0800, Roland Kaufmann wrote:

enable_languages(Fortran) can of course be done, but this precludes building the package unless a Fortran toolchain is available (or we could make it optional, which is only half bad).

You might want to take a look on how I solved this issue in DUNE:

http://svn.dune-project.org/websvn/filedetails.php?repname=dune-common&path=%2Fbranches%2Fcmake%2Fcmake%2Fmodules%2FLanguageSupport.cmake

This used as follows:

optional Fortran support

include(LanguageSupport)
workaround_9220(Fortran Fortran_Works)
if(Fortran_Works)
enable_language(Fortran OPTIONAL)
endif(Fortran_Works)

if(Fortran_Works)

search for lapack

find_package(LAPACK)
set(HAVE_LAPACK ${LAPACK_FOUND})
set(HAVE_BLAS ${BLAS_FOUND})
else(Fortran_Works)
set(HAVE_LAPACK Off)
set(HAVE_BLAS Off)

Write an empty FC header

file(WRITE ${CMAKE_BINARY_DIR}/FC.h "")
endif(Fortran_Works)

The downside of this is, that there will be no lapack/blas support if
fortran does not work.

[bska]

@blattms wrote:

The downside of this is, that there will be no lapack/blas support if fortran does not work.

At present the OPM-Core source code contains non-optional direct calls to BLAS and LAPACK subroutines. If I understand you correctly, this means that we will need a working, complete Fortran processing environment if we switch to using CMake. That's something to keep in mind. I am not about to relinquish a very mature code base for linear algebra.

[rolk]

But, obviously, BLAS can be linked to without a working Fortran toolchain, so the problem is rather to have a better FindBLAS.cmake on older installations. My idea is to copy the needed files into a compat/ directory which gets included if the CMake version is too old. This will perhaps help us solve #113 also.

[bska]

@rolk stated:

But, obviously, BLAS can be linked to without a working Fortran toolchain

That's not strictly true. It depends (a lot) on how the BLAS library was constructed. The official way of linking a C program that calls into the BLAS is to use something like

$ gcc t.c $BLAS_LIBS $LIBS $FLIBS

in which $BLAS_LIBS are the libraries comprising the BLAS, $LIBS is any other libraries the program might require and $FLIBS is the run-time support libraries of the Fortran processor used to construct the $BLAS_LIBS. Obviously, exceptions exist (e.g., the GotoBLAS which is mostly written in assembly language and ATLAS which is a C library).

However, the fact that you can usually get by with simply

$ gcc t.c $BLAS_LIBS $LIBS

is usually a result of $BLAS_LIBS being a shared object (e.g., -lblas) which includes references to its prerequisites in an internal table.

[rolk]

Please try if importing this commit to your cmake branch now enables you to build without modifications:

wget https://gist.github.com/raw/4594611/8acd7c2b50b2629da78a699470793a3514d9a72c/cmake-compat.patch -O - | git am

[bska]

Using the change from the gist, I was able to get a lot further, but the process didn't complete. Now it hinges on the write_basic_config_version_file() macro. Apparently, this was introduced in CMake 2.8.5 and, depressingly, deprecated and renamed to write_basic_package_version_file() in CMake 2.8.8 .

[rolk]

The irony here is that I think the macro was deprecated because they thought the name was confusing... Anyway, I don't expect the CMake boilerplate to make sense out of the YYYY.MM version scheme anyway, so a custom macro is in order.

Which means that commit ae72485 and onward should be able to get you somewhat further; I think the best thing is to get a new checkout and then reapply the gist on top of that one; if we're able to actually get a configure through I'll commit it.

[bska]

More progress, but I still cannot get through configure (this time on my laptop, still Ubuntu 10.04 LTS, x86_64). I end up with lots of messages of the form

CMake Error at CMakeLists.txt:214 (string):
  string end index: -1 is out of range 0 - 19

This is the SUBSTRING clause of the installation portion of CMakeLists.txt, in particular

### installation ###                                                            
string (LENGTH ${PROJECT_SOURCE_DIR} _prefix_length)                            
foreach (_hdr IN LISTS opmcore_HEADERS)                                         
  get_filename_component (_dir ${_hdr} PATH)                                    
  string (SUBSTRING ${_dir} ${_prefix_length} -1 _rel_dir)                      
  install (                                                                     
    FILES ${_hdr}                                                               
    DESTINATION include${_rel_dir}                                              
    )                                                                           
endforeach (_hdr)                                                               

Is there something wrong on my end?

[bska]

I wrote:

Is there something wrong on my end?

The answer is: Yes, there is. My CMake is too old. Specifying length as -1 in SUBSTRING to extract the remainder of the string starting at begin is a feature of CMakes 2.8.5 and later. Earlier editions of CMake do not feature this (very useful) short hand.

[rolk]

I guess we could do

 string (LENGTH ${_dir} _dir_length)
 math (EXPR _dir_remainder "${_dir_length} - ${_prefix_length}")
 string (SUBSTRING ${_dir} ${_prefix_length} ${_dir_remainder} _rel_dir)

if that is supported...

[bska]

Yes, it (the math feature) is indeed supported.

Using that calculation I am able to run through the configuration without issue. Now, however, the build fails at the generation of the lib/libomcore.so shared object. The last lines of make VERBOSE=1 are

cd /tmp/opm/build/opm-core.git/dbg/lib && /usr/bin/objcopy --only-keep-debug "\$<TARGET_FILE:opmcore>" "\$<TARGET_FILE:opmcore>.debug"
/usr/bin/objcopy: '$<TARGET_FILE:opmcore>': No such file
make[3]: *** [lib/libopmcore.so.2013.2] Error 1
make[3]: Leaving directory `/tmp/opm/build/opm-core.git/dbg'
make[2]: *** [CMakeFiles/opmcore.dir/all] Error 2
make[2]: Leaving directory `/tmp/opm/build/opm-core.git/dbg'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/opm/build/opm-core.git/dbg'
make: *** [__everything] Error 2

This is a configuration that was set up using the command

$ cmake ../../../opm-core/ -DCMAKE_INSTALL_PREFIX=/home/bska/usr/local -DCMAKE_BUILD_TYPE=Debug

as advised in the CMake branch README file. Did I do something wrong?

[rolk]

No, but the $<TARGET_FILE:...> construct is probably only supported in a newer CMake version (2.8.4), and interpreted literally in the old version (someone should point out to KitWare the meaning of patch version numbers!)

[bska]

I feel your pain. To be honest, there is some precedence to changing things in (very) minor version number. For instance, GNU Make made an incompatible change (I forget which) to the language between versions 3.80 and 3.81...

[rolk]

New attempt to work around this with cmake branch up to commit bf7f89a. (this include the previous mentioned gist too, so you can just checkout anew if you have none of your own changes (little likely, since it doesn't build))

[bska]

I forgot to follow up on this issue. The cmake branch as of commit 8a732c1 works perfectly on Ubuntu 10.04 LTS. I did experience something slightly worrying, simply issuing make after a git pull produced a build failure that I was unable correct without creating a new build directory from scratch. Of course, that is probably due to me not being used to working with CMake.

In any case, this issue is solved as far as I am concerned. I'll close it.