replica
/
diffblue-cbmc
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
diffblue-cbmc/CMakeLists.txt

202 lines
6.6 KiB
CMake
Raw Normal View History

Add CMakeLists
2017-08-31 00:10:45 +08:00
cmake_minimum_required(VERSION 3.2)
Add project(CBMC) to CMakeLists Suppresses a "missing project" warning. Each CBMC project should have a project tag.
2019-10-12 08:53:24 +08:00
project(CBMC)
Enable caching for CMake builds (hopefully)
2017-09-01 22:36:36 +08:00
find_program(CCACHE_PROGRAM ccache)
if(CCACHE_PROGRAM)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "${CCACHE_PROGRAM}")
Fix up CMake build (unrelated)
2017-09-14 05:03:57 +08:00
message(STATUS "Rule launch compile: ${CCACHE_PROGRAM}")
Enable caching for CMake builds (hopefully)
2017-09-01 22:36:36 +08:00
endif()
Enable compile command output
2017-09-18 05:08:59 +08:00
set(CMAKE_EXPORT_COMPILE_COMMANDS true)
Enable running tests from CMake
2017-08-31 00:17:38 +08:00
set(CMAKE_OSX_DEPLOYMENT_TARGET 10.9)
Add CMakeLists
2017-08-31 00:10:45 +08:00
include(GNUInstallDirs)
Enable running tests from CMake
2017-08-31 00:17:38 +08:00
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
Add CMakeLists
2017-08-31 00:10:45 +08:00
Make CMake release flags similar to Makefile build
2017-09-08 18:16:26 +08:00
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" OR
CMake refers to Clang on a Mac as AppleClang
2018-06-22 22:09:57 +08:00
"${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang" OR
Make CMake release flags similar to Makefile build
2017-09-08 18:16:26 +08:00
"${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU"
)
# Ensure NDEBUG is not set for release builds
set(CMAKE_CXX_FLAGS_RELEASE "-O2")
CMake builds: avoid NDEBUG in RelWithDebInfo builds Just like is done for Release builds, NDEBUG shouldn't be set for RelWithDebInfo builds either. Although we are trying to move away from straight "assert" and use invariants instead, we a) haven't completed this yet and b) imported code such as optional.hpp continues to use "assert."
2019-01-26 00:29:40 +08:00
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g")
Make CMake release flags similar to Makefile build
2017-09-08 18:16:26 +08:00
# Enable lots of warnings
Add -Wswitch-enum to default GCC/Clang build options This is now consistent with the warnings that Visual Studio would generate, which warns about missing enum cases in switch/case even when a default: is present.
2018-07-10 00:00:13 +08:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wpedantic -Werror -Wno-deprecated-declarations -Wswitch-enum")
Make CMake release flags similar to Makefile build
2017-09-08 18:16:26 +08:00
elseif("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC")
Use git bash when configuring CMake This way you don't have to use Cygwin on Windows to configure cbmc with CMake and allows you to use Windows's native CMake support (assuming git is installed).
2019-10-13 07:17:56 +08:00
# This would be the place to enable warnings for Windows builds, although
# config.inc doesn't seem to do that currently
# Include Git Bash Environment (rqeuired for download_project (patch))
find_package(Git)
if(GIT_FOUND)
get_filename_component(git_root ${GIT_EXECUTABLE} DIRECTORY)
set(ENV{PATH} "${git_root}\\..\\usr\\bin;$ENV{PATH}")
Display an error in case Git wasn't found It's probably safe to assume (since the project relies on submodules) that the user has git installed, so this will stop configuration rather than display a warning and then stop with a confusing error.
2019-10-13 07:42:15 +08:00
else()
message(FATAL_ERROR "Git not found. Git bash is required to configure the build.")
Use git bash when configuring CMake This way you don't have to use Cygwin on Windows to configure cbmc with CMake and allows you to use Windows's native CMake support (assuming git is installed).
2019-10-13 07:17:56 +08:00
endif()
Make CMake release flags similar to Makefile build
2017-09-08 18:16:26 +08:00
endif()
Enable running tests from CMake
2017-08-31 00:17:38 +08:00
set(enable_cbmc_tests on CACHE BOOL "Whether CBMC tests should be enabled")
Set up glucose externalproject
2017-09-08 17:05:51 +08:00
set(sat_impl "minisat2" CACHE STRING
"This setting controls the SAT library which is used. Valid values are 'minisat2' and 'glucose'"
)
Enable running tests from CMake
2017-08-31 00:17:38 +08:00
if(${enable_cbmc_tests})
enable_testing()
endif()
Restore testing of jbmc
2018-05-23 19:04:45 +08:00
Add CUDD to CMake CMake instructions to download Cudd when the CMAKE_USE_CUDD parameter is set to true.
2019-02-01 14:48:55 +08:00
if(DEFINED CMAKE_USE_CUDD)
include("${CMAKE_CURRENT_SOURCE_DIR}/cmake/DownloadProject.cmake")
message(STATUS "Downloading Cudd-3.0.0")
download_project(PROJ cudd
URL https://sourceforge.net/projects/cudd-mirror/files/cudd-3.0.0.tar.gz/download
URL_MD5 4fdafe4924b81648b908881c81fe6c30
)
Build Cudd at the cmake configuration phase This makes Cudd be configured and build at the configuration phase. This simplifies a bit the logic for dependencies of cudd and cudd-cplusplus targets. This is the only way I found to make Ninja build flawlessly.
2019-03-22 01:22:49 +08:00
if(NOT EXISTS ${cudd_SOURCE_DIR}/Makefile)
message(STATUS "Configuring Cudd-3.0.0")
execute_process(COMMAND ./configure WORKING_DIRECTORY ${cudd_SOURCE_DIR})
Add CUDD to CMake CMake instructions to download Cudd when the CMAKE_USE_CUDD parameter is set to true.
2019-02-01 14:48:55 +08:00
endif()
Build Cudd at the cmake configuration phase This makes Cudd be configured and build at the configuration phase. This simplifies a bit the logic for dependencies of cudd and cudd-cplusplus targets. This is the only way I found to make Ninja build flawlessly.
2019-03-22 01:22:49 +08:00
message(STATUS "Building Cudd-3.0.0")
execute_process(COMMAND make WORKING_DIRECTORY ${cudd_SOURCE_DIR})
Add CUDD to CMake CMake instructions to download Cudd when the CMAKE_USE_CUDD parameter is set to true.
2019-02-01 14:48:55 +08:00
add_library(cudd STATIC IMPORTED)
set_property(TARGET cudd PROPERTY IMPORTED_LOCATION ${cudd_SOURCE_DIR}/cudd/.libs/libcudd.a)
Build Cudd at the cmake configuration phase This makes Cudd be configured and build at the configuration phase. This simplifies a bit the logic for dependencies of cudd and cudd-cplusplus targets. This is the only way I found to make Ninja build flawlessly.
2019-03-22 01:22:49 +08:00
add_library(cudd-cplusplus STATIC IMPORTED)
set_property(TARGET cudd-cplusplus PROPERTY IMPORTED_LOCATION ${cudd_SOURCE_DIR}/cplusplus/.libs/libobj.a)
Add CUDD to CMake CMake instructions to download Cudd when the CMAKE_USE_CUDD parameter is set to true.
2019-02-01 14:48:55 +08:00
include_directories(${cudd_SOURCE_DIR})
add_compile_options(-DHAVE_CUDD)
set(CUDD_INCLUDE ${cudd_SOURCE_DIR} CACHE STRING "Record Cudd directory for includes")
endif()
Build coverage reports using CMake Understanding which code is covered by our tests may in future enable automation to check whether code modifications are covered by tests.
2019-01-15 20:56:15 +08:00
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" OR
"${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang" OR
"${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU"
)
Tidy up cmake commands for coverage These commands are equivalent
2019-08-21 00:18:32 +08:00
option(enable_coverage "Build with coverage recording")
Build coverage reports using CMake Understanding which code is covered by our tests may in future enable automation to check whether code modifications are covered by tests.
2019-01-15 20:56:15 +08:00
set(parallel_tests "1" CACHE STRING "Number of tests to run in parallel")
Tidy up cmake commands for coverage These commands are equivalent
2019-08-21 00:18:32 +08:00
if(enable_coverage)
add_compile_options(--coverage -g)
Build coverage reports using CMake Understanding which code is covered by our tests may in future enable automation to check whether code modifications are covered by tests.
2019-01-15 20:56:15 +08:00
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --coverage -g")
if (NOT DEFINED CODE_COVERAGE_OUTPUT_DIR)
set(CODE_COVERAGE_OUTPUT_DIR ${CMAKE_BINARY_DIR}/html)
set(CODE_COVERAGE_INFO_FILE ${CODE_COVERAGE_OUTPUT_DIR}/coverage.info)
endif()
find_program(CODE_COVERAGE_LCOV lcov)
find_program(CODE_COVERAGE_GENHTML genhtml)
add_custom_target(coverage
COMMAND ${CMAKE_COMMAND} -E make_directory ${CODE_COVERAGE_OUTPUT_DIR}
COMMAND ctest -V -L CORE -j${parallel_tests}
COMMAND ${CODE_COVERAGE_LCOV} ${LCOV_FLAGS} --capture --directory ${CMAKE_BINARY_DIR} --output-file ${CODE_COVERAGE_INFO_FILE}
COMMAND ${CODE_COVERAGE_LCOV} ${LCOV_FLAGS} --remove ${CODE_COVERAGE_INFO_FILE} '/usr/*' --output-file ${CODE_COVERAGE_INFO_FILE}
COMMAND ${CODE_COVERAGE_GENHTML} ${CODE_COVERAGE_INFO_FILE} --output-directory ${CODE_COVERAGE_OUTPUT_DIR}
DEPENDS
Add goto-harness dependency and unify format
2019-05-30 20:48:51 +08:00
java-models-library
"$<TARGET_FILE:java-unit>"
"$<TARGET_FILE:unit>"
"$<TARGET_FILE:goto-harness>"
Build coverage reports using CMake Understanding which code is covered by our tests may in future enable automation to check whether code modifications are covered by tests.
2019-01-15 20:56:15 +08:00
"$<TARGET_FILE:cbmc>"
"$<TARGET_FILE:driver>"
"$<TARGET_FILE:goto-analyzer>"
"$<TARGET_FILE:goto-cc>"
"$<TARGET_FILE:goto-diff>"
"$<TARGET_FILE:goto-instrument>"
"$<TARGET_FILE:janalyzer>"
"$<TARGET_FILE:jbmc>"
"$<TARGET_FILE:jdiff>"
"$<TARGET_FILE:smt2_solver>"
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
endif()
endif()
Add option to enable profiling For profiling, -pg must be used for the compilation and the linking steps. (-g must be used as well, so it should be a debug or relwithdebinfo build)
2019-08-21 00:20:04 +08:00
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" OR
"${CMAKE_CXX_COMPILER_ID}" STREQUAL "AppleClang" OR
"${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU"
)
option(enable_profiling "Build with profiling data")
if(enable_profiling)
add_compile_options(-g -pg)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -pg")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -pg")
endif()
endif()
Make memory analyzer optional We were doing this in multiple places, this should make it a bit easier to keep set properties consistent among different places. Ideally we could eventually move away from mentioning targets from modules here on the top level (and instead have each module call cprover_default_properties) but this isn't done in this commit. Because memory analyzer depends on GDB being present and further uses platform specific functionality at the moment it had some ifdef functionality to disable itself. This made the code a bit more complicated than it needed to be, and also lead to the code effectively building defunct executables. This removes these ifdefs and instead excludes memory-analyzer (and related tests) from the build unless requested (via WITH_MEMORY_ANALYZER environment variable or CMake option depending on whether it is a Make or CMake build respectively). Also force building memory-analyzer on Linux and test it there by default (unless explicitly unset). Behaviour on other platforms should be preserved.
2019-05-15 21:44:58 +08:00
function(cprover_default_properties)
set(CBMC_CXX_STANDARD 11)
set(CBMC_CXX_STANDARD_REQUIRED true)
set(CBMC_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY
"Developer ID Application: Daniel Kroening")
set_target_properties(
${ARGN}
PROPERTIES
CXX_STANDARD ${CBMC_CXX_STANDARD}
CXX_STANDARD_REQUIRED ${CBMC_CXX_STANDARD_REQUIRED}
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY ${CBMC_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY})
endfunction()
option(WITH_MEMORY_ANALYZER OFF
"build the memory analyzer")
if(CMAKE_SYSTEM_NAME STREQUAL Linux)
set(WITH_MEMORY_ANALYZER_DEFAULT ON)
else()
set(WITH_MEMORY_ANALYZER_DEFAULT OFF)
endif()
option(WITH_MEMORY_ANALYZER ${WITH_MEMORY_ANALYZER_DEFAULT}
"build the memory analyzer")
Restore testing of jbmc
2018-05-23 19:04:45 +08:00
add_subdirectory(src)
Enable running tests from CMake
2017-08-31 00:17:38 +08:00
add_subdirectory(regression)
Restore testing of jbmc
2018-05-23 19:04:45 +08:00
add_subdirectory(unit)
Make memory analyzer optional We were doing this in multiple places, this should make it a bit easier to keep set properties consistent among different places. Ideally we could eventually move away from mentioning targets from modules here on the top level (and instead have each module call cprover_default_properties) but this isn't done in this commit. Because memory analyzer depends on GDB being present and further uses platform specific functionality at the moment it had some ifdef functionality to disable itself. This made the code a bit more complicated than it needed to be, and also lead to the code effectively building defunct executables. This removes these ifdefs and instead excludes memory-analyzer (and related tests) from the build unless requested (via WITH_MEMORY_ANALYZER environment variable or CMake option depending on whether it is a Make or CMake build respectively). Also force building memory-analyzer on Linux and test it there by default (unless explicitly unset). Behaviour on other platforms should be preserved.
2019-05-15 21:44:58 +08:00
cprover_default_properties(
Tidy up CMakeLists
2017-11-15 23:55:08 +08:00
analyses
ansi-c
assembler
big-int
cbmc
cbmc-lib
cpp
driver
goto-analyzer
goto-analyzer-lib
goto-cc
goto-cc-lib
Move cbmc_solvers as solver_factory to goto-checker module This is the first step of introducing the goto-checker module which will hold the language-agnostic BMC classes.
2018-12-15 20:07:07 +08:00
goto-checker
Tidy up CMakeLists
2017-11-15 23:55:08 +08:00
goto-diff
goto-diff-lib
Add stub for new goto-harness tool This adds a new executable called goto-harness. Right now it doesn't actually do anything, but ultimately its purpose will be to generate "harness" functions for goto-programs - i.e. given some specification, it'll generate a function suitable as a cbmc entry point function that implements that specification. Planned for now are two types of harnesses: One that takes the name of a function with parameters and then generates a function that sets up these parameters and calls the function with them. This is similar to what cbmc does already, however will allow more flexibility in choosing how exactly these parameters will be initialised which was deemed out of scope for cbmc. The other will be able to take a snapshot of a concrete execution of a program, and then start an analysis from that point.
2019-01-22 00:16:34 +08:00
goto-harness
Tidy up CMakeLists
2017-11-15 23:55:08 +08:00
goto-instrument
goto-instrument-lib
goto-programs
goto-symex
jsil
json
Implement JSON symtab language frontend. Implement JSON symtab language, a new, more generic language frontend, able to read GOTO programs in JSON form, from any frontend that generates them. Currently this stands as the support frontend for our ADA conversion tool, GNAT2GOTO.
2017-02-24 02:39:14 +08:00
json-symtab-language
Tidy up CMakeLists
2017-11-15 23:55:08 +08:00
langapi
linking
pointer-analysis
solvers
Integrate STL parser into CBMC executable Includes a basic Statement List language interface (although without any typechecking yet) as well as modifications to some Makefiles and cbmc_languages.cpp. Use the --show-parse-tree option when parsing a .awl file to see the project's output.
2019-05-20 22:52:05 +08:00
statement-list
Add symtab2gb to enable linking of .json_symtab files Right now we have the `goto-cc` tool to create goto binaries from C files and link goto binaries together. This adds a similar type of "linker" tool for the symtab language. I had considered extending 'goto-cc' to handle symtab files as well, however goto-cc (quite reasonably) makes some C-specific assumptions about its input files, and I'd figured rather than working around that it'd be easier to just have a simple command line tool to invoke `goto_convert` and `link_goto_model` (which, in the end, is all we want to do for json_symtabs).
2019-05-08 22:57:20 +08:00
symtab2gb
Tidy up CMakeLists
2017-11-15 23:55:08 +08:00
testing-utils
unit
util
Make memory analyzer optional We were doing this in multiple places, this should make it a bit easier to keep set properties consistent among different places. Ideally we could eventually move away from mentioning targets from modules here on the top level (and instead have each module call cprover_default_properties) but this isn't done in this commit. Because memory analyzer depends on GDB being present and further uses platform specific functionality at the moment it had some ifdef functionality to disable itself. This made the code a bit more complicated than it needed to be, and also lead to the code effectively building defunct executables. This removes these ifdefs and instead excludes memory-analyzer (and related tests) from the build unless requested (via WITH_MEMORY_ANALYZER environment variable or CMake option depending on whether it is a Make or CMake build respectively). Also force building memory-analyzer on Linux and test it there by default (unless explicitly unset). Behaviour on other platforms should be preserved.
2019-05-15 21:44:58 +08:00
xml)
Make JBMC build optional with cmake This commit adds an option to CMake, `WITH_JBMC`, that controls whether the jbmc directory will be built. It is switched on by default, preserving the current behaviour. The motivation is to make it as easy as possible for users to get started with CBMC, especially users who are only interested in the C front-end and are on Windows, where installing the JDK and Maven is a painful exercise. Also updated `COMPILING.md` to note that you can pass `-DWITH_JBMC=OFF` to cmake to avoid building jbmc.
2019-03-14 07:02:22 +08:00
option(WITH_JBMC "Build the JBMC Java front-end" ON)
if(WITH_JBMC)
add_subdirectory(jbmc)
endif()