Hi Viktor,
> + Added QtUiTools for darwin. (tested)
> + Added QtUiTools for linux. (not tested)
> ! Added QtUiTools lib for static QT hbqts.hbc.
I think we will not have problems with the QtUiTools integration on the native
linux builds. As we know, the problem with QtWebkit appears just during the
cross builds, making the hbqt lib build impossible. Now this is solved with a
drastic temporary solution by cutting out the references to QtWebkit headers
and functions from hbqt_slots.h and hbqt_slots.c. Probably the final solution
will contain new hbqtWebKit_slots.h and hbqtWebKit_slots.c in qtwebkit
subfolder.
My proposal is to help the designers in building new Qt interfaces with correct
interdependencies, avoiding a monolithic structure, with updating the Qt make
system.
Now we have the following sequence in the hbqt/detect.mk:
...
ifneq ($(HB_HAS_QT),)
ifeq ($(_QT_DARWIN),yes)
HB_CFLAGS += -I/Library/Frameworks/QtCore.framework/Headers
HB_CFLAGS += -I/Library/Frameworks/QtGui.framework/Headers
HB_CFLAGS += -I/Library/Frameworks/QtNetwork.framework/Headers
HB_CFLAGS += -I/Library/Frameworks/QtWebKit.framework/Headers
else
HB_CFLAGS += $(foreach d,$(HB_HAS_QT),-I$(d) -I$(d)/Qt -I$(d)/QtCore
-I$(d)/QtGui -I$(d)/QtNetwork -I$(d)/QtWebKit)
endif
...
The above sequence offers undesired references. For example HB_CFLAGS should
not contain -I/Library/Frameworks/QtWebKit.framework/Headers or the linux
correspondent (etc.) in the hbqt, hbqtcore, hbqtgui and hbqtnetwork builds.
This include-path should be used just for the hbqtwebkit library build.
Please analyze the idea mentioned above, taking into consideration that a new
element will appear soon due to Pritpal developments.
A flexible solution here will make the Qt interface more clear without
undesired interdependencies.
Best regards,
István
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
