Visual Studio перекомпилирует проекты, которые разделяются между двумя решениями без причины

Question

У меня есть два решения S1 и S2, которые ссылаются на пару проектов C ++:

Project    S1    S2
   A       x     x
   B       x     x
   C             x
   D       x

Проект A и B являются статическими библиотеками и используются в обоих решениях, в то время как C и D - это исполняемые файлы, которые используют A и B и являются только частью одного решения.

Если я внесу изменения в проект, VS должен перекомпилировать этот проект и его потребителей, которые являютсяожидаемое поведениеОднако, если я создаю одно из решений, сборка другого становится недействительной, что означает, что VS перестраивает все, хотя никаких изменений не было сделано.

Пример:

Я внесу изменения в A иB.Теперь я строю S1, который строит A, B и D (пока все нормально).Затем я строю S2, который строит A, B и C (почему A и B перестраиваются?).Теперь я снова строю S1 (обратите внимание, что я не вносил никаких изменений с тех пор, как я его построил в последний раз), который снова строит A, B и D.

Почему VS перестраивает эти проекты каждый раз?

Все проекты написаны на C ++ 17, а версия Visual Studio 15.9.10 (последняя версия на сегодня, 28.03.19).

Answer 1

Существует несколько причин:

1. По умолчанию при построении проекта объектные файлы и конечные двоичные файлы выводятся в подкаталог решения, которое ссылается на проект.Таким образом, каждый из решений 1 и 2 имеет свои собственные копии A.lib и B.lib и свои собственные копии всех объектных файлов для создания этих библиотек.Если вы перестроите проект для Solution 1, то копия в этом дереве каталогов будет иметь обновленную библиотеку, но дерево для Solution 2 не будет - оно должно построить ее заново.

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

2. Решение 1Решение 2 может создавать общие проекты с разными параметрами компилятора.Например, может быть, один использует MBCS, а другой - «Юникод».Если вы попытались открыть общий доступ к двоичному файлу, он не будет работать с решением, для которого требуется другой выбор.

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

Когда вы разделяете проект между решениями, вы 'просто делюсь исходным кодом.По сути, каждое решение имеет (возможно, уникальную) копию всех настроек проекта.

Я разделяю множество проектов по нескольким решениям и не особо беспокоюсь о перестройке библиотек при переключении между этими решениями.

Если C и D тесно связаны, то, возможно, вам нужно только одно решение.(У решения, безусловно, может быть много проектов, которые производят исполняемые файлы. Вы можете быстро и легко изменить, какой из них запускать при отладке.) Затем вы обнаружите, что каждая библиотека перестраивается только один раз, но изменение библиотеки также приведет к тому, что оба исполняемых файла будутперестроена.