Как интегрировать windeployqt Qt как часть рабочего процесса сборки Visual Studio? - PullRequest
0 голосов
/ 20 февраля 2019

Каждый раз, когда новый проект Qt создается в Visual Studio впервые, даже с установленными VS Tools, мне приходится копировать некоторые связанные с Qt двоичные файлы (Qt5Core.dll, файлы платформы ...).В противном случае при запуске из Visual Studio Qt5Core.dll (или отладочная) будут правильно найдены, но не будет DLL платформы:

enter image description here

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

У Qt есть инструмент для этого, называемый windeployqt, который в основном ищет зависимости(Qt) и скопируйте их.Например:

c:\Qt\Qt5.12.1\bin\windeployqt c:\projects\qt-project\Release --release

проанализирует исполняемые файлы в c:\projects\qt-project\Release и скопирует необходимые DLL, плагины, переводы и другие связанные двоичные файлы в такое расположение.

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

Ответы [ 2 ]

0 голосов
/ 20 февраля 2019

Вам не нужно копировать эти dll, если вы хотите только запускать и / или отлаживать свое приложение из Visual Studio, вы можете добавить пути к зависимостям в среду отладчика в Visual Studio.

Вы можете сделать это в Visual Studio следующим образом:

  • щелкните правой кнопкой мыши файл vcxproj в обозревателе решений
  • , в этом контекстном меню выберите Properties
  • в открывшемся диалоговом окне перейдите к Debugging (на левой панели)
  • на правой панели найдите Environment, и там вы можете использовать что-то вроде этого:

    PATH = $ (QTDIR) \ bin; $ (PATH)

Примечание : при обратном редактировании вы можете увидеть некоторую кодировку для';'это не проблема, вам нужно быть осторожным, когда вы редактируете это, чтобы не пропустить ';'между любыми 2 путями.

Если проект зависит от большего количества библиотек, вы можете добавить туда больше путей среды и не забудьте отредактировать это для всех параметров сборки (Release / Debug / x64 / x86 / etc)и вы можете определить свои собственные переменные с базовым путем для каждой внешней библиотеки.

Теперь вернемся к Qt, эта переменная QTDIR определена в файле .user, для всех конфигураций сборки у вас будет что-то вроде:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <QTDIR>C:\Qt\5.12.1\msvc2017_64</QTDIR>
    <DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
    <LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
  </PropertyGroup>

Проблема, с которой я столкнулся, заключалась в том, что QTDIR был заменен на LocalDebuggerEnvironment (я имел в виду, что сначала определяется LocalDebuggerEnvironment), и, очевидно, это не работает, так что если это такпросто вручную поменяйте местами эти 2 определения с вашим любимым текстовым (или xml) редактором, чтобы QTDIR был определен ранее.

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

0 голосов
/ 20 февраля 2019

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

Более удобный способ сделать это - настроить windeployqt как после сборкисобытие в вашем проекте (Свойства проекта> События сборки> Событие после сборки). Я документирую это здесь, так как я не смог найти никакой явной ссылки, и мне потребовалось некоторое время, чтобы выяснить это.

Чтобы разобраться с переносимостью:

  • $(QTDIR): эта переменная распространяется на путь установки текущей версии Qt (конечно, я предполагаю, что это проект Qt и что Qt VS Tools установлены).Используйте его, чтобы найти windeployqt$(QTDIR)\bin\).

  • $(OutDir): развернуть в каталог сборки исполняемого файла.Как обычно, укажите это, чтобы иметь дело с путями с пробелами.Проблема здесь заключается в том, что $(OutDir) обычно заканчивается обратной косой чертой (\), поэтому при расширении "$(OutDir)" будет создан экранированный символ \", который будет неверно интерпретирован.Чтобы исправить это, вы можете обрезать начальную косую черту: "$(OutDir.TrimEnd('\'))" ( кредиты ).

  • $(Configuration): расширяется до имени текущей конфигурации (обычно Отладка или Выпуск , см. Ниже для других имен конфигурации).Теперь windeployqt чувствителен к регистру в отношении параметров --debug или --release, а имя конфигурации - Заголовок.В нижнем регистре это: --$(Configuration.toLower()) ( кредит ).Этот шаг только для того, чтобы иметь общую команду, и его можно пропустить, поставив флаг --debug или --release вручную.

При этом полная команда после сборки выглядит так:следует:

"$(QTDIR)\bin\windeployqt.exe" "$(OutDir.TrimEnd('\'))" --$(Configuration.toLower())

Эта команда может быть применена равномерно на всех платформах и конфигурациях проектов.

Теперь, если у вас есть другие конфигурации, кроме Release и Debug, вы можете либо:

  • Измените команду, добавив --debug или --release соответственно или

  • Создание пользовательской страницы свойств для "на основе отладки"конфигурации "и" основанные на выпуске конфигурации "и задайте для переменной (например, BaseConfiguration) значение Debug или Release, а затем используйте эту новую переменную в команде.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...