Управление сторонними исходными кодами и двоичными файлами, используемыми кодом под контролем исходного кода

У меня большая кодовая база под управлением исходным кодом (, была subversion, теперь git ). Для компиляции кода и запуска тестов я использую набор сторонних библиотек. Эти библиотеки можно разделить на несколько категорий L

• . Только двоичные файлы
• Сторонние источники
• Сторонние источники + локальные модификации

Каждая библиотека имеет свои конфигурации {Windows, Linux} X {debug, release} X {32bit, 64bit}. Кроме того, эти библиотеки со временем развиваются, и разные версии моего проекта используют разные версии/сборки этих библиотек.

Мой вопрос в том, как лучше всего хранить эти третьи лица?

Вот мой набор предпочтений:

1. Сохраняйте размер репозитория исходного кода проекта небольшим
2. . Синхронизируйте исходный код проекта со сторонними организациями, чтобы я всегда мог скомпилировать и запустить старую версию
3. . Простота управления
4. Кросс-платформа

Я пробовал и думал о нескольких решениях, но ни одно из них не было удовлетворительным:

1. Используйте версионный скрипт для получения двоичных файлов с ftp-сервера, управляемого вручную, на котором хранятся все версии библиотек. Это работает, но требует тщательного управления структурой каталогов на сервере. Это подвержено ошибкам, поскольку кто-то может перезаписать один из двоичных файлов новой сборкой.
2. Внешние элементы SVN -В то время внешние элементы SVN не могли ссылаться на конкретный тег. Сегодня я использую git.
3. Подмодули Git -Извлекает весь внешний репозиторий, который может быть огромным. В качестве альтернативы требуется управление отдельным репозиторием для каждой отдельной библиотеки. Подмодуль указывает на определенный тег, что означает, что либо я получаю все внешние файлы, когда мне нужны только некоторые, либо я имитирую какую-то странную файловую систему в дереве git.

Мне ясно, что сторонние исходники нужно хранить в git в ветке вендора, но бинарники и заголовки — это совсем другая история.