Где хранятся библиотеки Visual Studio

компилятор знает, где находится этот материал.
Теперь, что касается компилятора. Все в стандартных библиотеках C и C++ является «особенным» — компилятор знает (или может знать) о них то, чего он не может знать ни о какой другой библиотеке. Например, если вы компилируете код с помощью , компилятор знает, что нужно связать с библиотекой C Math — вам не нужно говорить ему об этом. (Заметьте, это не относится ко всем старым компиляторам.)

Где-то в вашей системе есть два важных каталога -- каталоги, о которых знает компилятор.

Первый — это каталог «include», в котором содержится все, что вы . (За исключением, может быть, некоторых библиотек C++ - некоторые компиляторы помещают вещи C++ в странные места. Не брезгуйте, однако, у них есть изюминка.) Поэтому, если вы хотите загрузить и использовать специальную библиотеку Foo, вы должны поместить заголовки Foo в каталог «include». (Это или скажите компилятору добавить какой-либо другой каталог в список каталогов, рассматриваемых так же, как каталог «include». [предостережения!])

Другим важным каталогом является каталог "lib", который содержит всю информацию, необходимую для связывания с библиотеками DLL, или код для статического связывания библиотеки. На самом деле это немного сложнее, чем кажется, но для наших целей этого вполне достаточно. Поэтому, когда вы загружаете специальную библиотеку Foo, вы должны поместить данные статической/динамической библиотеки Foo в каталог «lib». (Это или сказать компилятору еще раз.)

Мне очень понравился макрос отсрочки в этом коде. Я не программист на С++, поэтому понятия не имею; это широко используемая вещь? Мне показалось классным использование RAII и лямбда-выражений.

Defer на самом деле не нужен, если вы программируете в так называемом книжном стиле "идиоматического C++". По сути, это защита области действия, выход из области действия, которая обычно обрабатывается деструктором любых ресурсов, с которыми вы работаете.

Defer также используется в Go, Swift и JAI!

Поток Джона — единственное место, где я видел его использование. Хотя это очень полезно

Мне больше нравятся списки, поэтому я сделал их. из pastebin

Я боролся с той же проблемой в других контекстах. В некотором смысле экосистема VS и Microsoft великолепна. Для низкоуровневых/базовых вещей это кажется намного сложнее, чем должно быть.

Однажды я попытался скомпилировать Java JDK в Windows и столкнулся с такими проблемами VS, это довольно ужасно.

Это кульминация нескольких дней работы, направленной на то, чтобы получить расположение библиотек Visual Studio, чтобы он мог связать их в своем новом языке программирования (кодовое имя Jai) и в компиляторе для этого языка.

Это показывает, насколько сложно получить что-то такое простое, как расположение папки.

Вы можете найти на Twitch видеозаписи кодирования в прямом эфире и увидеть, через что ему пришлось пройти, чтобы найти решение. Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6

Можно было бы скопировать и вставить код из clang, который делает именно это, и не тратить все свое время, пытаясь выяснить, где находятся все эти библиотеки (полагаю, в каталоге windows sdk+vs). 🤷‍♂️

Странно, разве wchar_t в Windows не просто кодовые единицы UTF-16? Почему это не может быть преобразовано в UTF-8? Это просто разные кодировки для Unicode.

Я думаю, что это UCS-2, даже не UTF-16.

Спасибо, я искал способ сделать это. Невероятно, насколько недружественно программное обеспечение Windows, когда вы хотите использовать их вместе, по сравнению с linux/mac (например, используйте компилятор Visual C++ из другой программы).

Не проще ли было бы позволить разработчику указать правильный каталог, как и в случае с любой другой зависимостью, и иметь разумное значение по умолчанию. Место установки не рандомизируется.

jblow старается делать все наилучшим образом, а не самым простым.

Раньше в его стримах она называлась find_visual_studio_in_a_ridiculous_garbage_way

Похоже, это действительно странная смесь идиом Jai, C и C++.

Я предполагаю, что free_resources не является деструктором, чтобы сделать это вызываемым из C?

Определение отсрочки с использованием перегруженного оператора+ — изящный прием, делающий синтаксис более естественным, но я бы не стал использовать его так часто в реализации. Я бы, вероятно, использовал что-то вроде следующего в своем собственном коде для случаев, когда требуется бесплатно (и что-то подобное для ->Release()):

Кроме того, сравнение версий, вероятно, можно было бы упростить примерно так:

Зависимости в проектах C и C++ сложны. Создавать проекты C и C++ сложно, а поддерживать информацию о зависимостях внутри проектов C и C++ сложно.

