Зависимости решения Visual Studio
Я работаю в организации с набором продуктов, основанным на нескольких сотнях решений Visual Studio (в основном C ++). Некоторые из этих решений генерируют библиотеки, которые используются другими решениями, и есть также общая папка «include», содержащая заголовки, которые совместно используются несколькими модулями.
Проблема заключается в том, что зависимости нигде явно не указаны, и система сборки разрешает зависимости путем указания линейного порядка сборки, который гарантирует, что зависимые модули будут собраны в нужное время. Это хорошо работает для системы сборки, но оставляет разработчиков в невыгодном положении при попытке работать с компонентами со многими прямыми и косвенными внешними зависимостями. Например, я могу захотеть отредактировать один из проектов библиотеки или общих заголовков, а затем собрать все затронутые модули, не зная заранее, какие из них затронуты. Другой вариант использования включает в себя сборку модуля после выполнения новой проверки из TFS и наличия модулей, от которых зависит его сборка, без необходимости сборки всей системы.
Мне интересно, есть ли какие-либо инструменты, которые могут автоматизировать генерацию зависимостей для построения больших проектов. Я подумал о создании нескольких действительно больших решений, которые бы инкапсулировали другие решения, но это кажется действительно неуклюжим и неуклюжим. Кроме того, мне не нравится идея, чтобы разработчики вручную указывали зависимости, так как это может привести к ошибкам, особенно при такой большой базе кода. Я работал с scons несколько лет назад, и мне очень понравилось, как он может анализировать исходные файлы и автоматически обнаруживать все зависимости. Есть ли сегодня что-нибудь, что может сделать то же самое с решениями Visual Studio?
Это не дубликат Visual Studio: как правильно обрабатывать зависимости проекта?
Мне нужно подчеркнуть масштабы проблемы, которую я пытаюсь решить. Это очень большая существующая кодовая база. В главном каталоге есть несколько сотен подпапок, каждая из которых содержит одно или несколько VS-решений (не проектов). Каждое решение, в свою очередь, содержит один или несколько проектов. Как я уже говорил, я не пытаюсь установить зависимости между несколькими проектами в решении. Проблема намного больше, чем это. Я пытаюсь найти способ установить зависимости между самими решениями (несколько сотен из них). Например, одно решение может содержать несколько проектов, которые генерируют библиотеки для обеспечения безопасности, другие для связи и т. Д. Могут быть, например, десятки решений, которые используют библиотеки связи. По сути, я пытаюсь создать ориентированный циклический граф с сотнями узлов и, возможно, десятками тысяч ребер.
Решение
Вы можете использовать cmake (https://cmake.org/). С его помощью вы можете указать несколько библиотек и приложений для сборки. После настройки вы можете изменить проект, и сборка просто обновит зависимые проекты. Cmake также предоставляет визуальный студийный генератор, чтобы вы могли продолжать использовать эту IDE.
Возможное неудобство для вас заключается в том, что для настройки вы должны явно указать для каждого проекта (библиотека или исполняемый файл), с какими проектами он должен быть связан и какие папки он должен включать. Существуют способы определения некоторых глобальных включений и ссылок, но их использование зависит от вашей проблемы.
Другие решения
VS отслеживает зависимости (анализируя исходные файлы). Не имеет смысла, что что-то может автоматически устанавливать зависимости ваших проектов VS, в любых других инструментах сборки вам все равно придется каким-то образом указать, что для связывания проекта A.exe вам нужно использовать B.lib,
Если вы используете более новые версии VS, вы должны просто добавить ссылки на lib в ваши проекты exe / dll. Если вы вручную добавили зависимости проекта, скорее всего, вы должны удалить их все, особенно убедитесь, что вы не делаете статические проекты lib зависимыми друг от друга. VS позволяет вам это делать (например, если сборка одной библиотеки генерирует некоторые исходные файлы, которые использует другая статическая библиотека), но в целом они не должны иметь каких-либо зависимостей, и это позволяет VS оптимизировать сборки, создавая их параллельно.
Например, обычно у вас может быть какой-то Base.lib, затем System.lib и Graphics.lib. Все это пользователь вашего App.exe. System.lib использует код из Base.lib, Graphics.lib использует код из System.lib и Base.lib. Итак, естественно, цепочка зависимостей ясна, и вы идете и устанавливаете их в VS, и это ошибка! В подобных случаях в VS вы должны сделать эти 4 библиотеки независимыми, и только App.exe должен зависеть от всех этих библиотек (например, он должен иметь ссылки на все из них). VS выяснит, какова правильная зависимость этих проектов.
Что касается случая Cmake: он просто генерирует проекты и решения VS, если вы используете VS, то cmake не может сделать больше, чем сама VS.