Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday February 25 2019 12:24:31 Kevin Funk wrote: > That makes sense in theory. QMake will switch to a different mkspec when you > pass `-spec ...` when building an external project. It's impossible to > instruct CMake to do the same right now, as the mkspec is hardcoded in the > CMake config files of the Qt install. > > Maybe there should be a way to overwrite the mkspec used via a -DQT_MKSPEC > parameter, with the potential drawback of being able to create a broken I'm testing a patch which leaves in the CMAKE_MKSPEC variable (with the current hardcoded setting as a default). So far I haven't noticed any differences but I haven't yet pushed things to the limit. CMake gives the user plenty of opportunity to create a broken configuration; as long as any new option complies with the "garbage in/out" principle there shouldn't be a problem :) > be a potential solution, but again, would require quite a lot of additional > CMake code I'm afraid. Not something I'd envision to maintain for all the > different mkspecs we have. You could consider an approach where you do a reasonable amount of inferring for the foreseeable configurations, and raise an error requiring the user to set the variable explicitly when there's a too big mismatch with the Qt build configuration. No idea if that's better than just using the current hardcoded default with a possibility for manual override. > Yes, that's why this hasn't popped up on the bug tracker so far I think. It's > again an artificial problem: Maybe, but one that can become a real problem anytime. Probably. So maybe my example was too good in a sense (it's been too long since I did any development on MSWin), but what when one of the mkspec headers introduces something that somehow depends on the C++ runtime in use (on Linux; here too I'm not certain if it is officially "not done" but libc++ appears to be mixable with libstdc++ when built against that runtime)? R ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday, 25 February 2019 11:04:31 CET René J.V. Bertin wrote: > On Monday February 25 2019 10:18:01 Kevin Funk wrote: > > Hi, > > >From my quoted message: > > >> Now, I think it's not entirely relevant whether or not this particular > > >> setting is a left-over due to me not trashing the entire Qt build > > >> directory > > >> before rebuilding with clang. The fact is that you should be able to > > >> build > > >> Qt with one compiler and dependent software with another. > > So you confirm that the path indeed depends on the compiler used during the > Qt build Well, yes. That's what currently happens. The mkspec used cannot be altered when using CMake afaics. > (and that my installed copy resulted from rebuilding with clang). > > The question remains though why this path determined at Qt build time and > not at the dependent's build time. > After all you use CMake to build some > dependent instead of Qt itself, and CMake makes it easier to use any > compiler than QMake. That makes sense in theory. QMake will switch to a different mkspec when you pass `-spec ...` when building an external project. It's impossible to instruct CMake to do the same right now, as the mkspec is hardcoded in the CMake config files of the Qt install. Maybe there should be a way to overwrite the mkspec used via a -DQT_MKSPEC parameter, with the potential drawback of being able to create a broken configuration (cf. a MinGW build against a Qt MSVC install; which can't be mixed), but I don't know. Deferring the mkspec from CMAKE_CXX_COMPILER would be a potential solution, but again, would require quite a lot of additional CMake code I'm afraid. Not something I'd envision to maintain for all the different mkspecs we have. So far we haven't had any reports of this issue, and I'd rather leave that for Qt6 times where we need to find a different solution regarding mkspecs when building Qt with CMake anyway. > The differences between GCC and clang tend to be small, but take an MSVC > build of Qt on MSWin, and then build some KDE project with > -DCMAKE_CXX_COMPILER=clang++ ; could be more problematic, no? Yes, that's why this hasn't popped up on the bug tracker so far I think. It's again an artificial problem: - Differences between GCC & Clang are tiny (in fact qplatformdefs.h for both of them are almost similar). - In the example your mention you'd need to use Clang's clang-cl.exe as compiler anyway, which is a drop-in replacement for MSVC's cl.exe and thus should accept anything from win32-msvc/qplatformdefs.h anyway. Regards, Kevin > > R. -- Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday February 25 2019 10:18:01 Kevin Funk wrote: Hi, From my quoted message: > >> Now, I think it's not entirely relevant whether or not this particular > >> setting is a left-over due to me not trashing the entire Qt build > >> directory > >> before rebuilding with clang. The fact is that you should be able to > >> build > >> Qt with one compiler and dependent software with another. So you confirm that the path indeed depends on the compiler used during the Qt build (and that my installed copy resulted from rebuilding with clang). The question remains though why this path determined at Qt build time and not at the dependent's build time. After all you use CMake to build some dependent instead of Qt itself, and CMake makes it easier to use any compiler than QMake. The differences between GCC and clang tend to be small, but take an MSVC build of Qt on MSWin, and then build some KDE project with -DCMAKE_CXX_COMPILER=clang++ ; could be more problematic, no? R. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
On Monday, 25 February 2019 09:56:42 CET René J.V. Bertin wrote:
> Hi,
>
> Trying to get an answer to the question below once more.
> In a nutshell: shouldn't the CMAKE_MKSPEC (or some equivalent) be preserved
> in the installed CMake modules such that the correct mkspec directory is
> added to the compiler's header include search path?
Hey,
The header include path is part of the _qt5_corelib_extra_includes CMake var.
See:
% ag -s mkspecs /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/
/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake
2:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/lib/x86_64-
linux-gnu/qt5//mkspecs/linux-g++")
That's what you're looking for, right?
If I instead build Qt5 myself using Clang, I end up with this location in the
.cmake file:
% ag -s mkspecs lib/cmake
lib/cmake/install/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake
2:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/.//mkspecs/
linux-clang")
Looks all fine to me?
Regards,
Kevin
> Or should that directory be excluded altogether?
>
> R.
>
> ---
> I just noticed something strange in the huge compiler commandlines you tend
> to get while building KDE applications. An application configured to build
> with clang adds qt5/mkspecs/linux-g++-64 to the header include path (with
> -isystem, at that).
>
> At first I thought this was an error in that my Qt install (5.9.7, FWIW) was
> built with GCC but since a release or two I changed to building Qt with
> clang too.
>
> Now, I think it's not entirely relevant whether or not this particular
> setting is a left-over due to me not trashing the entire Qt build directory
> before rebuilding with clang. The fact is that you should be able to build
> Qt with one compiler and dependent software with another.
>
> Am I overlooking an existing way to get the correct mkspec directory added
> to the header search path?
>
> The source for Qt5CoreConfigExtrasMkspecDir.cmake suggests this is set via
> CMAKE_MKSPEC but that variable is no longer referenced in the installed
> cmake modules (again, in Qt 5.9). So even setting this on the commandline
> doesn't have any effect - but CMake should be able to infer at least the
> most common mkspec dirnames from CMAKE_CXX_COMPILER(_ID) ...
>
> Thanks,
> R.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"
Hi, Trying to get an answer to the question below once more. In a nutshell: shouldn't the CMAKE_MKSPEC (or some equivalent) be preserved in the installed CMake modules such that the correct mkspec directory is added to the compiler's header include search path? Or should that directory be excluded altogether? R. --- I just noticed something strange in the huge compiler commandlines you tend to get while building KDE applications. An application configured to build with clang adds qt5/mkspecs/linux-g++-64 to the header include path (with -isystem, at that). At first I thought this was an error in that my Qt install (5.9.7, FWIW) was built with GCC but since a release or two I changed to building Qt with clang too. Now, I think it's not entirely relevant whether or not this particular setting is a left-over due to me not trashing the entire Qt build directory before rebuilding with clang. The fact is that you should be able to build Qt with one compiler and dependent software with another. Am I overlooking an existing way to get the correct mkspec directory added to the header search path? The source for Qt5CoreConfigExtrasMkspecDir.cmake suggests this is set via CMAKE_MKSPEC but that variable is no longer referenced in the installed cmake modules (again, in Qt 5.9). So even setting this on the commandline doesn't have any effect - but CMake should be able to infer at least the most common mkspec dirnames from CMAKE_CXX_COMPILER(_ID) ... Thanks, R. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
