Russian Qt Forum

Делал проект на Qt 5.2.0, MinGW 4.8.1, Cmake 2.8 (Windows XP). Изначально ставил CMake, потом MinGW, потом Qt. MinGW отдельно ставился, потому что до этого стояла старая версия со старым Qt, с ней проект не импортировался. Уже не помню точно, были какие-то мелкие нюансы, но все как-то практически сразу работало, особых проблем не встретил. Сейчас надо клонировать этот же проект, причем только исходники и сам проект, на голую Win7. А также написать документацию, чтобы потом при необходимости кто-то другой смог проект установить на другую машину с 0. Ставлю на W7 в том же порядке - CMake, MinGW, Qt. В проекте есть только CMakeLists.txt, он импортируется, проект в QtCreator открылся. Нажимаю собрать и получаю сообщение об ошибке в системном инклюде - нет файла wdm.h в ntddk.h. Смотрю - ntddk.h и прочие системные .h берутся из каталога ....mingw32\include, который вложен в установку Qt. А в проекте, который у меня собирается и работает уже давно, они берутся из каталога, который вложен в место установки MinGW. Смотрю настройки проектов, маршруты и т.д. и не вижу разницу - вроде всё одинаково в обоих случаях. Бьюсь уже полдня и не могу найти - где расходятся настройки, почему инклюды в первом случае берутся из одного места, во втором из другого, и главное не понятно - почему в обоих случаях (вложенный в Qt и отдельно установленный) используется MinGW x32 v4.8.1, но системные инклюды в них совершенно разные, даже написаны разными людьми.

Где я прозевал настройки?

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

PS по-моему ntddk является частью Windows DDK. Но тут minGw, а по нему я не знаю :)

Так я в QtCreator вижу - ntddk в рабочем проекте берется из C:\mingw\include\ddk, а в новом из C:/qt/qt5.2.0/tools/mingw48_32/i686-w64-mingw32/include/ddk. Но нигде не могу найти, где эти каталоги заданы, и почему именно такие у них маршруты.

Эмм.. переменные окружения посмотрите - я так понимаю это винда :)
Так же пути могут быть заданы в pro файле в секции INCLUDE += вроде.

В чем проблема то ? В том что файла нет, или что файл по пути есть, но креатор его не видит?

переменные окружения все в порядке, в них маршруты не задаются, кроме одного - умолчательный маршрут к бинарникам mingw в PATH, он у меня в обоих случаях одинаковый, и показывает на отдельную установку mingw

файла .pro нет в проекте вообще, есть CMakeLists.txt, в нем тоже маршруты к инклюдам mingw нигде не заданы, и разумеется, раз это клон проекта, то CMakeLists.txt точно такой же

проблема в том, что клон проекта не компилируется, выдает ошибки в системных инклюдах, в клоне они почему-то берутся не из того места, откуда должны

вписал в CMakeLists.txt клона явно указание где еще можно брать инклюды

include_directories("C:/mingw/include")

получил толпу ошибок в системных инклюдах, которые тащятся из c:\qt\qt5.2.0\tools\mingw48_32\i686-w64-mingw32\include

ПОЧЕМУ в комплект с Qt включены одни системные инклюды MinGW, а в отдельную поставку MinGW той же версии - совершенно другие, несовместимые??? это саботаж такой????  ???

Эмм.. Удалил недавно Qt 5.2+ не могу проверить, но там насколько я помню тоже не было ntddk.

В Qt (я не совсем понимаю CMAKE, но он по-моему парсит pro файлы Qt) видимо прописаны пути поиска для стандартного minGw, нне?

PS пробуйте, устанавливайте только нужный вам minGw, сносите идущий с Qt. Тут уже вступает в дело шаманство. У меня недавно вон собрался проект с зависимостью от древних библиотек, которые тихо мирно прятались. На другом компе конечно же не собралось бы :D

в коде приложения есть строка

#include <ddk/ntddpar.h>

и в работающем проекте, и в клоне это ссылка на c:\mingw\include\ddk\ntddpar.h

открываю этот файл в обоих проектах - он одинаковый, в нем есть строка

#include "ntddk.h"

в работающем проекте она ссылается на c:\mingw\include\ddk\ntddk.h
в неработающем на c:\qt\qt5.2.0\tools\mingw48_32\i686-w64-mingw32\include\ddk\ntddk.h

и эти файлы уже разные...

- хотя файл c:\mingw\include\ddk\ntddk.h ТОЖЕ СУЩЕСТВУЕТ - ну ладно бы его не было, нашло по маршруту одноименный в другом каталоге, но он есть, и порядок просмотра маршрутов тоже ни при чем - в каталоге c:\qt\qt5.2.0\tools\mingw48_32\i686-w64-mingw32\include\ddk есть и файл ntddpar.h, однако он был открыт из маршрута c:\mingw\include\ddk

где, в какой момент, почему поменялся маршрут  ???
ну да, я вижу, что во втором случае двойные кавычки у ntddk.h, но это "текущий" файл не для всего проекта, а для файла ntddpar.h, значит он должен браться в том же каталоге - но нет, и он берется непонятно по какому принципу

