Opened 16 years ago
Closed 16 years ago
#1 closed task (fixed)
Port qmake
| Reported by: | Silvan Scherrer | Owned by: | Silvan Scherrer |
|---|---|---|---|
| Priority: | major | Milestone: | qmake |
| Component: | qmake | Version: | 4.5.1 Beta 1 |
| Severity: | Keywords: | ||
| Cc: |
Description (last modified by )
Tracker for general discussion about the milestone.
Change History (10)
comment:1 by , 16 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:2 by , 16 years ago
| Summary: | Port of Qmake → Port qmake |
|---|
comment:3 by , 16 years ago
| Description: | modified (diff) |
|---|
comment:4 by , 16 years ago
Just for the record. While doing qmake, the following QtCore classes were ported to OS/2:
- QFSFileEngine
- QSettings
comment:5 by , 16 years ago
| Component: | QtCore → qmake |
|---|
comment:6 by , 16 years ago
Got a nasty problem: GNU make doesn't interpret quote (" and ') chars as space quotation chars in file names: it assumes they can be part of the file name. As a result, having, say:
all: "some" echo something
and a file called some in the current directory will cause make to complain:
make: *** No rule to make target `"some"', needed by `all'. Stop.
although "some" and some are defacto the same file in many OS/2 applications including CMD.EXE.
Currently all file name escaping is done in the OS/2 style (e.g. with double quotes) which is a must for commands executed through CMD.EXE but may break rule definitions.
I will have to change escaping functions and carefully check that the right one is used depending on whether it is a make construct (e.g. the target or dependencies of the rule) or a command to execute.
comment:7 by , 16 years ago
The main difficulty is that there are make variables (e.g. $(DESTDIR_TARGET)) that are used both in commands and in rule definitions...
So far, the only solution I see is to replace $(DESTDIR_TARGET) with $(escape $(DESTDIR_TARGET)) where escape is a custom function that removes " and escapes spaces and alike with /.
comment:8 by , 16 years ago
In r44, I implemented the described behavior (the function is called q for shortness). I applied it to all variables we define in the GNUMAKE generator, though there is still a possibility that there are variable references inserted by base classes which we don't control.
However, this isn't actually that dangerous since spaces in file names are quite rare (proven by Qt3/OS2 where these problems didn't show themselves yp; at least I didn't hear about that), so I think that we leave it at this stage and will come to the problem later if it pops up.
comment:9 by , 16 years ago
In general, qmake looks quite stable now (to the level I can test it w/o having the Qt libraries itself), so we can close the task. Further problems if any will be reported as bugs.
comment:10 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
Silvan, I was expecting that you will close the task since you're the "owner" and also to let you have an overview the overall progress, but I can do it myself of course.

(changeset:33) qmake is working. some bugs still present