Думаю многие из вас знакомы с таким мощным кросс-платформенным инструментарием, как Qt и насущной проблемой сборки Qt с Visual Studio. Работал я раньше с версией 4.8 и бед не знал, пока начальство не заставило не дало указание переходить на новую, недавно вышедшую, 5 версию. К слову сказать, сам переход проблем не вызвал, да вот понадобилось использовать Qt в Visual Studio (обсуждение необходимости данной меры выходит за рамки этого топика).
Последний раз, собирать Qt в Visual Studio мне приходилось 2 года назад, еще с версией 4.7.3 и, честно сказать, положительный эмоций от этой сборки у меня осталось мало не осталось. Как сейчас помню, необходимо было, минут 10-15 конфигурировать исходники Qt, а дальше в работу вступал jom, а работа его длилась ~3-4 часа (на моем Core i5-2430M). Только после сих деяний можно было писать на Qt в студии.
Перспектива повторения этих операций меня не радовала. Прочитав на хабре пару статей о попытках сборки Qt в Visual Studio выяснил, что теперь дела обстоят еще печальнее, для сборки необходимы: ActivePerl, Python, Ruby, ICU, плюс ко всему, весь процесс сборки теперь длится в разы дольше:
Сборка проекта | #25 — Курс по C++ для начинающих
nmake собирал qtwebkit уже часов 8 к ряду. Сейчас прошло уже более суток с момента последнего запуска nmake
С грустной миной на лице, с осознанием всего наваливающегося груза, я поставил на скачивание исходники, перл и т.д. Без надежды на успех, решил попробовать подключить библиотеки Qt к Visual Studio так, как это делается с некоторыми библиотеками для использования WinAPI и, я долго не мог поверить, но — получилось! А теперь обо всем по порядку и подробней (хотя подробно даже нечего описывать, все весьма просто и думаю, что я отнюдь не первый, кто до этого додумался).
Предполагается, что Вы имеете уже установленные:
- Microsoft Visual Studio 2010/2012
- Qt5 msvc2010/2012
Шаг 1: Настройка окружения
Допустим, при установке Qt, вы выбрали путь: «C:Qt», в таком случае, в этой папке у вас будут созданы папки 5.0.2, Licenses и т.д.
Устанавливаем следующие переменные окружения:
QTDIR = C:Qt5.0.2msvc2010 QMAKESPEC = win32-msvc2010
В переменную PATH добавляем путь: C:Qt5.0.2msvc2010bin
Рекомендуется перезагрузить компьютер после сделанных изменений (в Windows же все-таки работаем, ребят)
Шаг 2: Visual Studio Add-In
Далее просто скачиваем Visual Studio Add-in for Qt5 (не работает с Express Edition) и устанавливаем в любую папку, местонахождение студии будет определено автоматически. Я установил в C:QtQt5VSAddin.
Шаг 3: Использование Qt в VS
Да, именно использование! Уже на третьем шаге, без ручных сборок и т.д. Если Вы все правильно сделали (а что можно было сделать неправильно?), в Visual Studio появится вкладка Qt5, где версия Qt должна определиться автоматически, если этого не произошло, было неправильно настроено окружение и необходимо вручную указать путь к qmake (а лучше все-таки корректно настроить окружение, ибо без него скорее всего собираться проект не будет).
Компилирование всех файлов проекта в один EXE | Wpf
Создаем проект Qt5 (можно открыть имеющийся *.pro-файл, через меню Qt5). Пишем всеми любимый «Hello, World!»:
#include #include int main(int argc, char *argv[]) < QApplication app(argc, argv); QLabel *label = new QLabel(«Hello world!»); label->show(); return app.exec(); >
Если попробовать собрать данный проект, в момент линковки возникнут ошибки в виде «ссылок на неразрешенные внешние элементы». Чтобы это исправить надо, между директивами #include и функцией main добавить еще одну директиву:
#pragma comment(lib, «Qt5Widgets.lib»)
В последствии, от добавления этой препроцессорной директивы (нужно будет добавлять еще Qt5Core, Qt5Gui и т.д.) можно избавиться простой настройкой свойств проекта, т.е. добавить в дополнительные каталоги включаемых файлов:
$(QTDIR)include;$(QTDIR)includeQtCore;$(QTDIR)includeQtGui;$(QTDIR)includeQtWidgets и т.д.
В дополнительные каталоги библиотек:
$(QTDIR)lib
Ну и соответственно, в зависимости:
qtmain.lib;Qt5Core.lib;Qt5Gui.lib;Qt5Widgets.lib и т.д.
P.S. Надеюсь, что найдутся люди, для которых данная статься окажется-таки полезной
P.S.S Возможно, есть некий смысл именно собирать Qt из исходников под Visual Studio, если так, то приношу глубочайшие извинения. Мне пока что явная сборка не понадобилась, при такой интеграции Qt в Visual Studio был успешно написан уже один большой проект, который, ко всему прочему, использует ICE (с которым тоже долго возились в плане сборки, в итоге нормально работать с ним получилось только в студии, собственно, это и есть та необходимость интеграции Qt в студию, о которой говорилось в самом начале).
Запись опубликована автором admin в рубрике . Добавьте в закладки постоянную ссылку.
Один комментарий к “ Как подружить Qt5 с Visual Studio за 5 минут ”
SaZ говорит 26.06.2013 в 2:12 пп :
Странные у вас проблемы. Если вам не нужно самому собирать qt — то зачем столько траха со сборкой проекта? Качаете готовый дистрибутив qt под вашу студию, ставите addin — и вперёд, безо всяких свистоплясок с прагмами.
Источник: savepearlharbor.com
Компиляция и сборка в Visual Studio
Область применения:
Visual Studio
Visual Studio для Mac Visual Studio Code
Начальные сведения о сборке в IDE см. в разделе Пошаговое руководство. Построение приложения.
Сборку приложения можно выполнять с помощью интегрированной среды разработки Visual Studio, программ командной строки MSBuild и Azure Pipelines:
| IDE | — Немедленное создание сборок и тестирование их в отладчике. — Запуск многопроцессорных сборок для проектов C++ и C#. — Настройка различных аспектов системы сборки. |
| CMake | — Создание проектов C++ с помощью средства CMake – Использование одной и той же системы сборки на платформах Linux и Windows. |
| Командная строка MSBuild | — Сборка проектов без установки Visual Studio. — Запуск многопроцессорных сборок для всех типов проектов. — Настройка большинства аспектов системы сборки. |
| Azure Pipelines | — Автоматизация процесса сборки в рамках конвейера непрерывной интеграции или поставки. — Применение автоматических тестов для каждой сборки. — Использование практически неограниченных облачных ресурсов для процессов сборки. — Возможность изменения рабочего процесса сборки и создания процедур сборки с подробно настраиваемыми задачами. |
В этом разделе подробно рассматривается сборка на основе IDE. Дополнительные сведения о других методах см. в разделах CMakeMSBuild и Azure Pipelines соответственно.
Этот раздел относится к Visual Studio в Windows. Информацию о Visual Studio для Mac см. в статье Компиляция и сборка в Visual Studio для Mac.
Общие сведения о сборке из IDE
При создании проекта среда Visual Studio создает для него конфигурации сборки по умолчанию, а также содержащее проект решение. Эти конфигурации определяют, как выполняется сборка и развертывание решений и проектов. В частности, используются уникальные конфигурации проектов для разных целевых платформ (например, Windows или Linux) и типов сборки (например, отладка или выпуск). Вы можете как угодно изменять эти конфигурации и при необходимости создавать свои собственные.
Начальные сведения о сборке в IDE см. в разделе Пошаговое руководство. Построение приложения.
После этого вы можете познакомиться с другими задачами:
- Общие сведения о конфигурациях построения
- Настройка проектов для целевых платформ
- Управление свойствами проектов и решений
- Назначение событий построения в C# и Visual Basic
- Задание параметров сборок
- Параллельная сборка нескольких проектов
См. также раздел
- Сборка (компиляция) проектов веб-узлов
- Компиляция и сборка (Visual Studio для Mac)
- Проекты CMake в Visual Studio.
Источник: learn.microsoft.com
Структурирование проектов и решений в Microsoft Visual Studio Team System
В данной статье описываются различные варианты структурирования файлов решений и проектов Visual Studio, подходящие для коллективной разработки. Для группировки взаимосвязанных файлов проектов (.csproj и .vbproj) Visual Studio использует файлы решений (.sln). Выбор структуры проектов и решений очень важен, поскольку имеет ряд последствий. Например, он влияет на то, насколько легко члены групп разработки смогут извлекать и размещать решения и проекты в системе контроля версий, на механизм, используемый для описания зависимостей, а также на процессы сборки.
Все файлы небольшого проекта можно поместить в одно решение. При работе над большой системой для группировки взаимосвязанных проектов, соответствующих разным подмножествам функциональных возможностей основного проекта, используется несколько файлов решений. В зависимости от конкретного сценария, может также возникнуть необходимость сгруппировать все файлы проектов в один файл решения.
Стратегии структурирования решений и проектов
Чаще всего используются три стратегии структурирования файлов решений и проектов:
- Одиночное решение. При разработке небольшой системы, создается одиночное решение, в котором размещаются все проекты.
- Сегментированное решение. При разработке большой системы взаимосвязанные проекты группируются в разные решения. Для каждой логической группы проектов, с которой разработчик, вероятнее всего, будет работать как с совокупностью, создается отдельное решение. Затем все эти решения объединяются в одно главное решение, которое будет содержать все проекты. При таком подходе сокращается количество данных, извлекаемых из системы контроля версий, поскольку работа ведется только над определенными проектами.
- Несколько решений. При создании очень большой системы, требующей десятков и более проектов, следует работать с подсистемами. Для отображения зависимостей и из соображений производительности не нужно создавать главное решение, содержащее все проекты.
В общем, следует:
- Использовать стратегию одиночного решения, если размер получаемого в результате решения не слишком велик и не приводит к проблемам загрузки в Visual Studio.
- Использовать несколько решений для создания отдельных представлений подсистем приложения.
- Использовать несколько решений для сокращения времени загрузки решения и сокращения времени сборки для разработчиков.
- Каждый проект во время компиляции создает отдельную сборку (assembly). Начните с определения того, какие сборки потребуется создать, и затем, исходя
- из этого, принимайте решение о необходимых проектах. На основании этого распределите код по проектам.
- Начинайте с самой простой структуры одиночного решения. Усложняйте структуру только в том случае, когда это действительно необходимо.
- При проектировании структуры с множеством решений:
- Рассмотрите зависимости проекта. Попытайтесь сгруппировать взаимосвязанные проекты в одно решение. Это позволит использовать в решении ссылки на проекты, а не на файлы, что обеспечивает возможность Visual Studio синхронизировать конфигурации сборки (отладка/ версия для выпуска) и, отслеживая версии, определять, когда необходимо повторно собрать проект. Пытайтесь свести к минимуму количество перекрестных ссылок на проекты между решениями.
- Рассмотрите возможность совместного использования исходного кода. Поместите проекты, использующие один и тот же исходный код, в одно решение.
- Учтите структуру группы. Решения должны быть структурированы таким образом, чтобы упростить группам работу с набором взаимосвязанных проектов.
Одиночное решение
При работе над небольшой системой рекомендуется размещать все проекты в одном решении Visual Studio. Такая структура упрощает разработку, потому что при открытии решения доступен весь исходный код. При такой стратегии также очень легко работать со ссылками, потому что все они являются ссылками на проекты одного решения.
Но все-таки, возможно, придется использовать ссылки на файлы сборок сторонних производителей, например на купленные компоненты, находящиеся вне решения. На рис. 3.1. показан подход с использованием одиночного решения.
Рис. 3.1 Подход с использованием одиночного решения
- Простые сценарии сборки.
- В рамках решения можно без труда отображать зависимости между проектами.
Сегментированное решение
При работе над большой системой рекомендуется использовать несколько решений, каждое из которых будет представлять некую подсистему приложения. Разработчики могут использовать эти решения и работать над отдельными небольшими частями системы, в этом случае им не придется загружать код всех проектов.
Структура решения должна быть спроектирована таким образом, чтобы все взаимосвязанные проекты располагались в одной группе. Это позволит использовать ссылки на проекты, а не на файлы. Также можно создать один файл главного решения, содержащий все проекты. Этот файл используется для сборки всего приложения.
Примечание: В отличие от предыдущих версий, Visual Studio 2005 полагается в сборке проектов на MSBuild. Начиная с Visual Studio 2005, появилась возможность создавать структуры решений, не включающие в себя все проекты, на которые имеются ссылки, и такие решения все равно будут собираться без ошибок.
Поскольку главное решение собирается первым, формируя результирующие двоичные файлы каждого проекта, MSBuild может прослеживать ссылки на проекты вне границ решения и успешно выполнять сборку. Но это возможно только в случае использования ссылок на проекты, а не ссылок на файлы.
Созданные таким образом решения можно успешно собирать из командной строки Visual Studio и из IDE, но не с помощью Team Build. Чтобы успешно создать сборку с помощью Team Build, необходимо использовать главное решение, включающее все проекты и зависимости. На рис. 3.2 показан подход с использованием сегментированного решения.
Рис. 3.2 Подход с использованием сегментированного решения
При работе с несколькими решениями все проекты должны иметь плоскую структуру. Типичный пример – приложение, включающее проект Microsoft Windows® Forms, проект ASP.NET, службу Windows и ряд библиотек классов, которые совместно используются некоторыми или всеми перечисленными проектами. Для всех проектов может использоваться следующая плоская структура: /Source /WinFormsProject /WebProject
/Source
/WinFormsProject
/WebProject
/WindowsServiceProject
/ClassLibrary1
/ClassLibrary2
/ClassLibrary3
Web.sln
Service.sln
All.sln
Плоская структура обеспечивает большую гибкость и возможность использования решения для создания разных представлений проектов. Физическую структуру каталогов решения менять очень трудно, особенно если используется библиотека классов из другого решения.
Основания использования этой структуры:
- Повышение производительности при загрузке и сборке составляющих решений.
- Возможность использования составляющих решений для создания представлений наборов проектов, созданных определенной подгруппой, или на основании границ совместного использования кода.
- Возможность использования главного решения для сборки всего приложения.
- Возможность без труда отображать зависимости между проектами в каждом составляющем решении.
- Упрощение системы в целом, если решения выделены логично. Например, если решение выделено соответственно технологическим или функциональным характеристикам, новым разработчикам намного проще понять, над каким из решений работать.
Основная причина не использовать эту структуру:
- Повышение затрат на обслуживание решения. Введение нового проекта может повлечь за собой изменение файлов многих решений.
Несколько решений
При работе над очень большим решением, включающим десятки проектов, может возникнуть проблема с масштабируемостью решения. При таком сценарии следует разбить приложение на несколько решений, но при этом не создавать главного решения для всего приложения, потому что все ссылки внутри решений являются ссылками на проекты. Ссылки на проекты вне решений (например, на библиотеки сторонних производителей или проекты из другого составляющего решения) – это ссылки на файлы, т.е. без «главного» решения можно обойтись.
Вместо главного решения необходимо использовать сценарий, который понимает порядок сборки решений. Одна из главных задач при обслуживании структуры с несколькими решениями – гарантировать невозможность создания циклических ссылок между решениями. Эта структура требует сложных сценариев сборки и явного отображения зависимостей.
При такой структуре невозможно создать сборку всего приложения в Visual Studio. Это делается непосредственно из TFS Team Build или MSBuild. На рис. 3.3 показан подход с использованием нескольких решений.
Рис. 3.3 Подход с использованием нескольких решений
Такая структура должна использоваться для очень больших приложений. Она поможет решить проблемы с производительностью и масштабируемостью Visual Studio IDE.
Одна из причин не использовать эту структуру – необходимость в сложном сценарии сборки, обеспечивающем обработку зависимостей составляющих решений через сборку решений в правильном порядке.
Рекомендации по работе над большим проектом
Большим группам разработки, в отличие от малых, присущи следующие черты:
- Им нужна более сложная структура ветвления и слияния.
- Для них более высока вероятность работы с зависимостями между решениями и групповыми проектами.
- Для них более высока вероятность работы с несколькими сценариями сборки для компонентов и групп.
Сегментированное решение прекрасно подходит для большинства крупных проектов, потому что обеспечивает гибкость решения, и при этом предоставляет одно решение, которое может использоваться для сборки приложения. Для достаточно больших приложений, которые приводят к достижению пределов масштабируемости, должны использоваться несколько решений.
Заключение
Для небольших проектов, в которых не требуется разделять исходный код на отдельные составляющие решения, используется одиночное решение. Сегментированное решение используется для логической группировки подмножеств проектов, которые разработчики, вероятнее всего, будут изменять совместно. При этом создается одно главное решение, содержащее все проекты. Для создания определенных представлений подсистем и сокращения времени загрузки и сборки приложения используется несколько решений. Сегментированное решение отлично подходит для большинства больших проектов, потому что обеспечивает гибкость решения и при этом предоставляет одно решение, которое может использоваться для сборки приложения.
Источник: www.cyberguru.ru