Hi Istvan, >> + 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.
I know about this, but until the source code itself contains monolithic code, I don't see any point on spending time to solve this problem on the build level. I would just be a waste of time at this point. As I wrote in prev mail, IMO it'd be much better to avoid hbqt lib altogether and move any lib dependent stuff (including above flags) to qt lib level. But, this job needs to be solved on source level first, and it's enough to follow by build system afterwards. After the source will have been changed and hbqt eliminated, above build level change is quite easy to make. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
