After the initial release (see Past States), we have settled on the following structure of the RetDec project repository:

• Sources of all libraries and tools that make up RetDec are in a single repository called retdec.
• Sources of our tools are in the src directory. Headers are in include/retdec.
• Third-party libraries are in the deps directory. Their sources are downloaded via CMake's external-project mechanism.
• Preferably, we get third-party libraries directly from their official repositories.
• However, if we use modified third-party libraries, we get them from our modified forks in the avast organization.
• There are no Git submodules, C++ dependency managers like Conan, etc. Only CMake external projects.
• It is possible to build, install, and use only the selected subset of RetDec components. E.g. only the fileformat library and fileinfo tool.
• All the components support a proper system-wide installation (includes, dependencies, documentation, etc.). After the installation, libraries can be used in a standard way.

This solution has the following advantages:

• Simple. No Git submodules, C++ dependency managers, etc. Only CMake external projects.
• Development-friendly. A single repository solution is the fastest and most comfortable option for development.
• Clean. CMake external projects keep the third-party sources out of the retdec repository and provide an elegant way to reference particular versions used by RetDec.
• The build system preserves the advantages of independent repositories - selective build and installation.

This solution has the following disadvantages:

• If someone is interested only in some component of the RetDec project (e.g. fileformat), he or she needs to clone the entire repository containing all RetDec libraries and tools, and configure CMake to build and install only the desired component. This is less elegant than cloning only the desired independent repository (e.g. fileformat).

How did we come to this:

• Originally (before open-sourcing), everything was in one giant internal repository (including sources of third-party projects, regression tests, etc.). It was messy but easy to develop.
• Before open-sourcing, we wanted to split the repository into its logical parts, so that they can be built, used, and developed independently.
• We decided to create a separate Git repository for every logical component and link them together via Git's submodule mechanism. The dependency tree looked like this:

• This proved confusing (#72), hard to maintain, slow to develop, and exhibited several other issues like #14 and #48.
• Instead of reducing the complexity of the dependency tree, or complicating the matter by using C++ dependency managers, we decided to put all the related libraries and tools together into a single repository.
• We keep the advantage of independent repositories by implementing the build system in a way that allows build and installation of only user-selected components.