Qt x64|x86 msys2

Всем привет

Понадобились мне разные версии Qt (собранный разными компиляторами и разной битности) под Винду.
На сайте Qt Отправили в MSYS2.
Вообщем установил MSYS2 (msys2.github.io)
Доставил в MSYS2:
pacman -S mingw-w64-x86_64-qt-creator
pacman -S gcc
pacman -S gdb
pacman -S cmake
pacman -S make

Запускаю QtCreator из MSYS2 шела. В настройках QtCreator все находится (весь кит, как положено и на ожидаемых местах).
Но при попытке собрать проект из CMakeList.txt
получаю следующее:
CMake Error: Could not create named generator CodeBlocks — MinGW Makefiles

Подскажите, где и что еще прописать? Почему QtCreator пытается запустить cmake -G «CodeBlocks — MinGW Makefiles», а не «Unix Makefiles»?

P.S. Решил MSYS2, потому как там много либ нужных мне уже собрано. Надоело каждую ручками под винду собирать и разбираться, что и почему не собирается.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
mingw x86_64 Qt не собирается. Получается, что не просто так у них на сайте нет сборки соответсвующей.
а есть ли дистрибьютивы винды конкретно x86_64?
просто я насколько помню видел (на торрентах) тока х86 и х64 релизы (и сборки) винды, либо сборки, где можно с одного диска установить либо 32-битную винду (х86), либо 64-битную (х64). А сборок винды конкретно х86_64 не помню чтобы видел (видел вроде тока линуксовые дистрибьютивы x86_64)...

ну судя по википедии ru.wikipedia.org/wiki/X86-64 это таки винда x64 и для 64-битной QT наверное и есть только пресловутое

Нашел вот это пока Qt64-NG (PROJECT CLOSED!) sourceforge.net/projects/qt64ng
Nixman и компания забили на сборки Qt.

а так про винду х64 я знаю) Просто у меня закралось подозрение, что 64-битные версии винды могут просто не поддерживать какие-то возможности (команды или что-то еще системное) mingw x86_64 (т.е. mingw 86_64 может быть не полностью совместимо с 64-битной виндой)...

Под виндой QT x64, получается, возможно только студией собрать.
я видел, что некоторый опенсорс рекомендуют под виндой из студии собирать (хотя возможно это больше сугубо виндового опесорc-софта касается)
Это с какого бодуна, если это и есть порт gcc под винду.
хз. в некоторых репозиториях на гитхабе такое видел. может это больше для тех, кто юзает студио для сборки софта под винду (или конкретная сорфтина писалась на студии)...
Смущает там только одно: (PROJECT CLOSED!)
может финансирования на данный проект не хватало и его решили прикрыть (может временно?).
А так — может найдутся энтузиасты или еще кто, кто решит поддерживать и развивать этот проект.
Что именно.
да я не запоминал какие проекты — вроде какие-то не шибко известные. Да и я в основном ищу уже готовые сборки под винду (хотя редко такое надо, основной набор своего опенсорс-софта уже есть), а на линуксе беру нужный софт из репозитория.
Просто код нужно писать на том подмножестве языка, что поддерживается одинаково обоими компиляторами и все прекрасно собирается и там и там.
полностью согласен.
Вот сейчас один проект, основная разработка идет в Линухе 64 битном, а я под Виндой 32 бит собираю и разработываю. Заодно пофиксились несколько багов режимах 32 и 64 бит.
респект!) у самого линух 64 и 32-битная 7-ка. Если мне когда-нибудь понадобиться что-то разрабатывать из десктопа (сам пока веб, но есть и пара идей для дектопного софта, которые может попробую реализовать как-нибудь) — приму этот подход на вооружение)

погоди, я ведь собираю mingw и 32 и 64. Та жэ история с cl.

Какой такой msys2?

Ставим MinGW из sourceforge.net/projects/mingw-w64
Ставит сразу для x32/x64
Модель исключений (я выбираю seh)
Модель потоков выбираем по вкусу (я выбираю НЕ POSIX (не вспомню сейчас что там еще есть))

Дале, идём в установленный mingw и пишем для удобства там такой батник (для x32 и x64):
[code]
echo off
set PATH=V:\mingw-gcc-x32-dwarf-x64-seh\x32\mingw32\bin;%PATH%
rem echo %PATH%
rem cd «V:\mingw-gcc-x32-dwarf-x64-seh\x32\mingw32\bin»
cd «C:\»
«C:\Windows\system32\cmd.exe»
[/code]

V:\mingw-gcc-x32-dwarf-x64-seh\x32\mingw32\ <- что б понятно было это где у меня стоит 32 битный mingw

Качаем исходники Qt download.qt.io/archive/qt

Распаковываем. Тут я еще применяю пару патчей для qmake и qtbase, приходилось кое что фиксить, потому как практика общения с разработчиками говорит что если ты левый Вася а не их клиент то смысла в общении и багрепортах = 0, так что я просто экономлю себе время.

Запускаем батник который мы написали выше.
Идём в папку с распаковынными сырками Qt и конфигурируем:

configure.bat -prefix %CD%\qtbase -opensource -debug-and-release -no-icu -no-accessibility -nomake examples -nomake tests -no-cetest -opengl desktop

