On Sunday March 22 2015 21:35:47 Samir Aguiar wrote: > I remember that somewhere during the makefile generation qmake runs > xcrun --find clang > and uses the output as the compiler path, ignoring what you set in > QMAKE_CXX.
Yes, that's in qtbase/configure, and it basically determines the compiler used to build qmake. It's the first thing I fixed, remove QMAKE_CC and QMAKE_CXX from the switch that queries xcrun. Without that you cannot even hardcode compiler paths in mkspecs/common/clang.conf ... Turns out that was not enough. On Sunday March 22 2015 20:33:53 Hausmann Simon wrote: > Should bootstrap really use the mkspec compiler? I'm not sure that's always > the right thing. Bootstrap should just use _any_ compiler. Heh, I think I agree to some extent, because a priori "any compiler" means that you (I :)) have some control over it. As things stand, a very specific compiler is chosen, i.e. the one provided by Xcode. That's fine on recent OS X versions where that means a recent clang version, but not on OS X 10.6 (and maybe even 10.7). The compiler used to build qmake shouldn't matter, as long as it's recent enough, and it'd be useful if one could specify it through $CXX for instance. But I do think that the bootstrap qmake should respect the mkspec. Suppose you want to build with clang on Linux where you also have perfectly a valid gcc which is probably the system default compiler (/bin/cc or something like that). It'd a bit surprising if qmake just used whatever it finds first in that case. One could of course think of a mkspec that has something like QMAKE_CXX=$CXX to tell qmake to use the CXX env. variable (or the system default otherwise). But that's a different topic (though still subject to qmake NOT replacing this setting through .qmake.stash ;)). > What is the underlying problem that you are trying to solve? Sorry, this is going to be long! I'm trying to come up with a reproducible build script for MacPorts, on OS X 10.6.8 . On that OS version we have to take 2 Xcode versions in consideration (3.2.6 and a very early 4 series). The former has gcc-4.2 as the default compiler (and an optional very early clang version, 1.7 or so), the latter Apple clang 3.0 . Gcc-4.2 runs the config tests just fine, but chokes on something too modern in QtCore. Apple clang 3.0 doesn't compile all tests: the nis, icu and corewlan ones fail. The former 2 can be patched (and need to for later clang versions too, with the 10.6 SDK). The corewlan test cannot be patched, though. The additional issue is that the MacPorts script (Portfile) cannot easily control what Xcode version is installed or selected, and shouldn't have to force the user to make a choice. So the best way out is to install one of the recent clang versions that are in MacPorts (and *that* is something we can control in Portfiles). That provides clang and clang++ in MacPorts' bin, which is frontmost in the path during builds. So in practice I'm not actually hardcoding a compiler path in the mkspec, but that is only because I figured out how to avoid the hardcoded references to Xcode compilers. There's a related problem that may carry more weight because if affects current OS X and Qt versions. The MacPorts Portfile installs Qt 5.4.1 on OS X 10.7 and later. It can also generate a universal build, using 2 separate builds which are lipoed together at the end. That requires "cross-bitwidth" compilation, e.g. 23bit on a 64bit system. That's easy enough on paper; just use the macx-clang-32 mkspec, and that works for everything but QtWebEngine. That is in fact what the Portfile installs in a single go, giving me a universal Qt 5.4.1 installation missing just that 1 component. The QtWebEngine component is a separate port. To build it, we extract just the qtwebengine directory from the qt-everywhere tarball, and then invoke the installed qmake (/opt/local/libexec/qt5/bin/qmake -r ../qt-everywhere*/qtwebengine/qtwebengine.pro) with either macx-clang or macx-clang-32 . And that's where things go wrong: when called inside the Qt source tree, the *installed* qmake ignores the m kspec file. Outside that source tree it works exactly as expected, but not inside the tree. Note that we're talking about a fresh checkout here, so there is no .qmake.stash before I call qmake. I'll be having another look at this issue when I'm done working on the 10.6.8/Qt5.3.2 build. R. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
