adds omake as an optional compilation backend #1039
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The OMake plugin is not propagating the transitive closure of dependencies, so we need to specify our dependencies explicitly and not depend on dependencies induced by existing dependencies.
They describe the system and should be committed. Unfortunately, with OASIS they mostly contain the boilerplate code, but some of the actually contains the necessary flags.
with some changes, e.g., we can't now look for `_build/plugins`
most of the OMakefiles are unmodified so we can just let oasis to generate them. So far, we have three OMakefiles that we want to have commited: the root one, that has some global options, and disasm with llvm OMakefiles, that include C++ and LLVM options which we just hardcode for now.
so that files generated by oasis setup could be seen by omake
to make codacy happy we switch from using bacticks to `$(...)`.
gitoleg
approved these changes
Jan 28, 2020
as there could be other files, which are not plugins
since omake puts build artifacts directly into the source tree, we just need to reference to them without the _build folder.
plugins weren't built at all.
|
See https://github.com/BinaryAnalysisPlatform/bap/wiki/Experimental-OMake-backend for the future development of the omake backend |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduction
OMake is one of the compilation backends for OASIS. It is extremely fast and on my machine with 10 cores builds BAP 10 times faster (in two minutes from scratch on mine 2Gh machine). It is also extremely fast on rebuilding and can redeploy BAP after a deep change in the matter of milliseconds. It also has a lot of interesting features, like incremental building, when an omake server is polling for changes in the file system and triggers rebuild as soon as you hit save. OMake also watches for the changes in dependencies outside of the source tree, so if you have any external library updated it will notice it and correctly rebuild the dependencies (no more "inconsistent assumptions").
Caveats and workarounds
There are a couple of caveats though, that is why it is not our default build system. First of all, for omake backend to work, we had to submit a few patches to OASIS. While they are pending, we need to use our own fork:
Another issue, is that OMake backend doesn't support OASIS variables and conditional compilation. This immediatelly bars omake as a default backend, since we rely on the configuration variables a lot. But for the development mode, when we build all targets in the repository, it is not a big deal. As a workaround, we turn all conditional compilation into unconditional and hardcode variables for LLVM and C++ (and any other that we might need in future) in corresponding OMakefiles.
For the same reason, we also hardcode opam as the default OCaml package manager, so this backend doesn't support opamless environemnts.
Another important limitation is that it is in general unsafe to use the omake backend with compilers that are earlier than 4.08. While I didn't have any problems, I can't guarantee that they do not exist :) In any case, we will soon drop 4.07 and everyone are encouraged to use 4.08 or later, especially if they are developing BAP and using omake for that.
There are also a couple of non-essential issues with omake (which are fully offsetted by its compilation speed). We will create a wiki page for omake, where we will accumulate knowledge about omake and share tips and tricks.
How to use it
Go to the root directory of the BAP repository and perform the following steps:
(optional) update LLVM flags in
lib/bap_llvm/OMakefile. This step could be done before2or after, shouldn't matter.everything else is as usual