Я собираю без accessibility, т.к. тесты профйлером показали что именно из за этой поддержки тормозит UI когда на нём слишком много виджетов. Если интересно могу найти свой пост на RSDN.

После конфигурации: mingw32-make -j16
Параметр -jX по вкусу, у меня машинка с легкостью позволяет 16. Собирается все очень быстро.

Для собрки студией просто запускаем командную строку из тулов типа
Visual Studio Command Prompt (2010) или такую же только для x64

Строка для конфигурирования та же.

Сборка:
set CL=/MP
nmake

Да.. Потмо просто ставим Qt Сreator и в Tools->Options->Build&Run->Qt Versions
Добавляем собранную библиотеку. Если нужны подробности распишу как.

Да прости пожалуйста. Совсем из головы вылетело. Python и Perl нужен, а вот ruby наверно нет, по крайней мере у меня его точно нет и все собирается.
Версии если что у меня такие:
Python 2.7.9
This is perl 5, version 16, subversion 3 (v5.16.3) built for MSWin32-x64-multi-thread
(with 1 registered patch, see perl -V for more detail)

На вопрос о железке: i7 5960X, про веник не понял вопроса.

Сложно тут сказать. Я его кроме как для соборки Qt нигде не использую, так что ставил по их рекомендации (постараюсь найти линку на эту страницу, с переездом на qt.io они много чего поперемещали). Но ты попробуй думаю что должно получиться.

Да RAM 64, ну и RAM диск для временных файлов.
В Windows положил такой файл hstart.vbs (что бы прятало консоль):
{code}
If WScript.Arguments.Count >= 1 Then
ReDim arr(WScript.Arguments.Count-1)
For i = 0 To WScript.Arguments.Count-1
Arg = WScript.Arguments(i)
If InStr(Arg, " “) > 0 Then Arg = ”""" & Arg & """"
arr(i) = Arg
Next

RunCmd = Join(arr)
CreateObject("Wscript.Shell").Run RunCmd, 0, True
End If
{code}

Для студий, в том числе и qtCreator написал батники:
{code}
set TEMP=T:\TEMP
set TMP=T:\TEMP
V:\Qt\QtCreator\bin\qtcreator.exe
{code}
T — это RAM диск.

Запуск соответвенно:
hstart.vbs qtcreator.bat

А вот видик вполне обычный GTX 460

А что ты считаешь на GPU, очень интересно?
Сам все хочу CUDA попробовать вот только пока добраться не могу.

CMakeList.txt
Это убожество на уровне автотулов. Геморрой ещё тот. Особенно с кросс-компиляцией.
Но пока из всех что я видел Сmake наиболее удобен, если нужно собирать под разными осями и разной битностью.
Это если за тебя всё сделали и тебе нужно только запустить cmake — то тогда, да, великолепная тулза.
А автотулы еще и запусти под виндой попробуй.
под mingw или cygwin они всегда запускались.
Ну и если обычно Cmake не очень сложно писать, если писать аккуратно.
Чем кросс-платформенней проект, тем CMakeList.txt больше и толще :)

Всё оказалось намного хуже.

1) У меня mingw — это часть cygwin, т.е. по сути шел и прочие шли от cygwin’а.
2) Стоит QNX Development IDE, которая имеет собственную сборку гнушных утилит (правда не первой свежести, но сойдёт).

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

По поводу пункта 1). У винды очень большие проблемы со скоростью создания процессов, в отличие от юникс-подобных ОС, из-за этого сборка больших проблем может быть тормознутая, когда создание процесса занимает по времени больше, чем компиляция файла. У cygwin есть хорошая эмуляция некоторых вещей в отличие от msys, где попытались сделать нативный порт и часто он работает заметно быстрее при компиляции.

Интересно, Linux мир когда-нибудь уйдет от этой дикой древности — автотулов.

Никогда, но их и не нужно применять за пределами своей целевой ниши.
Autotools предназначены для конфигурирования и сборки базового приходящего софта в обстановке, когда ещё нет почти ничего из нормальной рабочей обстановки. Именно поэтому там выходной результат — один толстенный sh-скрипт и выходные мэйкфайлы, которые пользуются только позиксовой базой и никакими расширениями.
То есть с их помощью надо ставить собственно binutils, gcc, gmake, cmake и прочую базу.
Использование autotools за пределами этой базы — не обязательно, а для массы целевого юзерского софта они уже просто неудобны и слово «нельзя» чем дальше, тем актуальнее.
Честно говоря, не понимаю, где ты нашёл autotools для Qt — у него свой комплект инструментов сборки, начиная с qmake. Может, это специфика сборки под винду, но я тогда не понимаю, зачем такое было нужно...

По барабану. Это же не средства разработки и не базовые системные утилиты.

На оф. сайте есть собранная vs2013 64.

А гугл что говорит по поводу этой ошибки?
P.S. Под винду есть pacman?

stackoverflow.com/...ke-make-program-not-found вот тут несколько возможных решений

По поводу ошибки System is unknown to cmake stackoverflow.com/...ystem-is-unknown-to-cmake
По поводу варнингов

Use the cmake_policy command to set the policy and suppress this
warning.
может стоит изменить политику?
По поводу генераторов не уверен, но стоит попробовать Unix Makefiles в виду использования пакмена.

Підписатись на коментарі