Port qmake

[Silvan Scherrer]

Tracker for general discussion about the milestone.

[Silvan Scherrer]

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

[Dmitry A. Kuminov]

Just for the record. While doing qmake, the following QtCore? classes were ported to OS/2:

• QFSFileEngine
• QSettings

[Dmitry A. Kuminov]

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.

[Dmitry A. Kuminov]

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 /.

[Dmitry A. Kuminov]

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.

[Dmitry A. Kuminov]

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.

[Dmitry A. Kuminov]

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.