On Monday 19 January 2015 19:17:51 René J.V. Bertin wrote: > On Monday January 19 2015 09:26:23 Thiago Macieira wrote: > > On Monday 19 January 2015 11:34:43 René J.V. Bertin wrote: > > > > > > Hence a recommendation (not a requirement) to build in a clean > > environment. > > It does turn out to be the kind of recommendation one cannot ignore, eh?
YMMV. The problem is really that if it fails, it may fail subtly and you never get to find out until you've shipped the binary... > > > I'm still a bit surprised though which this isn't an issue with library > > > directories. > > > > It is. > > In what sense? If it's an issue, it's a very subtle one that doesn't cause > the build to fail. I'm speaking in generic terms. I don't have any specific case that can cause this problem right now. But the principle is the same: -I flags affect the #include order so you can find stale headers and -L flags affect -l flags, so you can find stale libraries. > > > > OK, it shouldn't be looking for headers of its own version outside of > > > > the parent of its source directory. > > Not just its own headers, any header (that should be of the correct > version). In my opinion, adding a non-default -headerdir path to the -I > arguments means you're looking there. Of course I never said "it" as > looking for old headers, it indeed just happens to find them because it's > looking in a place it shouldn't. And like I said: it isn't adding the path to -headerdir because you passed it to -headerdir. (yes, it is in the qtwebengine case, but I'm talking in generic) It added that because something *else* requested that path. I gave you the example of qtsvg searching for QtCore headers, but it could also happen for glib header or OpenGL headers or whatever. For example, let's take the case of a ports system that puts all the headers in /opt/ports/include so QtCore headers end up in /opt/ports/include/QtCore and zlib.h is /opt/ports/include/zlib.h. What might happen is that qtsvg has -I/opt/ports/include so it can find zlib.h there, but this -I interferes with the QtCore headers. Worse, this can happen for QtCore itself, so QtCore's own build finds its old and stale headers. A similar thing can happen for libraries: to link to /opt/ports/lib/libzlib.dylib, the -L/opt/ports/lib flag interferes with the option for -lQt5Core. > > In my opinion, all such systems that build in-place have a serious flaw > > because you're trusting that software won't accidentally pick up > > something that is already installed. > > Go ahead and change the world if you wish ... I don't have to. This is standard practice already. All the major Linux distros build their packages like I described. Look at Fedora's Koji or the Open Build System or what Debian uses. Take a look at Scratchbox too. That's also how we build our own binaries at the Qt Project: clean configuration, not in someone's machine. > To be honest, I don't know. I do know it's easy enough to debug in this > case: /usr/local/include/config.h shouldn't exist, because too common. And > most of all, no project should install a file with a name like that in a > global include directory. I agree with you. My problem is when you as the ports maintainer have to debug a problem because this file that shouldn't exist does exist. Preprocessor issues are the worst kind, because they often result in very unexpected and weird errors, elsewhere. A bad config.h might result in disabled features on an otherwise fully-working application, so you'd spend a lot of time debugging to find out that it was caused by a left-over build of an unrelated package that the user built herself... Hence, the wish to avoid this error in the first place. > > Note I wasn't addressing qtwebengine, but a generic problem. > > No, but I was, because that's the only place where the issue occurs. I'm Where this occurs *right now*. I'm giving the recommendation because it might occur in other places. The recommendation is generic but works for this specific case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
