On Sunday January 18 2015 11:40:38 Thiago Macieira wrote: > > >If you're building Qt 5, remove the old Qt 5 headers that exist in the > > >target of the installation. > > > > So someone on a recent Linux system with a KF5 desktop built on a > > system-wide Qt 5.3.2 should remove those system headers when building Qt > > 5.4? > > If you're building with -headerdir /usr/include, yes. > > > Is that really different from giving the same instruction to someone > > building a new libc version? > > No, same instruction.
Sorry, but that's just inacceptable, if not only because we're talking about multi-user systems. It may be neigh impossible to avoid finding old headerfiles if they're in accessible through a standard include path like /usr/include. But that's not the case here - which is probably also one of the reasons why the -headerdir option exists. A path like /opt/local/include/qt5 (my case) or /usr/include/$(DEB_HOST_MULTI_ARCH)/qt5 is *not* in the standard search path, and the only time the Qt5 build system should use these paths when given through -headerdir is in the install step. (And maybe for configuring the qmake copy that will be installed.) And not even a week ago you agreed: On 12 January 2015 at 17:20, Thiago Macieira <thiago.macie...@intel.com> wrote: > On Monday 12 January 2015 14:38:20 René J.V. Bertin wrote: >> Concerning the error show at https://paste.kde.org/p2vtxcfcs , it turns out >> that it indeed went away after I moved aside /opt/local/include/qt5 . That >> is the place the headers should go after installation, NOT where they >> should be looked for during the build. In other words, `configure >> -headerdir foo` should NOT, IMHO, add `-Ifoo` to the compiler/preprocessor >> options! >> >> Can that be considered a bug? > > Yes. I also think that the fact that this header confusion issue exists only with qtwebengine (the only component using ninja) means that it is perfectly possible to avoid it. > It can't always be. Think of when you're building something besides qtbase > > (let's say qtsvg) and qtbase is the system one. You'd expect the build to do: > -I$QTDIR/include -I$QTDIR/include/QtCore -I$QTDIR/include/QtGui > > But then you have includes like: > > #include <QtSvg/qsvggenerator.h> > > which will match the first -I. In this case, it's easy It should always be "easy". When you're building qtfoo against the system qtbase, you will use the system qmake, and you're only going to specify headerdirs when you want your qtfoo to be installed elsewhere but system wide. But when you're building all of Qt by invoking the toplevel Makefile in the build directory (in or out of tree, shouldn't matter, say /tmp/qt5build), something else will or should happen. - First, a qmake is build. It could be a special qmake, or it could be the qmake that will be installed later on; that doesn't matter as long as it will use the build directory as its QTDIR (QTDIR=/tmp/qt5build). - Then, qtbase is built. It remains in place, just like for someone who never does a `make install`. - After qtbase, the other components are built in the appropriate order. Each of those components is built in the local Qt environment (/tmp/qt5build), and the qmake tool from that environment will provide header and library paths within that environment. So one would NOT expect "the build to do -I$QTDIR/include -I$(QTDIR/include/QtCore -I$(QTDIR)/include/QtGui", but rather something like -I$(QTDIR)/qtbase/include -I$(QTDIR)/qtbase/include/QtCore -I$(QTDIR)/qtbase/include/QtGui If this issue never came up before, it's likely that it is a regression introduced with 5.4.0, and the cause should thus be found comparing the qtwebengine/src/core build system between 5.3.2 and 5.4.0 . R. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