и вообще где порядок перебора маршрутов в QtCreator задается - никак не могу найти...  >:(

нет, нифига... проект приложения изначально был сделан на CMake/GNU, там никакого Qt в помине не было, Qt уже я потом подшил, но сначала импортировал и собрал приложение без использования Qt в QtCreator

а Qt подшивается в отдельной библиотеке, которая вообще собирается отдельным проектом, и уже её .dll указана в проекте CMake, и грузится эта библиотека при старте приложения - то есть, маршруты проекта, который использует Qt, никак с маршрутами проекта CMake не связаны

CMake при запуске какой MinGW toolchain находит, если из консоли запускать без всяких QtCreator?

если просто запустить cmake CMakeLists.txt то начинает генерить для Visual Studio 2005, которая тоже есть на целевой машине

при запуске с ключом -G "MinGW Makefiles" ругается, что не найден RC компилятор, просит установить переменную среды CMAKE_RC_COMPILER

я так понимаю, это к виндозным ресурсам - но при чем тут они, если они в проекте вообще не используются, и вообще никаких ресурсов в приложении, собираемом с помощью CMake нет и в помине, оно глухо консольное и мультиплатформенное

Хех... установил на еще одну голую машину (на самом деле, всё это проделывается в виртуалках, то есть, число голых машин не ограничено) всё тоже самое, но Qt ставил без встроенного MinGW.

И исходники главного приложения откомпилировались... Правда, там есть косяк какой-то в отдельном MinGW, ошибка в хидере wchar.h, почему-то нет типа intptr_t. Лечится добавкой typdef int intptr_t; после чего всё компиляется. Но сборка приложения не проходит - нет моей библиотеки, которая использует Qt. Но её и не может быть - нет ведь встроенного MinGW, который для компиляции с Qt используется.

Вот ведь намутили с этими MinGW в Qt! Два совершенно разных, хотя одной и той же версии.

В понедельник попробую еще раз установить Qt с MinGW после отдельного MinGW, и внимательно настроить использование комплектов в креаторе. Похоже, проблема именно в этом - тщательно надо настраивать использование MinGW, поскольку для основного приложения используется отдельный, встроенным в Qt оно не компилируется. А для библиотеки с Qt, наоборот, используется встроенный, отдельным она не компилируется. Как-то это всё у меня при первом разе на автомате получилось правильно полгода назад, но сейчас повторить пока не удалось.

Qt компилируется любым. Просто тот, который идёт с ним проверен разработчиками :)

Ну не буду же я из-за библиотеки в 2000 строк перекомпилировать весь Qt отдельным MinGW...

При открытии проекта библиотеки в его настройках такая надпись: Отсутствуют подходящие комплекты. При этом отдельный MinGW в списке комплектов, разумеется, есть.

В общем, всё получилось, внимательно надо только было настроить использование компиляторов: для сборки всего приложения использовать отдельно установленный MinGW, а для сборки моей библиотеки MinGW из комплекта Qt. Почему-то после установки Qt в настройках комплекта Desktop Qt ... MinGW поле sysroot оказалось пустое, и для библиотеки по-умолчанию qmake не запускался.

Теперь всё это придется повторить и описать по шагам, а то достанется это когда-нибудь отмороженному виндузятнику, он же ничего вообще сделать не сможет...

И блин, не получается повторить... после установки Qt и MinGW в любом порядке в мастере запуска CMake, в поле Генератор есть только генератор для конфигурации MinGW из Desktop Qt 5.2.0.  >:( Получилось один раз наверно только потому, что я сначала ставил Qt без встроенного MinGW, а потом еще раз устанавливал уже со встроенным. Но это уже шаманство, непредсказуемо и не гарантировано, что повторится.

Вот же блин горелый...  :-\

КАК ЗАСТАВИТЬ QtCreator НАЙТИ ГЕНЕРАТОР ДЛЯ CMake ИЗ ОТДЕЛЬНО УСТАНОВЛЕННОГО MinGW???

Колдыбался, колдыбался и плюнул. Похоже на баг QtCreator. Если ставить Qt без встроенного MinGW, но поставить MinGW отдельно, то Creator его генератор для CMake успешно находит. От порядка установки не зависит. Но если поставить Qt со встроенным MinGW, то генератор для CMake из комплекта отдельно установленного MinGW пропадает напрочь. Везде оба MinGW видны, кроме этого места. Чтобы не заставлять последователей заниматься шаманством и ставить Qt сначала без MinGW, генерить CMake, потом сносить Qt (тоже блин радость - поверх установленного он не умеет ставиться, то есть, repair сделать нельзя), потом ставить уже со встроенным... проделал всё сам и кладу в комплект исходников каталог <project>-build с нагенеренными файлами для CMake. Так всё работает, поскольку ничего генерить не надо.

Но... неправильно это, костыль. Написать что-ли баг репорт в Digia...

Я думаю там проблема с подхватываемыми настройками. Сам пару раз ох.. удивлялся когда собиралось из консоли то с одной, то с второй, то с третьей версией Qt :D