-
Notifications
You must be signed in to change notification settings - Fork 273
Add CMakeLists alongside existing makefiles #1293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not going to pretend to understand CMake to verify that this is correct. This does appear to build on my machine (+ with the travis change I suppose we can have some certainty it builds elsewhere).
I have two questions:
- Is there a way to verify that the make files generated by this are equivalent (or perhaps generate them from this, and replace the current Makefiles with the generated ones)
- if there are any gotchas or weird non cmake-standard things in here, could they be documented (perhaps there are none).
The generated makefiles will not be equivalent. CMake generates machine-dependent makefiles (the point being that it abstracts over different machine configurations itself, and generates tailor-made makefiles). Therefore, it's not viable to replace the makefile build with cmake-generated makefiles.
There's nothing too weird in here, but if this is adopted I'll add a "getting started with CMake" to the wiki. |
Please add documentation to |
ee8bc72
to
58fc70d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see a test-gen PR introducing this just to check that there aren't any nasty surprises, otherwise LGTM.
The CI jobs should do some form of checking beyond "it compiles." This might either be enabling the regression and/or unit tests, or a simple comparison of the binaries (which ought to be identical, after all). |
I just thought of something that won't work yet: the CBMC executable will be built out-of-source, so the regression tests won't be able to find it. Given that the user might put the build anywhere, it's not practical to hard-code the path. Maybe for now I should just explain that users need to symlink the CBMC executable into |
COMPILING
Outdated
--------------------------------- | ||
|
||
There is an experimental build based on CMake instead of hand-written | ||
makefiles. You may prefer to use this, as it should work on a wider variety of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Omit "You may prefer to use this" -- this isn't marketing.
COMPILING
Outdated
have a package for CMake, and Mac users can get it through homebrew. | ||
Windows users should download it manually from cmake.org. | ||
|
||
1) Navigate to the CBMC directory in a terminal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Get the instructions in line with the above instructions: precise commands, no fuffing about a "CBMC directory" (no idea what that is).
COMPILING
Outdated
|
||
1) Navigate to the CBMC directory in a terminal. | ||
|
||
2) Create somewhere to store your build: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Be precise in your wording: "Create a directory", not "somewhere"
build back-ends. You can use clang (for example) by adding the argument | ||
`-DCMAKE_CXX_COMPILER=clang++` to the command line. You can also tell | ||
CMake to generate IDE projects by supplying the `-G` flag. | ||
Run `cmake -G` for a comprehensive list of supported back-ends. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the detailed instructions. Yet: how to set compiler options? For example, how to change optimisation, how to set additional linking flags? The bits currently in config.inc must be clearly documented here.
${CMAKE_CURRENT_BINARY_DIR}/gcc_builtin_headers_ubsan.inc | ||
) | ||
|
||
generic_includes(ansi-c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is make library_check
implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not yet. I'll look at that now.
src/CMakeLists.txt
Outdated
) | ||
add_dependencies(minisat2-condensed minisat2-extern) | ||
|
||
# Override add_executable to automatically sign the target on OSX. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where are universal binaries and the MacOS version implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's handled automatically. By default, the build will be for the architecture of the machine running the build. However, you can also supply the flag -DCMAKE_OSX_ARCHITECTURES=i386;x86_64
to build fat binaries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will -mmacosx-version-min=10.9
also be supported? Note that this ought to be the default as we have had problems in the past with users being unable to run the tool on those older MacOS versions.
Essentially, whatever is currently configured in common
and config.inc
ought to be the default for the CMake builds as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a few areas I do not yet understand how CMake mimics all the previous features. See comments above.
Shouldn't the regression tests (and unit tests!) also be run from within the "build" (or whatever the user chosen name) folder? That is, all the artifacts generated by running regression tests ought to end up within the "build" folder, not underneath the "regression" folder as is currently the case. |
They should, and this is the case for the unit tests. I'll try to fix this for regression tests too. |
3c694b5
to
957fc5b
Compare
I've been hacking around with the regression tests. The ones with custom driver scripts are a bit awkward, because the scripts have to be adjusted to drive arbitrary executables instead of hard-coded ones. Other than that, it seems to work (on my machine). If it gets through CI I'll squash the commits appropriately. Tests can be run with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on Ubuntu and Mac. Works fine.
src/solvers/CMakeLists.txt
Outdated
@@ -0,0 +1,85 @@ | |||
# TODO Specify which solver to use (minisat2 etc.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you try using glucose and document the changes required to get it to run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do that now.
.travis.yml
Outdated
packages: | ||
- g++-5 | ||
install: | ||
- cmake -H. -Bbuild '-DCMAKE_BUILD_TYPE=Release' '-DCMAKE_CXX_FLAGS_RELEASE=-O3' '-DCMAKE_CXX_FLAGS=-Wall -Wpedantic -Werror' '-DCMAKE_CXX_COMPILER=g++-5' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we compile with -O3 now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default "Release" flags for clang++ and g++ are -O3 -DNDEBUG
. We have to keep assertions enabled, which is why I've manually overridden the flags. I can switch to -O2
too if you'd like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say for a start the Release build ought to be using an as similar set of flags as the current build as possible. Is it possible to make this the default in the CMake configuration rather than requiring overrides on the command line?
I've addressed the last few comments. The glucose build can now be enabled by supplying the flag Also, build flags should match the makefile flags more closely by default. This also allows the travis config to be simplified. |
I've also simplified the CMake files based on #1321. |
Some of the regression tests fail when glucose is used. Switching this off for now. |
Some of the regression tests fail when glucose is used. Switching this off for now.
Can this be captured in an issue, possibly also with a note on what the mismatch is?
Thanks!
|
I've added an issue, #1366, describing the problem |
@peterschrammel are you happy with this now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@reuk, is this mergeable or do you plan further additions for now? |
Yes, it's mergeable |
08f269c Merge pull request diffblue#1388 from smowton/merge-develop-20170914 e3f3abd Merge remote-tracking branch 'upstream/develop' into merge-develop-20170914 4df244c Merge pull request diffblue#1383 from reuk/reuk/sync-projects f25db0a Merge pull request diffblue#189 from diffblue/smowton/fix/remove_debug_code 1fae64c Remove stray use of overlay_map 1264b4d Re-enable old function signatures for test-gen compat e54c0e9 Merge pull request diffblue#338 from thk123/bug/function-flag-on-goto-program 63c9a1e Merge pull request diffblue#1374 from reuk/reuk/maintain-pointer-invariants 00e4555 Fix up CMake build (unrelated) 81f1300 Use PRECONDITION in std_types.h a9806c0 Ensure pointer invariants are maintained a46ad62 Regenerate malformed binary blobs f77822b Merge pull request diffblue#1380 from diffblue/remove-musketeer 22f06fd Correcting windows build 3ede81b Merge pull request diffblue#1293 from reuk/cmake-develop 92a52a5 Corrected doxygen errors c6f1430 Ensure symex and goto-analyzer regenerate functions e37d3d5 Disable failing test in the symex directory 15b89fc Weaked the tests for pointer-function-parameters dee89b0 Fixing the method to work with java_bytecode 1ccd1a2 Add support for using the --function flag to goto-analyze and symex 0732580 Adding missing overrides 71dec3d Use ID_main as the default name for entry function 2aea88d Made generate_start_function abstract f0d6d72 Refactored the regenerate function into goto-programs 71e6800 Added regression test for using --function on a GOTO program 94b7185 Implemented generate_start_function for Java cd416bc Call generate_start_function only when regenerating the start function ee5fb93 Protect against invalid function label 2a3d876 Adding explanatory comment f347a22 Cause a regeneration of the entry method if a --function is provided 69d05a9 Merge pull request diffblue#1382 from pkesseli/bugfix/language-opaque-stubs d45325c Merge pull request diffblue#1378 from thk123/bugfix/fix-symex-appveyor 444f256 Add initial value to languaget::generate_opaque_stubs 91e733d Manually disable some failing tests 41bafc0 Merge pull request diffblue#1375 from pkesseli/bugfix/uncaught-exceptions-invariant a31f1d9 remove musketeer af8d46f Reverting manually commited fixes e73a884 Attempt to fix the symex appveyor build 0496142 Account for replaced functions in exceptions_map 2816b80 revert symex regression until Appvoyer works 6a2fd50 added symex to Appveyor build a2834d0 Map wrappers: forward more of the std::map interface 0a668ae Merge commit '6f386e5eeffa223e7213b596403085f8b497023e' into pull-support-20170908-2 8cd4490 Merge pull request diffblue#1373 from diffblue/symex-trace-fix 5d2d07b enable symex regression testing 5195d24 avoid confusion between SSA lhs and full lhs during assignment 430218f option is now --trace 746bff5 remove_returns missing in symex 211355d comments on test 3896110 output statements 8fc714d use __CPROVER_assert 728ac5b Merge pull request diffblue#1367 from reuk/reuk/disable-alpine-in-travis 73b4357 Merge pull request diffblue#1339 from diffblue/initialize_goto_model 4febd10 Merge pull request diffblue#1364 from diffblue/phread-create-fix 0cfd7b0 Remove PRE_COMMAND scaffolding 04b4f63 Merge pull request diffblue#186 from diffblue/cleanup/misc 577fa6c Tightened up usage of maps 8782103 Merge pull request diffblue#1365 from smowton/smowton/feature/more_map_forwarding 4dde3c5 Disable glucose in Travis 91684da Clean up CMake files after diffblue#1321 7d4e9b5 Make CMake release flags similar to Makefile build 5ee349f Control SAT library from makefiles ad486f8 Set up glucose externalproject 5afa929 Quote paths in flex/bison commands 9afbced Disable 32-bit builds in Travis d953327 Enable caching for CMake builds (hopefully) 6251055 Fix and refactor library_check target 3c36aa5 Enable CMake in Travis f6e4968 Enable running tests from CMake e609bbb Add CMake howto to COMPILING file 22c2ab9 Add CMakeLists 6facf74 Map wrappers: forward more of the std::map interface b846858 Merge pull request diffblue#1291 from LAJW/optional 3ddd377 clean-out ill-modeled optimization in string comparisons 95c5e63 Disable Alpine in Travis fe60e60 pthread_create arguments null/nonnull fix 7d30cde missing copyright header 8c4ff7b remove spurious references to langapi/language_ui.h e4498ca brief list of symbols, from language_uit fc4d44a use goto_modelt 9469552 use initialize_goto_model in CBMC/goto-analyse/etc 40fe0f8 simplify API of goto_convert 40557df Used range iterators d4e89fd Tidy up symbol_tablet::move c125146 Merge pull request diffblue#1245 from tautschnig/run-diagnostic 435c0bf Merge pull request diffblue#1321 from reuk/reuk/remove-unused-files 08a4077 Make the child process that failed to execvp exit 4928f69 Diagnostic output if run/execve fails 5863a75 Merge pull request diffblue#1333 from tautschnig/remove-c_sizeof 498718f Code readability 2217501 Remove unused files 1c8d81a Merge pull request diffblue#1356 from smowton/smowton/feature/test_pl_add_dry_run 56b5e25 Merge pull request diffblue#1358 from thk123/feature/decrease-message-spam 359a3e3 Modified verbosity for loaded message 296349c Add dry-run mode to test.pl f6d94cf clean out an unused method 3613ebc When possible, update array types before typechecking initializer 3273bf5 Fix type casts from initializer lists to arrays of unspecified size 1fa569f sizeof(*(void*)) is sizeof(char) d79067e Remove long-deprecated c_sizeof in favour of size_of_expr et al. 254f133 Merge pull request diffblue#1323 from janmroczkowski/janmroczkowski/goto_modelt-output-const 388a25e Make uncaught_exceptions_analysis.output const 211fcc2 Make path_nodet.output const 9be84ea Make automatont.output const 567eaa7 Make basic_blockst.output const ebbbf5f Make goto_modelt.output const ae584df Move optional unit tests into util directory 4dbf939 Manually fix optional 43d0602 Add unit tests for nonstd::optional 8584bb0 Add nonstd/optional.hpp library 281e384 Workaround for travis performing shallow clones with wrong branch git-subtree-dir: cbmc git-subtree-split: 08f269c
By adding a CMake build alongside the makefile build, we can continue supporting existing users of CBMC, while also supporting development in a wider range of IDEs, with faster build back-ends and better integration with clang-based static-analysis and code completion tools (clang-tidy and YCM).
As long as both builds are tested in CI, we don't need to worry about the build systems getting out-of-sync. I don't think having two build systems will add maintenance overhead: I've been maintaining this build for the last three months or so, and the only time I've had to update it was when unit tests were added. This is possible because I've set the build to automatically pick-up all the source files in each directory containing a CMakeLists.txt (in fact, some of the source files don't build and should probably be removed).