[Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"

[Kevin Funk]

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.funk at kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5322 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190225/737cbffc/attachment.bin>