Taken and adapted from my original comment in #287
See another discussion of this subject in #96

Allow me to say, that the way external dependencies are handled and embedded in LMMS's source is just not a practicable way, and all in all a mess.

In my opinion, one should avoid including source from other projects as far as it's possible. It adds unnecessary compile time for libraries that may be shipped by the linux distro anyway, makes it very difficult to maintain the source, to update the library from upstream, and to push own commits to upstream. Especially the last three points can cause a lot of work.

Basically, it's a matter of principle: Imagine every project out there shipping it's dependencies in the source tree, every project using and installing a different version of the needed libraries. This would lead to a lot of versions of the same library being installed next to each other at the same time which is a huge waste of disk space. It also contradicts the principle and intentions of shared libraries and package management.

Starting my argument at the other end: We can't include every single library we need, for instance we're never going to ship Wine or Qt or Jack or whatever because it's too huge and just not our job as that's what shared libraries and package managers are for.
There are good reasons for the fact that including external sources is no common practice and is something that is generally discouraged to do.

Even though I would head to removing as many third party sources from the tree as possible, I (partly) understand Toby's reasons for including them.
So if we're going to continue shipping external sources (the question about whether to do this in the first place shall not be the point of my message now), we should at least find a better way to do this.

I therefore suggest:

• Have a special directory for dependencies
  Move all 3rd party libraries to one single directory in the source root, let's name it extern. The root directory would then look something like this:

  lmms/
  ├── cmake/
  ├── data/
  ├── extern/
  |      ├── calf
  |      ├── caps
  |      ├── …
  |      └── ZynAddSubFx/
  ├── include/
  ├── plugins/
  ├── src/
  ├── CMakeLists.txt
  ├── …
  └── README
  

• Use git subtree

  Use git subtree to manage the libraries. Basically it works by still having the source code in the tree, but knowing about where it comes from. This way pulling or pushing updates from or to upstream is made possible.
  Note that it causes no extra efforts for users who for instance just want to clone the git repository and compile lmms (in contrast to git submodule, which requires users to explicitly run a command for downloading the directores).
  Subtree has been introduced in git-1.7.11. Update: I just noticed this feature may be not included or not enabled in some distributions by default. It is not needed as long as you don't want to push changes in the subproject though.

• Use CMake's ExternalProject module

  Make use of the functionality CMake provides for this purpose. I think the best option is to use the ExternalProject module. This will help having cleaner CMake scripts, and, if used correctly, should make it possible to remove external projects later without great trouble. This would raise the minimum CMake version to 2.8. The module is also capable of automatically downloading the source or cloning it from git.

Let me hear your opinions on this.