use cmake?

[ceheitsch]

@maxieds It's been suggested that we should consider using cmake for this update. Would you please look into that? Thanks!

[maxieds]

For reference, when I get back to this, there is a solid small CMake configuration here: https://github.com/nfc-tools/libfreefare/tree/master/cmake.

[ceheitsch]

@maxieds Reverting from "feature request" in view of continuing discussion in #20.

[maxieds]

@ceheitsch
Following up from the meeting today to document my impressions with the build process transition from vanilla Makefile to automated CMakeLists.txt:

The syntax for the Cmake scripts generally tends to be more readable than the noted dialect of shell script that the Makefile relies on for syntax. This is good for long term maintenance as it will not require too much specialized experience to find someone to maintain these files.

I had a few remarks with respect to concerns about all of the custom, smaller (non-automated) changes I needed to make to the original Makefile to compile on math-mulberry. Yes, it is correct that parts of the build process that tend to change over time are easily automatically re-configured by using Cmake. This is very much true of the libboost sources and their easy native interface into CMake:

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME ON)
set(Boost_FIND_REQUIRED TRUE)
set(Boost_FIND_QUIETLY TRUE)
set(Boost_DEBUG FALSE)
set(Boost_NO_BOOST_CMAKE TRUE)
set(Boost_NO_SYSTEM_PATHS TRUE)
set(Boost_ADDITIONAL_VERSIONS "1.74" "1.74.0")
set(BOOST_MIN_VERSION "1.74.0")
if(NOT DEFINED BOOST_ROOT)
     set(BoostFileSystemRootPath "../BoostLocalInstall")
     set(BOOST_ROOT ${BoostFileSystemRootPath})
endif()
set(Boost_INCLUDE_DIR ${BOOST_ROOT}/include)
set(Boost_LIBRARY_DIR ${BOOST_ROOT}/lib)
find_package(
     Boost ${BOOST_MIN_VERSION}
     COMPONENTS filesystem program_options system log log_setup thread atomic regex chrono
     REQUIRED
)
if(NOT Boost_FOUND)
    message(FATAL_ERROR "Boost Not Found ... Unable to complete the build")
endif()

One point to log here is that many of the individual compiler flags I had to fine tune with the Makefile still need to be explicitly added into the Cmake build profile by hand. For example:

## Install targets (both for binary sub-utilities and the
## Python library to be used with SageMath):
if(APPLE)
    set(CMAKE_CXX_FLAGS
        "${CMAKE_CXX_FLAGS} -Wall -std=c++14 -stdlib=libc++ -fPIC -fopenmp -Wall -g -O3 \
        -DBOOST_LOG_DYN_LINK=0 -DCGAL_HEADER_ONLY -D_GLIBCXX_USE_CXX11_ABI=0 \
        -I/usr/local/include -Iinclude/ -IiB4e/ \
        ${PC_GMP_INCLUDE_DIRS} ${PC_GMPXX_INCLUDE_DIRS} \
        -I${Boost_INCLUDE_DIR} ${CGAL_INCLUDE_DIRS}"
    )
    set(CMAKE_EXE_LINKER_FLAGS
        "${CMAKE_CXX_FLAGS} ${CMAKE_EXE_LINKER_FLAGS} \
        -L/usr/local/lib -lgmp -lgmpxx -lCGAL -lm -lboost_filesystem \
        -lboost_program_options -lboost_system -lboost_log -lboost_log_setup \
        -lc++ -lboost_log-mt \
        ${PC_GMP_LIBRARIES} ${PC_GMPXX_LIBRARIES} ${Boost_LIBRARIES}"
    )
elseif(UNIX AND NOT APPLE) # Primary target: Linux (typically RHEL)
    set(CMAKE_CXX_FLAGS
        "${CMAKE_CXX_FLAGS} -std=c++11 -fPIC -fopenmp -Wall -g -O3 \
        -fvisibility=hidden -fvisibility-inlines-hidden -DABI=0 \
        -DBOOST_FILESYSTEM_NO_DEPRECATED -DCGAL_HEADER_ONLY -UBOOST_DISABLE_THREADS \
        -DBOOST_LOG_DYN_LINK=0 -BOOST_ALL_DYN_LINK=0 -D_GLIBCXX_USE_CXX11_ABI=0 \
        -Iinclude/ -IiB4e/ \
        ${PC_GMP_INCLUDE_DIRS} ${PC_GMPXX_INCLUDE_DIRS} \
        -I${Boost_INCLUDE_DIR} ${CGAL_INCLUDE_DIRS}"
    )
    set(CMAKE_EXE_LINKER_FLAGS
        "${CMAKE_CXX_FLAGS} -L/usr/lib -L/usr/local/lib \
        -L/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9 \
        -L/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32 \
        -Wl,-Bstatic ${PC_GMP_LIBRARIES} ${PC_GMPXX_LIBRARIES} ${Boost_LIBRARIES} \
        -Wl,-Bdynamic -lm -lpthread -lc++ -lc ${CMAKE_EXE_LINKER_FLAGS}"
    )
endif() # -L/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32

In this sense, it is reasonable to expect that the Cmake scripts will eventually still need to get updated over time, just as we did with the historical Makefile sources.

Cmake also makes it easier to separate out chunks of scripts from the monolith Makefile format. This results in more modular code that is easier to parse, understand and maintain.

I will work on wrapping up the full transition to Cmake for use on math-mulberry this week and file the results as a new pull request.

[maxieds]

@ceheitsch
Notice that CMake integration is now enabled through pull request #26. Proposing that we close out this issue. 😺