Russian Qt Forum

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

make -k all
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
Incorrect command line argument: -k

Syntax: MAKE [options ...] target
    ...
    -K                Keeps (does not erase) temporary files created by MAKE
    ...
Build complete for project test_2

При сборке вручную (make -k all) никаких проблем не возникает...

Доп.:     8)
1. Опция Build Automatically запускает процесс пересборки проекта перед каждым запуском ?
2. Читал, читал help, так и не понял до конца, чем отличается managed project от standart project... Тем, что в standart project нужно указывать готовый makefile, который будет использоваться для билдинга, а в managed project он создаётся командой make (в данном случае) в начале 1-го билдинга ?

А ты тот make используешь. Eclipse у тебя (судя по сообщению) пытается вызвать Borland'овский make, а тебе скорее всего нужен mingw32-make

Вот, млин, не заметил... Действительно вызывает Borland'овский...
У меня Qt'ные бинарники прописаны в локальных переменных среды. Добавил Qt'ный bin в глобальный path (на первое место) - ситуация повторилась (опять вызывает Borland'овский make). В то же время у меня в Qt'ном bin - батник (make.bat), вызывающий mingw32-make.
Напрашивается вывод, что Eclipse не дружит с bat-никами.
Ну ладно, прямо указал в свойствах проекта mingw32-make. Всё пошло...

Таким образом, вопрос:
1. Как Eclipse подружить с батниками ?

2.Что за странный managed project... Искал, где прописываются includ'ы - нигде нет. Создал standart project - появились соответствующие пункты в свойствах... Что - в managed project нельзя includ'ы прописывать ?

добавлено спустя 16 часов 36 минут:

 Впрочем, Include Paths & Symbols и Project Paths (для прописки includ'ов) для прописки Qt-ных исходников и не нужны (для Standart C++ Project). Поскольку в Standart Project makefile нужно создавать самому. А в makefile qmake'ового производства все Qt'ные include'ы прописаны. И Eclipse берёт все include-пути из этого makefile'а.
Сложнее дела обстоят с Managed Project (кто-нибудь объяснит, что это за загадочный проект такой, пока я не удавился !: ). Здесь makefile создаёт сам Eclipse (как и чем - непонятно...). И в этом makefile'е, естественно, никаких путей не прописано. Пытался прописывать пути и в Include Paths & Symbols, и в Project Paths - всё-равно не может найти Qt'ные либы. Видит их только у себя под носом - в одной папке с проектом.

добавлено спустя 7 часов 32 минуты:

 Страшная запарка с конфигурациями.
Создал debug-конфигурацию, указал exe'ник из каталога debug. При запуске Run->Debug выходит очень информативное сообщение:

Error creating session: Exec error:Launching failed

Сразу всё понятно стало...
Может быть, на вкладке Debugger этой конфигурации что-то не так:
Debugger: - ну, здесь, наверное, Cygwin GDB Debugger ставить надо, т.к. у меня MinGW стоит. (Другие варианты: GDB Debugger и GDB Server. Что это - неизвестно, в help'е ничего нет...)
Debugger Options:
   GDB Debugger - стоит gdb
   GDB command file - пусто (что это такое - опять неизвестно...)
Вот и вся вкладка Debugger.
В свойствах проекта текущая конфигурация - debug. В каталоге debug проекта exe'ник имеется.
В чём проблема - непонятно...

добавлено спустя 14 часов 29 минут:

 Тьфу, блин, совсем уже крыша едет. gdb то у меня не стоял...

1. Со Standart Project (это где makefiles создаёшь сам) такая проблема:
Создал проект, создал makefile'ы. В Eclipse сбилдил, получил дебажный и релизный exe'ники.
Дальше создаю run-конфигурацию. Указываю релизный exe'ник. В ответ получаю:
Program is not a recognized executable
Указываю дебажный exe'ник - то же самое.
И вообще никакие exe-ники не принимает...
С debug-конфигурацией то же самое.

С Managed Project таких проблем не возникало.

2. И вообще, неплохо было бы услышать совет тех, кто юзает Eclipse, по поводу того, с каким проектом лучше работать - Standart или Managed...
В Managed приходится вручную прописывать все Qt'ные пути.
В Standart приходится вручную создавать файл проекта и make-файлы после добавления/удаления файлов из проекта.

3. И как изменить ключи компиляции (для g++), указанные в свойствах проекта (Managed С++ Project). По умолчанию ставится: -O3 (-g3 для debug) -Wall -c -fmessage-length=0 и изменять их нельзя...

Я вот читаю и никак не могу понять, вы Qt проекты собираете в eclipe или обычные сишные.
Если Qt,  то зачем самому писать makefiles, если есть qmake? По поводу Qt проектов, можно поискать по форуму, здесь была тема как четверку прикрутить к eclipse без посторонней помощи (через maketargets), но это весьма неудобно. Я же пользуюсь плагином одного очень хорошего человека -> http://artis.imag.fr/~Xavier.Decoret/resources/qt/eclipse, он хоть и не слишком многофункционален, но очень сильно облегчает жизнь, да и вроде обещает дальнейшее развитие, советую попробовать.
Если же имеются ввиду обычные проекты, то конечно, проще пользоваться managed project, т.к.  сборкой тогда будет управлять, встроенный в eclipse, ant. Все настройки проекта в этом случае находятся в Project -> Properties, в т.ч. и пути к заголовочным файлам.


А вы считаете он сам за вас их додумывать будет. А потом почему все, одного вполне достаточно.  :D


Конечно, на то он и не managed.  :D


Гммммм. А вы когда нибудь здесь -> Project -> Properties бывали?


А вы уверены, что файлы реально создались, то есть, что сборка прошла без ошибок? Проверьте ручками.

Проекты - Qt'ные, а самостоятельное написание makefile'ов - садомазо (приятно с бодуна)

В общем то Qt4 прикрутил через maketargets. Всё работает - и автозавершение, и фолдинг. Тормоза, правда, нехилые, но стерпеть можно.
Так вот, чем это неудобно ?

include/QtGUI ?
Как насчёт QtNetwork, QtOpenGL и др.?

Теперь насчёт плагина. Что означает QMAKEFEATURES ?
И нужно ли вручную прописывать include'ы для плагина ?


Всё, ручками забубенил PE Windows Parser...

В Qt начиная с четвертой версии появилось два способа подключать заголовочные файлы:
1. #include<qapplication.h> или #include<Qt/qapplication.h> и тогда прописываете в IDE только путь %QTDIR%/include/Qt или %QTDIR%/include, соответственно.
2. #include<QtGUI/QApplication> и тогда прописываете в IDE только путь %QTDIR%/include.

Первый на данный момент считается deprecated, и реализован только для поддержки старого софта портируемого с Qt 3.x.x, так что лучше пользоваться вторым.


А это откуда?


Что значит "include'ы для плагина"? Всмыле для проекта? Конечно. Иначе откуда он их возьмет?

Ето плохой способ.


Префикс оставлен просто для разделения модулей оп отдельньІм папкам. Ето никак не означает, что так и нужно писать:



КлассьІ в Qt уникальньІ, никаких конфликтов внутри библиотеки нет и не будет. Правильно, как сказал Cyrax, прописьІвать пути ко всем модулям:



Есть множество вещей, которьІе должньІ бьІть реализуемьІ не на уровне исходного кода, а на уровне параметров компилляции. ДанньІй случай - один из них.

Хмммм. Возможно вы в чем-то и правы, но в любом случае это дело вкуса. Невижу чем этот способ плох. И не очень понимаю, почему это чуть ли не единственный вопрос, который так сильно волнует Cyrax-а.

1. QMAKEFEATURES - это в Preferences -> Qt. Что там указывать ?
2. Раз мы указываем плагину QTDIR (там же), почему бы ему самому не прописать Qt-header'ы... Или по принципу "только то, что надо"...
3. Как я понял, плагин не использует qmake для создания файла проекта...
Подсветки синтаксиса для файла проекта нет...

Ааааааа, вы об этом, как-то не обратил сразу на это внимание т.к. сам этим не пользуюсь (хотя может и зря). Это путь к каталогу содержащему так называемые users features. Подробнее о них смотрите в Assistant -> qmake Manual -> qmake Advanced Usage -> Adding New Configuration Features. В вашем случае можно туда вообще ничего не писать.  :D


Гммм. Ну допустим прописать пути к заголовочным файлам, в данном случае вы можете и в *.pro файле, и в IDE и займет это одну минуту. А потом какие всетаки пути нужно прописывать, откуда плагин это должен знать (%QTDIR%/QtGUI, %QTDIR%/QtNet, а может быть еще чего). Прописывать все пути не совсем правильный (ИМХО) путь, т.к. они, может, вам и не нужны вовсе. А вообще это вопрос к автору плагина. Кстати, вижуальный интегратор пути к инклюдам и либам сам тоже не прописывает.


При создании проекта, создается простенький шаблонный *.pro файл, который является основой для buildera, т.е. при дальнейшей разработке проекта от вас требуется только подправлять данный файл в соответствии с внесенными в проект изменениями. На мой взгляд это разумный компромис.



(а это тогда что -> Preferences -> Qt->QMake Editor?) Есть. Мало того, он (плагин) следит за изменением этого файла и сам вызывает qmake при его сохранении.

1. Не работает фолдинг в Qt-проекте (в других работает). Что это - глюк ?

2. Файл проекта запускается только в Text Editor. При попытке запустить его в QMake editor - появляется пустая вкладка "QMake editor". При этом, при открытии двойным кликом, выходит сообщение:

An error has occured. See error log for more details.

(подсветки, естественно, никакой не будет, пока глюк не будет профиксен (если это глюк)...)

3. Плагин не создаёт makefile'ы ни в процессе билдинга, ни вообще никогда. Возможно, из-за п. 2...

8)

В смысле в файле проекта (*.pro) или в фалах проекта (*.cpp,*.h ...)?
Если в файле проекта (*.pro) то ->

Если в фалах проекта (*.cpp,*.h ...) то ->



Похоже глюк, но у меня он не наблюдается, ни в винде, ни в линуксе. В обоих системах работаю с eclipse 3.2.0 и CDT 3.1.0. А какая версия среды и плагинов у вас?


Скорее всего.

1. Конечно cpp...
Судя по описанию комбинации Ctrl+* она должна раскрывать "зафолденный" фрагмент, у меня же всё было раскрыто и плюсиков справа не было... Enable folding when opening a new editor стоял (его я и мучал)...
Впрочем сейчас всё заработало. Может, глюк (перезагрузку Eclipse'а делал). С PE Windows Parser тоже не сразу всё пошло...

2. Попыхчу ещё с QMake Editor'ом.
Версии: Eclipse 3.1.1, CDT 3.0.2.

3. В процессе билдинга какие команды предшествуют
mingw32-make -o Makefile (по умолчанию)
У меня билдинг начинается с этого make'а...

Не совсем так или, лучше, совсем не так.  :D Эта комбинация показывае и скрывает полоску слева, на которой этот фолдинг, собственно, и отрисовывается.



Советую все же обновиться, ибо: "This plugin has been tested with Eclipse 3.1.2 and CDT 3.0.2."



В идеале, если *.pro файл не содержит ошибок, то после его сохранения плагин сам запустит qmake и создаст для вас makefile-ы, следовательно вам останется только вызвать Build, который, в свою очередь, естественно, будет вызывать make.

Что означают строки в консоли при вызове в Eclipse отладчика:
(1) mi_cmd_stack_list_frames: No stack.
(2) Warning: E:\Cyrax\P2/E: No such file or directory.
Прооект у меня находится в E:\Cyrax\P2. К чему относится фрагмент "/E:" и какую директорию он не может найти - E:\Cyrax\P2 или E: ?

Странное поведение отладчика:
1. При установленном Stop at main() on startup при запуске отладчика выполнение программы останавливается на main'е (судя по всему). Но эта строка не выделяется. Если поставить брикпоинт, то при отладке строки выделяются...
2. Далее (после остановки на main'е) жму F5 или F6 - вся программа выполняется до конца. Тоже странно, поскольку F5 (Step Into) должен залезть внутрь main'а...
Выходит, останов на main'е по Stop at main() on startup происходит не по брикпоинту, а как-то по-другому...
3. Ставлю брикпоинт на main'е. Запускаю дебагер. останавливаюсь на main'е (уже по брикпоинту). Жму F5 - захожу внутрь на первую команду в main'е. Далее жму F5 или F6 - вся программа выполняется до конца...
4. Жму на main'е (после останова по брикпоинту) F6 (Step Over) - тоже захожу внутрь... Далее - как в п.3.

Как я понимаю, Eclipse'овый Step Over должен вызывать gdb-команду next, а Step Into - step.

Ни один из описанных  вами артефактов у меня не наблюдается. Похоже, что это все таки глюки. Какая-то не совместимость Mingw, gdb и eclipse. Возможно что-то из этого софта не из стабильных веток. Не стабильный eclipse, особенно под виндой, бывает глючит весьма сильно. Сечас у меня нет возможности посмотреть какиеименно версии Mingw и gdb стоят под виндой (это на работе, а я в отпуске). На следующей неделе, в понедельник, буду знать точно.

З.Ы.  Одно могу сказать точно, что для работы всегда использую не SDK версию eclipse, а обычный Platform Runtime Binary, его вполне достаточно, а весит несравнимо меньше.

Platform Runtime Binary - это голая платформа безо всяких плагинов ?

Вобщем, да, а главное без sdk. Но вот то что отсутствует нужно только разработчикам на яве, или разработчикам плагинов для eclipse, разработчику на С++ этот хлам абсолютно безполезен, и даже вреден, поскольку замедляет процесс загрузки  самой IDE. Так что смело можете в следующий раз скачивать только ее. Eclipse Platform Runtime Binary и CDT, это все что вам нужно. Я правда, тут не говорю о других плагинах, которые не входят в Eclipse Platform SDK, но могут быть полезными (например плагин для взаимодействия с subversion), это совсем другая история.

Сначала скачал последний gdb (6.3), поставил. MinGW у меня 5.0.2. Один из последних, по-моему.  Все глюки (может и не глюки) отладчика по-прежнему наблюдались, кроме одного - 3-го...

Далее скачал Eclipse SDK 3.2.1, CDT SDK 3.1.1. Всё поставил. Проверил Qt-плагин - всё то же самое, за искл. сообщения об ошибке (не выходит, но по-прежнему открывается пустая вкладка QMake Editor). Плюс 10-кратное сообщение об ошибке "...token error..." при первом изменении и apply'е параметров подсветки синтаксиса Qt...
Отключил CDT Makefile Builder и Scanner Configuration Builder, оставил только qmake builder. Сохранил. После этого перед открытием пустой вкладки QMake Editor стало выходить сообщение об ошибке
An error has occured. See error log for more details.
Просто замечательно ! :)

Выходит, плагин нормально работает только на Eclipse 3.1.2 and CDT 3.0.2...

Теперь, что касается отладчика. На таком примере:

к отладчику нет абсолютно никаких претензий.

Другой простенький пример:

А вот здесь всё и наблюдается:
1. отладчик не останавливается на main'е (на самом деле на первой команде main'а) по Stop at main() on startup, но останавливается по брикпоинту...
2. и по F5, и по F6 на QApplication app(argc, argv); происходит переход на строку
inline T qAtomicSetPtr(volatile T *ptr, T newval)
файла qatomic.h...
Далее после 40-кратного F6 (40 шагов висим на этой строке) возвращаемся на строку QApplication app(argc, argv);
Далее по F6 нормально движемся по строчкам...
И теперь непонятно, к чему относится вся эта канитель - к QApplication app(argc, argv); или к int main(int argc, char *argv[]). Судя по всему - к main'у. Только почему выделяется строка QApplication app(argc, argv);...

С чем всё это связано - с Qt или с "неконсольностью" проекта ?..


И ещё такой вопрос. В Qt-ном include файлы без расширения ссылаются (через #include) на одноимённый h-файл. Для чего это нужно ?
Все подключаемые к Eclipse Qt-ные h-файлы содержат директиву #include со ссылкой на h-файлы из каталога src. Опять-таки зачем так сложно всё организовано ?

добавлено спустя 7 минут:

 Предупреждения при вызове отладчика несколько видоизменились. mi_cmd_stack_list_frames: No stack вроде бы исчезло, а остальное:

Warning: /Cyrax/P2_Department/Department/debug;E: No such file or directory.
Warning: /Cyrax/P2_Department/Department/.settings;E: No such file or directory.
Warning: /Cyrax/P2_Department/Department;E: No such file or directory.
Warning: E:\Cyrax\_Myself_advancement\P2_Department\Department/E: No such file or directory.

Что это, всё-таки, означает ?
И debug, и .settings - всё имеется по указанным путям...

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



Это надо у тролей спрашивать. ИМХО, они, кажется, старались привести названия и методику включения заголовочников в соответствии с С++ стандартом (STL) и непотерять совместимость с программами написанными в старом стиле.

Ставил я прекомпилированную версию Qt 4.1.4, затем перекомпилировал в debug-варианте. Тогда получил гиг. Перекомпилил ещё раз - распух аж на 2,3.Гб... Видно в тот раз не почистил объектники...

В любом случае с дебаггером то же самое...

SLiDER, вы пробовали отлаживать второй пример кода ?  Может, и у вас те же артефакты пронаблюдаются...

добавлено спустя 9 часов 3 минуты:

 Те же самые проблемы с плагином возникают, если в свойствах Qt (преференсы) ничего не указывать. QtDir стоит .../Qt/4.1.4. Может, QMakeFeatures нужно указать...

Дело в том, что я проверил плагин на русифицированном Eclipse SDK 3.2.0 с CDT 3.1.0. Те же самые глюки...
Может, Java криво работает... Я ставил Java 2 SDK, SE v1.4.2...

Впрочем, попробую поставить Qt 4.2...

Сегодня был на работе. Воооот. Проверил

Все действительно так. Но этому есть простое объяснение. Я с этими проблемами не сталкивался, потому как мне как-то ни когда не приходило в голову ставить БП на функцию main непосредственно, как-то всегда обходиля, в случае острой надобности, первой функциональной строчкой кода внутри. А теперь по теме. Я так понимаю это глюк реализации gdb под винды. А эффект попадания "куда-то" связан с тем что Qt "перегружает" функцию main по своему усмотрению, вот на этой хитрой перегрузке gdb и глючит.

Кстати ява у меня версии 1.5, один из последних апдейтов, серьезных глюков вроде не заметил. На eclipse.org  рекомендуют именно ее, 1.4 вроде старовата.

А как насчёт warning'ов:

С такой проблемой, похоже, столкнулся DenKor из GCC (Ошибка при работе с gdb)...

Что касается плагина, то дело было именно в JRE. Поставил 1.5.0 - глюков нистало...
Можно было начать обновление именно с JRE, впрочем то, что обновился тотально - тоже неплохо... Выйдет Qt 4.2 Release - тоже обновлюсь.

8)

*в шоке* А сейчас Qt 4.2 не релиз?

*в шоке* А сейчас Qt 4.2 не релиз?

Сейчас пока Release Candidate...

Ето вы зря так. :D Очень даже релиз, неделю уж как.



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

Нет, всё-таки от глюков с плагином полностью не избавился. Остался один, но работать никак не мешает:
В преференсах в QMake Editor при изменении подсветки после каждого apply'а выходит ошибка "Token Error". После сообщения всё нормально применятеся...
Сам плагин глючить так не должен, скорее всего из-зха версий всего Eclipse'ового хозяйства...

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

Скорее всего, как-то, через Customize Perspective, но не спрашивайте меня как, я эту задачу в свое время так и не осилил.  :(

Да... Досадная недоработка...  :(

Всё, избавился и от последнего глюка с Qt-плагином (token error на apply'е).
Скорее всего дело было в длинных путях. В самом Eclipse'е плагины длинющие + у меня он сам глубоко сидел. В итоге длина превышала 256 символов. Посадил поближе - глюка нистало...
Если из-за путей, то, возможно, и со старой JRE нормально работало бы...
(а то были проблемы с распаковкой и копированием из-за длинных путей)

з.ы. Как избавиться от Far'овского глюка: иногда некоторые длинные файлы не может копирнуть, тогда как винда с ними справляется...

Вопросы по файлу проекта, создаваемому Qt-плагином, и не освещаемые Qt Assistant'ом:
1. Что означает операция "*=". Это то же самое, что и "+=" ?
2. Что за CONFIG-параметр debug_and_release_target ?
3. Как указать в файле проекта (не корректируя makefile) каталог, в который uic'у нужно поместить ui_... .h - файл ?  По умолчанию uic кидает его в папку с файлом проекта...

2. Откуда взял такое название параметра?
3. Ответ:
a) UI_DIR
This variable specifies the directory where all intermediate files from uic should be placed. This variable overrides both UI_SOURCES_DIR and UI_HEADERS_DIR.
For example:

b) UI_HEADERS_DIR
This variable specifies the directory where all declaration files (as generated by uic) should be placed.
For example:

c) UI_SOURCES_DIR
This variable specifies the directory where all implementation files (as generated by uic) should be placed.
For example:

1. *= заносит значение в список, если его раньше там не бьІло, тогда как += позволяет создавать дубликатьІ.

2. debug_and_release - будут создаваться мейкфайльІ и временньІе каталоги для рилиза и дебага. Я так понял debug_and_release_target нужен для того, чтобьІ результирующие исполняемьІе файльІ ложились в соответствующие временньІе каталоги, а не в корневую директорию.

3. Вообще для етого есть переменная UI_DIR:

Как вьІставляется в плагине не скажу.

Steven_Orko
Откуда взял такое название параметра?

Это Qt-плагин его ставит...

Dendy

Почему-то в Qt Assistant'е про *= ни слова...
Что значит "выставляется" ?  Имеешь ввиду QMakeFeatures ?

добавлено спустя 1 час 59 минут:

 Такой общий вопрос по Qt (левый по отношению к сабжу):
Почему в Qt переписаны некоторые контейнеры, которые имеются в STL ?

Про *= написано в докуvентации по утилите Make. Очевидно, синтаксис .pro-файла Qt частично списан с синтаксина Makefile.

Как флаг UI_DIR вьІставляется в плагине к Еклипсу. С последним не встречался, поетому ничего подсказать не могу. Может и не надо.

добавлено спустя 2 минуты:

 

Я вот здесь кое-что писал по етому поводу. Загляни:

http://forum.qtlib.ru/viewtopic.php?t=27

Ого. Классный сайт...
Стоит перебазироваться (в части Qt)...
8)

qtlib.ru погиб?  ???