Opened 10 years ago

Closed 10 years ago

#134 closed defect (fixed)

QMake: Incorrectly generated INCLUDE entries due to missing substutution in moc.prf/uic.prf

Reported by: hermi Owned by:
Priority: major Milestone: Qt Enhanced
Component: qmake Version: 4.5.1 GA
Severity: medium Keywords:


Incorrect INCLUDE entries have been generated.

Solved by changing

QT4.5.1-GA\mkspecs\features\moc.prf (line 76):

win32:moc_dir_short ~= s,^.:,/,


"win32|os2:moc_dir_short ~= s,^.:,/,"


QT4.5.1-GA\mkspecs\features\uic.prf (line 38):

win32:ui_dir_short ~= s,^.:,/,


win32|os2:ui_dir_short ~= s,^.:,/,

It might make sense to review all other *.prf files if some more "win32" -> "win32|os2" changes are needed.

Change History (4)

comment:1 Changed 10 years ago by dmik

  • Summary changed from QMake: Incorrect generated INCLUDE entries caused by an error in moc.prf/uic.prf to QMake: Incorrectly generated INCLUDE entries due to missing substutution in moc.prf/uic.prf

Thanks for the report! Could you please an example of the input, the "generated INCLUDE entries" it produces and the expected result?

From what I see, this assignment replaces "x:" at the beginning of the string with "/" -- w/o the context, I don't see how it can make any sense.

comment:2 Changed 10 years ago by hermi

Additional remarks:

Unfortunately it is not easy for me to provide a single .pro file.
When I tried to compile mks_1.8.4.0b2-svn3482 I had the problem that the ResponseFiles? contained the following lines:


It seems that the QMake parser was confused by the drive part "u:" (I saw this in QMakes's debug output). With the above changes which remove the "u:" the ResponseFiles? were correct:


comment:3 Changed 10 years ago by dmik

Okay, now I see, it's one of the unix/dos path difference related bugs they still can't get rid of in qmake (the qmake code is a big mess, believe me :) which they fix with the even worse hack in the .pro file.

Fixed in r572 (on the trunk, which is 4.6.1. Left the 4.5.1 branch untouched since I don't think we actually want to spend time supporting it).

What about reviewing all cases where win32 is used in .pr? files, there are quite a few of such places. I already fixed the obvious ones quite some time ago but it's impossible to analyze and check all of them w/o the context (like in this case). We will fix other issues if and as they appear.

comment:4 Changed 10 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.