Endless loop of qmake.exe

[koahnig]

backslashes could be the problem.
Checkout on the "defect" setup computer your .pro files.
DO NOT use backslashes in Qt related for folders. They have a special meaning and mark that the next line is a continuation line.
A .pro file should have statements like:
@
HEADERS += ./head.h
./head2.h
c:/AnotherHeader/header3.h
c:/Blo/bli.h
@

As you see at the end of lines there is a backslash when another line is following.

[Benjamin05]

Yes, but I have used the same .pro file on both computers, without changing it. And if I open the .pro file on the defect computer, everything looks fine:
@#-------------------------------------------------

Project created by QtCreator 2011-11-17T11:31:42

#-------------------------------------------------

QT += core

QT -= gui

QT += network

TARGET = arinc2network
CONFIG += console
CONFIG -= app_bundle

TEMPLATE = app

INCLUDEPATH += ../../advTcpSocket/
../../socketConfig/
../../aimCard/src/
../../aimCard/src/third_part/aim/
../../arincChannel/
../../condorCard/src/
../../condorCard/src/third_part/condor/include/
../../advTcpServer/
../../Font/

CONFIG += console

SOURCES += main.cpp
../../socketConfig/socketconfig.cpp
../../advTcpSocket/advtcpsocket.cpp
../../aimCard/src/aimcard.cpp
../../condorCard/src/condorcard.cpp
../../arincChannel/arincChannel.cpp
../../advTcpServer/advtcpserver.cpp

HEADERS +=
../../socketConfig/socketconfig.h
../../advTcpSocket/advtcpsocket.h
../../aimCard/src/aimcard.h
../../condorCard/src/condorcard.h
../../napArray/napArray.h
../../arincChannel/arincChannel.h
../../advTcpServer/advtcpserver.h

LIBS += -L"$$PRO_FILE_PWD/../../aimCard/src/third_part/aim/libs" -lapi_civ
-L"$$PRO_FILE_PWD/../../condorCard/src/third_part/condor/libs" -lcei_ll -lwinmm

CONFIG(debug) {
LIBS += -L"$$PRO_FILE_PWD/../../condorCard/src/third_part/condorLib-build-desktop/debug/" -lcondorLib
-L"$$PRO_FILE_PWD/../../aimCard/src/third_part/aim/libs" -lapi_civ
-L"$$PRO_FILE_PWD/../../condorCard/src/third_part/condor/libs" -lcei_ll -lwinmm
}
@

[koahnig]

Did you copy the qmake from one machine to the other?
Do not forget the safety copy!

Are both OS identical?
Any OS language settings? Which are different?

[Benjamin05]

I have copied the whole project from one pc to the other. I could not build it, then I ran qmake and could again not build it. The I compared the new makefile with the backup.Unfortunatly are the backslashes created by the computer, that is working fine. The "correct" slashes are created by the computer that is getting the endless loop.

The problem is, that I cannot even reproduce the behaviour. I have some older makefiles from the "working" computer, which have no false baskslashes. This morning I tried and it made backslashes in the path. Still building the project worked fine. Sometimes I can build the project on the defect PC (when creating the makefile is skipped - the configuration has not changed) when I copy it from the working pc, sometimes the endless build occurs and sometimes I get Makefile Error 2 message. And the one file I copied can be build even after I run qmake on the defect PC.

Both OS are a french windows xp version. Qt is both times english and version 5.1.0

[koahnig]

It could be windows xp possibly in combination with french. However, this is for sure trying hit something in the fog. :(
Qt libs are English anyway. You can change the language setting in Qt creator, but that should not matter I would think. default installations were in German in my case. I have changed merely because I used to have English interfaces and get irritated by German :)

The only thing you have apparently not tried (or I have not found) is copying the QMAKE.EXE version from one installation to the other.

However, once again, make sure that you have a safety copy in order to be able to restore.
As long as you have the identical setup (folder names and stuff) on both machines, this should be possible.
The executable QMAKE.EXE is most likely the trouble maker.

However, IMHO all is very illogical!!
If there are some issues with xp and new Qt creator respectively qmake, I cannot answer. I do not have the experience.
You would have to raise this question with the developer channel.

[Benjamin05]

Thank you again for your help.
I copied qmake.exe from the other computer and building and cleaning works fine now!
The only strange behaviour is, that I have to run qmake before building in order to get my sourcecode changes compiled. But this at least, is a behaviour I can live with!

[koahnig]

[quote author="Benjamin05" date="1375429902"]
I copied qmake.exe from the other computer and building and cleaning works fine now!
[/quote]
That is good to know.

[quote author="Benjamin05" date="1375429902"]
The only strange behaviour is, that I have to run qmake before building in order to get my sourcecode changes compiled. But this at least, is a behaviour I can live with![/quote]
I got this behavior too. When switching between release and debug compilations, I need to run qmake for sure.
I have quite complex projects using "subdirs" templates. Editing in the subprojects is not always caught properly and caused already a couple of times heavy swearing ;-)

[woehrl.biz]

Had the same behavior. I had a cross-compile environment building for Raspberry Pi. The reason for that behavior was, that the clock of the embedded system was hours late. That's why "make" resulted in calling "qmake" forever...

[jsulm]

@Benjamin05 The first Makefile from the two you compared looks like a Makefile generated for UNIX systems:

DEL_FILE = rm -f
CHK_DIR_EXISTS= test -d

The other one is for Windows.

[sl.sy.ifm]

I just ran into another case where this can happen with Qt5.11 mingw (and completely clean project ... so, no old makefiles or similar)
it seems it was triggered by a too long file path (it seems even on Windows10 there is some max-file-path at least for the mingw tools) ... I worked around that by reducing the name of the shadow-build folder
... from "build-FoobarUI-Desktop_Qt_5_11_1_MinGW_32bit-Debug" into "build-qt11_mingw"

... I guess other workarounds are probably to relocate sourcecode (so that it has shorter absolute path) ... or reducing folder name length in the project it self

Just wanted to drop this info, in case someone also runs into this old thread by googling ;)

[8Observer8]

I had this problem. In my case it was because of too long path to the project.