Keep only a single clone of LLVM

[mabrowning]

deps/llvm AND deps/fileformat/deps/llvm AND deps/capstone2llvmir/deps/llvm AND deps/fnc-patterns/deps/fileformat/deps/llvm ??

Look into conan for sane c++ dependency management...

[PeterMatula]

Yeah, we are aware. The whole git submodule thing, or packages in C++ in general, is kind of an ongoing issue. We will explore the possibilities to make this better in future, but it is not of the highest priority. Only one LLVM should be built and disk space is cheap :-D

[mewmew]

Would it be possible to utilize local installations of LLVM on the system? For instance, Arch Linux provides both the latest LLVM release (5.0 package) as a binary package download, and the 3.9 release (3.9 package).

For the compile time it would be really wonderful to make use of the LLVM libraries installed on the system. On my laptop, it took 1.5 hours to build retdec (#5 (comment)). Most of that was probably due to building LLVM.

[s3rvac]

@mewmew Unfortunately not, because (1) we currently need exactly version 3.9.1 and, most importantly, (2) our version of LLVM contains many customizations that we need for RetDec.

Anyhow, even though a cloned repository contains multiple copies of LLVM, only one of them is built. The dependencies should be set correctly. If you believe they are incorrect, please open an issue.

[PeterMatula]

Yes, LLVM plays a major role in compilation time.

No, it is not possible to use local LLVM for the following reasons:

• There are often big differences between LLVM versions. For example, there is no way one program could be used with both 3.9 and 5.0 versions. Fixing RetDec to a certain version is necessary and avoids confusion and problems that would be caused by users trying to use their own versions.
• Even more important, we do not use vanilla LLVM. See https://github.com/avast-tl/llvm for details. LLVM is great, but it is also aimed at compilation. Sometimes it works against us and we need to hack it a bit. We try to keep hacks to minimum, but I dont know if we would be able to get rid of them altogether. In fact, we might need more of them, since I’m fairly certain there are still some glitches in the matrix - related to code lowering, optimizations, and LLVM’s habit of discarding code with undefined behavior - understandable for compilers, not so good in reverse engineering.

[sandsmark]

just to get a bit clearer overview of what the actual differences are: sandsmark/llvm@3c47bd2

doesn't look impossible to eventually use a vanilla llvm, but it seems like it would require some work to expose the necessary knobs to adjust behavior.

[PeterMatula]

Options mentioned in duplicate #48:

Take a look a this project which is using repo: https://github.com/aurora-fw
Repo Tool: https://source.android.com/setup/using-repo

[MerovingianByte]

Maybe if you could contact the llvm guys to give options to disable code discarding and optimizations, let it be more configurable, then you guys wouldn't need to hack it and use the vanilla version instead.

[PeterMatula]

We got rid of all git submodules. See https://github.com/avast-tl/retdec/wiki/Project-Repository-Structure for more details. See #92 how to fix your repo.