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