Реорганизовать классы в статические библиотеки

Question

Я собираюсь попытаться реорганизовать способ, которым моя группа создает набор больших приложений, которые разделяют около 90% их исходных файлов. В настоящее время эти приложения создаются без каких-либо библиотек, кроме внешних, которые не находятся под нашим контролем. В приложениях используются одни и те же общие исходные файлы (мы не поддерживаем 5 версий одних и тех же файлов .h / .cpp), но они не встроены ни в одну общую библиотеку. Таким образом, в настоящее время мы платим цену за создание одного и того же кода снова и снова для каждого приложения, каждый раз, когда мы намереваемся выпустить версию. Для меня это звучит как основной кандидат на использование библиотек для захвата общего кода и сокращения времени сборки. У меня нет возможности использовать DLL, поэтому подход заключается в использовании статических библиотек.

Я хотел бы знать, какие советы вы бы дали, как решить эту задачу. У меня ограниченный опыт создания / организации статических библиотек, поэтому приветствуются даже основные предложения по организации / получению. Может быть, даже хорошая книжная рекомендация?

Я сделал короткое упражнение, найдя все подмножество файлов, которые совместно используются каждым приложением. В качестве подтверждения концепции я взял эти файлы и поместил их в одну статическую библиотеку "Common Monster". Сборка полного приложения с использованием этой единственной статической библиотеки, безусловно, сокращает время сборки всех приложений, но стоит ли на этом останавливаться? Назначение библиотеки в этой форме не очень сфокусировано и выглядит как ленивая попытка модульности. Эти приложения находятся в процессе разработки, и я боюсь, что эта установка вызовет проблемы в дальнейшем.

Answer 1

Убедитесь, что зависимости ваших библиотек образуют ациклический ориентированный граф (дерево). Хотя это не обязательно проблема для статических библиотек (на самом деле я не уверен), это будет проблемой, если вы когда-нибудь решите переключиться на dll. В зависимости от вашей ситуации это может потребовать некоторого изменения интерфейсов.

Еще одна вещь, которую я заметил (наверняка в MSVC), которую вы можете рассмотреть, если скорость сборки является важной проблемой: библиотеки DLL связываются намного быстрее, чем статические библиотеки. Я предполагаю, что это потому, что их не нужно копировать в новый исполняемый файл и нет необходимости искать неиспользуемый код. Даже если это не вариант для производства, вы можете использовать этот трюк во время разработки.

У меня также есть привычка создавать файлы решений с помощью CMake, потому что проще просматривать весь процесс сборки, чем просматривать бесконечный список параметров в графическом интерфейсе. Вам решать, хотите ли вы идти по этому пути.

Answer 2

Очень сложно дать общие рекомендации в этой области - как вы структурируете библиотеки, во многом зависит от того, как вы их используете. Возможно, если я опишу свои собственные библиотеки кода, это может помочь:

• Одна библиотека общего назначения, содержащая код, который, как я ожидаю, будет иметь шанс использовать по крайней мере 50/50 для всех приложений. Это включает в себя строковые утилиты, регулярные выражения, оценку выражений, синтаксический анализ XML и поддержку ODBC. Возможно, это следует немного разделить, но это облегчит распространение моего кода в проектах FOSS, чтобы он оставался монолитным.

• Библиотека, поддерживающая многопоточность, обеспечивающая обертки вокруг потоков, мьютексов, семафоров и т. Д.

• Один поддерживает SQLite через собственный интерфейс, а не через ODBC.

• Оболочка веб-сервера C ++ для веб-сервера Mongoose C.

Библиотека общего назначения используется во всех вещах, которые я пишу, остальные в более специализированных обстоятельствах. Заголовки для каждой библиотеки хранятся в отдельных каталогах, как и сами двоичные файлы библиотеки (хотя они, вероятно, должны находиться в одном каталоге lib).