MSVC C2859 при использовании другой конфигурации сборки другого проекта в качестве библиотеки

Question

У меня довольно большое многопроектное решение на C++ в Visual Studio 2015. Некоторые из проектов составляют статические библиотеки, которые используются другими проектами, и большая часть они используют прекомпилированные заголовки для ускорения компиляции. Каждый проект также имеет несколько конфигураций сборки: debug, release и несколько конфигураций тестирования, которые всегда создают исполняемый файл для запуска тестов (даже если обычные конфигурации создают статическую библиотеку).

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

Например, у меня есть проект peach, который создает статическую библиотеку и проект cobbler, который полагается на peach. Предварительно скомпилированный заголовок для cobbler ссылается только на системные и внешние библиотеки (без заголовков внутри решения). cobblertest ссылки на конфигурацию peach.lib. peach.lib создается peach «s release конфигурации, так что я конфигурацию решения под названием cobbler-test, который определяет, что:

• peach использует конфигурацию release проекта
• cobbler использует конфигурацию test проекта.

Здание cobbler-test с нуля (или его восстановление, очистка & сборка и т. Д.) Отлично работает. Но если я затем модифицировать исходный файл с именем crust.cpp в cobbler и попытаться построить, я получаю эту ошибку:

c:\...\cobbler\src\crust.cpp(1): error C2859: C:\...\out\cobbler-test.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.

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

Необходимо выполнить полную перестройку каждый раз, когда поражает цель использования предварительно скомпилированных заголовков. Есть ли способ получить конфигурацию инкрементного тестирования для работы без необходимости прибегать к созданию дополнительных конфигураций проектов для каждой комбинации проектов?

Answer 1

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

Хотя это довольно хорошо работает для статических библиотек, поскольку их можно легко импортировать с помощью #pragma comment(lib, ...), это немного проблематично для проектов, которые создают автономные исполняемые файлы. К счастью, в моем случае большинство из этих проектов не имеют большого количества материала, требующего тестирования.