Библиотека - это двоичный файл, поэтому все, очевидно, уже определены.
Просто для того, чтобы упорядочить, определения оцениваются как 1-й этап процесса компиляции - этот шаг называется предварительным процессом. На этом этапе для каждого файла cpp создается один файл, содержащий все #include ', которые были в нем, рекурсивно и все макросы оцениваются.
В любом случае сторонние разработчики не должны зависеть от ваших флагов компиляции с одним исключением - release / build lib. Только в этом случае вам нужны 2 версии 3-й библиотеки.
Что касается вопроса о том, нужно ли компилировать сторонние библиотеки один или каждый раз во время компиляции вашего кода, это зависит. Если вы делаете это только для себя, чем делаете то, что вам кажется легким для вас, но если мы говорим о команде разработчиков и проекте, который будет поддерживаться в течение длительного времени, то нужно учитывать больше вещей.
Итак, мы говорим о каком-то надежном решении для команды и хотим несколько раз скомпилировать библиотеку.
В этом случае я лично стараюсь собрать библиотеку третьей части один раз и использовать ее много раз. Это сокращает время компиляции для каждой сборки для каждого разработчика, что означает более быструю разработку.
Хорошо, но где вы держите этих библиотек? Мне нравится физическое разделение - сторонняя библиотека и мой код не в одном дереве. Это может избежать некоторых неумышленных ошибок. Хорошая система сборки, и в большинстве случаев она обязательна, должна быть перестраиваемой. Это означает, что если вы извлекаете код из года в год, вы можете компилировать и получать точно такие же двоичные файлы.
Однажды я использовал какое-то внешнее дерево только для чтения на моей машине. Этим деревом управлял только я.
Для того, чтобы мои исходные коды можно было перестраивать, каждая следующая версия сторонней библиотеки помещала в директорию, содержащую ее версию, и мое дерево исходных текстов было обновлено, чтобы указывать на этот момент. Если вы работаете на нескольких машинах, то дерево только для чтения должно быть видно на всех этих машинах.
Дополнительное решение состоит в том, чтобы проверить, дает ли ваш инструмент SCM (я полагаю, вы его используете) некоторую возможность объединить несколько подпробований из репозитория в одной проверке. Для каждой сторонней библиотеки есть одно поддерево. Таким образом, сторонние библиотеки доступны на всех машинах вашей сборки. В настоящее время я использую этот метод на Subversion - он называется SVN: внешний. На CVS AFAIK это называется cvs modules. Дополнительным преимуществом является то, что библиотеки управляются системой контроля версий, поэтому вы можете отслеживать все изменения, сделанные в сторонних библиотеках.