Visual Studio C++ — это самая популярная интегрированная среда разработки и компилятор для платформ Microsoft Windows, широко используемая разработчиками C и C++. Очень часто разработчики вручную добавляют информацию в проект вручную в среде IDE, но этот метод трудно поддерживать с течением времени. К счастью, MSBuild, система сборки, используемая Visual Studio, позволяет определять файлы внешних пользовательских свойств (это XML-файлы), что представляет собой интересную точку расширения для автоматизации и стандартизации многих задач.

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

Давайте начнем с того, что вручную добавим внешнюю библиотеку в один из существующих проектов. Давайте представим, что нам нужны некоторые возможности сжатия в нашем проекте, и мы хотим использовать для этой цели популярную библиотеку ZLib.Команда разработчиков может решить, что они поместят все свои зависимости в «C:\TeamDeps», и процесс добавления такой информации в наш проект обычно включает несколько шагов:

• Добавление включаемых каталогов, в которых можно найти такие заголовки, как zlib.h
• Добавление библиотек, которые необходимо связать, например zlib.lib
• Добавление каталогов библиотек, в которых можно найти эти библиотеки
• Добавление возможных определений препроцессора, которые могут потребоваться библиотеке для правильного поведения.

Все эти задачи можно выполнить в интерактивном режиме в среде IDE, перейдя в представление проекта, щелкните правой кнопкой мыши и откройте «Свойства». Для определения включаемых каталогов необходимо перейти в C/C++ -> Препроцессор -> Дополнительные включаемые каталоги:

Обратите внимание, что вся эта информация определяется для каждой конфигурации, в этом образе конфигурация Release — x64 изменяется. Если мы добавим каталоги include в эту конфигурацию, а затем переключимся на Debug в IDE, сборка не найдет заголовки ZLib. Поэтому необходимо добавлять включаемые каталоги, как правило, во все конфигурации.

Аналогичным образом библиотеки, которые связывает наше приложение, могут быть определены в Linker -> Input -> Additional Dependencies.

И, наконец, необходимы пути к библиотекам, это можно указать в Linker -> General. Как и указанные выше свойства, его также можно определить для нескольких конфигураций.

Этот процесс очень ручной, но мы можем проверить, как он транслируется в файлы проекта. Если мы проверим файл .vcxproj, то найдем что-то вроде этого:

Учитывая, что файлы .vcxproj являются XML-файлами, в них можно напрямую добавлять свойства. Тем не менее, файлы свойств предоставляют очень удобный способ сделать то же самое, сохраняя при этом желаемую развязку и разделение задач в разработке программного обеспечения. Файлы свойств также представляют собой XML-файлы с расширением .props, которые в основном имеют тот же синтаксис, но могут быть импортированы из .vcxproj и даже других файлов свойств. Следуя принципу единой ответственности, мы создадим отдельные файлы свойств, предназначенные исключительно для обработки информации о зависимостях.

Для приведенного выше примера мы могли бы создать файл zlib.props, например:

И затем импортируйте его в файл .vcxproj. Этот импорт также можно добавить вручную в IDE, перейдя в «Диспетчер свойств» -> «Добавить существующий лист свойств», а затем перейдя и выбрав файл zlib.props. Но так как мы немного узнали, как выглядит .vcxproj, давайте сделаем это прямо в нем:

После того, как у нас есть эта настройка, добавить новую зависимость в проект очень просто, добавив новый файл xxxx.props и импортировав его в тот же раздел «Зависимости» в нашем .vcxproj, в одну строку.

Visual Studio C++ — это интегрированная среда разработки с несколькими конфигурациями. Это означает, что он может обрабатывать различные конфигурации сборки, такие как выпуск, отладка или архитектуры, такие как x64 или x86, в одном проекте без перезапуска, просто выбирая его в поле со списком.

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

Если мы хотим поддерживать и разрабатывать несколько конфигураций, как правило, для каждой конфигурации требуется как минимум отдельная библиотека. Существуют разные альтернативы, первый из которых будет использовать разные имена для библиотеки, например, zlibd.lib для отладочной, zlib.lib для выпуска и такие варианты, как zlib64d.lib для 64-битных. Второй вариант — сохранить то же имя библиотеки, но разместить ее в разных папках, например Release/x64 или Debug/Win32.

Чтобы позволить Visual Studio MSBuild использовать активные значения конфигурации, мы можем ввести условные обозначения для значений IDE «Конфигурация» и «Платформа» в нашем предыдущем файле zlib.props, например:

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

И каждый из файлов будет определять определенные переменные, например, zlib_release_x64.props будет:

Этот подход делает более очевидными важные значения, которые необходимо определить, а изменения и улучшения менее подвержены ошибкам.

