Add a CMake build

[Alex Valavanis]

This will allow faster builds (using Ninja) and hopefully make the build system a bit simpler. Jonny's currently working on it.

[Alex Valavanis (valavanisalex)]

Jonny - I just tested lp:qwwad r135. Build log through out a linker error (can't find pthread). Any immediate solution? I ran it as an out-of-source build. Here's a transcript

$ mkdir build-cmake
$ cd build-cmake/
$ CC=clang CXX=clang++ cmake ../
-- The C compiler identification is Clang 3.4.0
-- The CXX compiler identification is Clang 3.4.0
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for dgemm_
-- Looking for dgemm_ - found
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- A library with BLAS API found.
-- Looking for cheev_
-- Looking for cheev_ - found
-- A library with LAPACK API found.
-- Boost version: 1.54.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/devel/qwwad/lp-qwwad-ch/build-cmake

$ make
Scanning dependencies of target gtest
[ 33%] Building CXX object gtest/CMakeFiles/gtest.dir/src/gtest_main.cc.o
[ 66%] Building CXX object gtest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
Linking CXX static library libgtest.a
[ 66%] Built target gtest
Scanning dependencies of target tests
[100%] Building CXX object tests/CMakeFiles/tests.dir/some_tests.cpp.o
Linking CXX executable tests
../gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::~ThreadLocal()':
/home/alex/devel/qwwad/lp-qwwad-ch/gtest/src/gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev]+0x16): undefined reference to `pthread_getspecific'
/home/alex/devel/qwwad/lp-qwwad-ch/gtest/src/gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev[_ZN7testing8internal11ThreadLocalISt6vectorINS0_9TraceInfoESaIS3_EEED2Ev]+0x2e): undefined reference to `pthread_key_delete'
../gtest/libgtest.a(gtest-all.cc.o): In function `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::~ThreadLocal()':
/home/alex/devel/qwwad/lp-qwwad-ch/gtest/src/gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev]+0x19): undefined reference to `pthread_getspecific'
/home/alex/devel/qwwad/lp-qwwad-ch/gtest/src/gtest-all.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev[_ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2Ev]+0x2c): undefined reference to `pthread_key...

[Alex Valavanis (valavanisalex)]

OK - fixed it in lp:qwwad r136 using the answer at:

http://stackoverflow.com/questions/1620918/cmake-and-libpthread

CMake build (of tests folder etc) now succeeds with clang!

[Alex Valavanis (valavanisalex)]

I've also migrated the library name to libqwwad, added the missing lib files and uncommented the files that build OK with clang on Ubuntu 14.04

Still need to sort out:

1. auto detection of GSL and libm
2. why doesn't "make check" do anything? (i.e., "check" target isn't defined)

[Alex Valavanis (valavanisalex)]

OK, I think I've fixed the GSL detection issue as of r148. We now need to add the remaining programmes to the build and hook up "make check"

[Jonathan Cooper (jdc-tas)]

Cool: I found that same CMake FindGSL macro when I was google-ing around earlier.
I've also found how to add the 'make check' functionality (see here: http://www.cmake.org/Wiki/CMakeEmulateMakeCheck).
Doesn't look to taxing... I'll have a play when I get a chance, unless you beat me to it!

[Jonathan Cooper (jdc-tas)]

'make check' functionality added with r162.

[Alex Valavanis (valavanisalex)]

Excellent :) Any remaining OSX issues or can we start adding more programmes into the build?

[Jonathan Cooper (jdc-tas)]

There are no issues with the build system itself... Just with things the files are trying to include; namely armadillo from 'double_barrier.cpp' - I've had a quick look and it seems armadillo is compatible with mac so shouldn't have any problems there, and with error.h in some of the other qclsim code as we discussed before.
I've added in a check for Mac within src/CMakeLists.txt either way so feel free to start adding in more src files; I'll exclude them from the mac build if they're causing issues and deal with them when I can.

[Alex Valavanis (valavanisalex)]

OK, I've removed all usage of error.h in r163. That should hopefully fix the legacy code builds.

Is there an easy way of adding the armadillo dependency? I'm not really familiar with dep handling on CMake yet.

[Jonathan Cooper (jdc-tas)]

CMake has a load of in build scripts (there within the CMake program files folder on windows - not sure were they are on linux) exactly like the one you downloaded for GSL (I'm not sure why there isn't a standard one for GSL) which are used when the find_package macro is used... And it turns out there is one for Armadillo :) I've added it in as of r175.
(Intersting but off topic side note: Apparently the way CMake finds dependencies is slowly changing so that it doesn't have to include loads of 'find' scripts; it's starting to rely on distributors providing there own CMake find scripts such that you point CMake roughly in the right direction and it will use the find script from the dependency itself to configure options. That's how the latest version of Qt interacts with CMake... Might be something to think about in the future if we ever want libqwwad to be included in other peoples projects?)

[Alex Valavanis (valavanisalex)]

I've fixed the CMake build now so that it compiles and installs a subset of the QWWAD tools.

I've removed the OS X checks for now... I guess I'd rather deploy a broken build than no build at all!

I still need to fix the compilation/installation list and include the examples and manual pages.