On Friday March 27 2015 14:20:57 Mojca Miklavec wrote:
>My suggestion would be to require a "hack" from users for now and have
>something that conditionally works. And only later try to figure out
>if Qt's sources could be modified in such a way that the compiler
>could be reliably set to ${prefix}/bin/clang-mp-3.4.
Actually I had forgotten about 1 aspect. The Qt build system uses xcrun -find
$foo to find the "official" foo executable. That works fine on recent OS X
versions when $foo contains a path (i.e. / character(s)), but not on OS X 10.6
. I already hacked the build system to skip the use of xcrun for CC and CXX; I
have now commented out its use entirely, so that the tools are used as they're
specified through the mkspec (clang.conf). I'm running the build again (I'm
crazy...) with a symlink to clang++-mp-3.5 in ${build.dir}/qtbase/bin/clang++
and using that as QMAKE_CXX (idem for QMAKE_CC). It seems that this link is
resolved anyway, so the build is invoking /opt/local/bin/clang++-mp-3.5 .
If this works out I'll add logic that creates the compiler symlinks to the
latest clang version available on the system, which will be macports-clang-3.5
is no clang version had been installed before. I'll have to see how I'm going
to configure things for the installed Qt, if the macx-clang mkspec will just
invoke clang/clang++ (i.e. a runtime dependency on port select), a proxy, or if
I leave the hardcoded, versioned name.
I don't know if I like this better or worse than asking the user to make a
choice, but at least this should work on the build bots...
R.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