Очень часто одна библиотека зависит от функциональности другой библиотеки. Например, популярный фреймворк Poco C++ зависит от ZLib (помимо других библиотек, таких как expat, sqlite и т. д.). В большинстве случаев, когда пользователь хочет создать приложение с использованием инфраструктуры Poco C++, он не хочет заботиться обо всех транзитивных зависимостях Poco, а просто хочет указать в своем проекте свою зависимость от Poco, но не от другие транзитивные зависимости, такие как Zlib. Часто пользователи даже не подозревают об этих транзитивных зависимостях

Возможно реализовать эту логику в наших файлах свойств и внедрить в файл poco.props:

Обратите внимание на условие zlib_props_imported . Это флаг, который мы ввели, чтобы избежать повторного импорта одного и того же файла. Как такое могло произойти? Это то, что называется «ромбиком» на графике зависимостей. Если бы у нас была другая зависимость, такая как библиотека Boost, которая также зависит от ZLib, и мы хотим использовать в нашем проекте и Poco, и Boost, файл zlib.props был бы импортирован дважды.

Давайте на этом этапе повторим файлы, которые у нас уже есть:

• zlib.props: точка входа для библиотеки zlib. Он содержит условную логику, основанную на «конфигурации» и «платформе» Visual IDE для выбора одного из следующих файлов. Он также реализует «защиту импорта», чтобы избежать транзитивного включения более одного раза.
• zlib_release_x64.props : содержит конкретные данные о библиотеке zlib в ее выпуске, режиме x64, как ZLibLibraryDirectories , которые могут меняться в разных конфигурациях.
• zlib_debug_x64.props: то же, что и предыдущий, но для конфигурации отладки. Возможны и другие файлы конфигурации.
• poco.props : точка входа в библиотеку poco. Именно этот файл пользователи будут включать в свои файлы проектов .vcxproj. Он содержит транзитивную зависимость от zlib.props .
• poco_release_x64.props: специальные данные для библиотеки poco для выпуска, конфигурация x64.
• … другие файлы для каждой транзитивной зависимости и для каждой конфигурации.

Теперь, когда зависимости хорошо структурированы, у нас есть необходимая инфраструктура для дальнейшей автоматизации процесса. Это может быть очень полезно в нескольких случаях, например, при развитии зависимостей. Многим командам необходимо работать с несколькими проектами и разными версиями своих библиотек C++. Было бы относительно просто определить такой макет, как C:\TeamDeps\zlib\1.2.11 и C:\TeamDeps\zlib\1.2.8 . Каждый проект может определять свои версии и иметь некоторый сценарий для автоматизации создания различных файлов свойств.

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

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

В этом репозитории Github есть проект C++ для Visual Studio 16 2019, реализующий приложение, которое может загружать изображение из Интернета, используя некоторые функции из библиотеки Poco, обрабатывать его с помощью библиотеки OpenCV и отображать с помощью графического интерфейса ImGui. пользовательский интерфейс, визуализирующий его с помощью GLFW. Все эти библиотеки, в свою очередь, имеют несколько транзитивных зависимостей.

Мы могли бы вручную загрузить их и собрать из исходников, поместить в папку типа «C:\TeamDeps», а затем записать наши файлы свойств. Менеджер пакетов Conan C++ может автоматизировать это для нас, управляя загрузкой пакетов из центрального репозитория пакетов с открытым исходным кодом ConanCenter, установкой их в кэш Conan, чтобы они никоим образом не загрязняли и не изменяли систему, и, наконец, используя Генератор MSBuildDeps автоматически генерирует из графа зависимостей все файлы свойств для нашего проекта.

Первым шагом является установка зависимостей (прочитайте файл conanfile.py, если вы хотите проверить, как там указаны версии зависимостей):

Эта команда загрузит и установит все наши зависимости из ConanCenter и транзитивные зависимости (27 из них). Граф зависимостей можно создать с помощью $ conan info .. --graph=graph.html, а затем открыть файл graph.html:

После команды $conan install перейдите в папку conan и проверьте там все сгенерированные файлы .props.

После того, как зависимости установлены и файлы свойств добавлены в проект (это нужно сделать только один раз, проект в репозитории Github уже добавил файлы свойств, ничего делать не нужно), можно построить и запустить проект. Не забудьте выбрать «Release» и «x64», так как это конфигурация по умолчанию, которая будет установлена с помощью conan install.

Использование файлов свойств — это удобный и структурированный способ управления информацией о зависимостях в проектах Visual Studio C++. Они могут быть очень систематически организованы для масштабирования до любого количества зависимостей, управления транзитивными зависимостями и несколькими конфигурациями (выпуск/отладка, x64/x86).

Читайте также:

  
• Как сделать сноску со звездочкой в ​​Word
  
• Как отменить сортировку в Excel
  
• Таблица Word не работает
  
• Как прошить самсунг а51 через компьютер
  
• Как убрать серую полосу в слове справа