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

Question

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

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

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

Answer 1

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

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

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

• один поддерживающий SQLite с помощью своего собственного интерфейса, а не через ODBC.

• Обертка веб-сервера C++ вокруг веб-сервера Mongoose C.

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

Answer 2

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

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

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