Also I’ve tried using Hyper-V, which WSLg under the hood uses, but the Ubuntu 22.04 image wouldn’t boot.
WSL2 and WSLg was the way to go! I’ve installed Qt Creator via sudo apt install qtcreator and then started Qt Creator via the Windows shortcut named Qt Creator (Ubuntu-22.04)!
This is a short cut for C:\Windows\System32\wslg.exe ~ -d Ubuntu-22.04 qtcreator
Qt Creator would look like this:
It’s very hard not to notice that the windows title bar looks a bit weird. The generic window icon, the mouse cursor that does strange theme changes, and the bit fat window borders!
My goal was to have Qt Creator 9 look similar on Windows 11 as a native Windows Arm64 application and as native Ubuntu 22.04 Linux application running with WSLg.
Coming from other build systems to CMake one will quickly learn that
CMake can build only one configuration at a time. In practice
you need to set up multiple build directories and configure/build
with CMake for each and every one.
Autotools can do static and shared builds of libraries. For CMake
most of the project would do a static build, then a shared build
by setting the CMake variable BUILD_SHARED_LIBS to ON.
QMake can do debug and release builds at the same time, and as
we can read at Qt for Android better than ever before,
it can configure multiple Android architecture configurations
at the same time.
What can we do to get the same level of convenience with CMake?
In this article I’m going to talk about building a C++ library with CMake, but it won’t be a CMake tutorial.
Let’s say you have a C++ library which depends upon a few open source libraries, which have a CMake project structure,
but not necessarily done by the book (which means that they get only get built, and not deployed / installed)
Your library will include tests (unit-tests / integration tests), and the deployment can be just packing the headers and the binaries together in a tar.gz file.
This is not necessarily by the book, but it will do the job, and it could fit into any build system that the client has.
In this article I am revisting an article from three years ago: “Speeding up libclang on Windows”,
in which I was having a look at how the experimental Clang Code Model was handling a particular source code file.
With the help of Profile Guided Optimization I was able to go down from 10 seconds to 6 seconds.
Three years ago I tested Qt Creator 3.6.0, Qt 5.5.1, LLVM/Clang 3.6.2, MinGW GCC 5.3.0, Visual C++ 2013/5.
I tested on a Lenovo W510 Thinkpad with an “Intel(R) Core (TM) i7 CPU M 620 @ 2.67 GHz” CPU.
Now I am going to test Qt Creator 4.8.2, Qt 5.12.2, LLVM/Clang 7.0.1, MinGW GCC 7.3.0, and Visual C++ 2017.
I upgraded my laptop to a Lenovo A485 Thinkpad with an “AMD Ryzen 7 Pro 2700U w/ Radeon Vega Mobile Gfx 2.20 GHz” CPU.
How many seconds would it take libclang to parse the file? TL;DR? 3 seconds!
Empty (Qt Creator wrongly refers to this as “Default”)
RelWithDebInfo – Release with debug information, needed for profiling / post mortem debugging
MinSizeRel – Release optimized for size, and not for speed.
If we have a look at CMake’s Modules/Compiler/GNU.cmake we can see:
The empty build type usually contains the common build flags for all build types. It is generated from
the CMAKE_C_FLAGS_INIT / CMAKE_CXX_FLAGS_INIT variables, and the CFLAGS / CXXFLAGS system environment variables.
But in the case of an IDE like Qt Creator makes no sense to have, you will end up for GCC with a
-O0 (Debug) build. I’ve opened QTCREATORBUG-22013 in this regard.
Want to enable all possible warnings from the compiler
Lastly, we want to do all this without putting if clauses in the code, and manually changing the CMAKE_<LANG>_FLAGS variables.
The rule of thumb is: if you have to change compiler flags, you should do it in a toolchain file!
At the end of October 2018 on the Qt development mailing list it was announced
that CMake was chosen as the build system (generator) for building Qt6. That also meant that The Qt Company will gradually stop
investing in their in house Qbs build system.
I personally think is a good idea to have major C++ projects like Boost (July 2017 switch announcement! ),
LLVM/Clang, and now Qt to use CMake as their build system (generator). We C++ developers should work together in having a common build system.
There was a bit of email traffic on this topic. There was some skepticism of CMake being able to support specialized operating systems
like QNX, so I pointed to an October 2017 blog entry of Doug Schaefer named QNX CMake Toolchain File.
There Doug Schaefer presents us with a minimal CMake Toolchain File.
Since I am lucky() to have a QNX 7.0 license I tried to compile and run the recently released CMake 3.13.0 for the QNX 7.0 x86_64 target!
At the beginning of this year Bits’n’Bites wrote an article named Faster C++ builds,
in which it’s being described how you can accelerate building LLVM using ninja, using a cache etc.
The following excerpt caught my eye:
For most developers, the time it takes to run CMake is not really an issue since you do it very seldom. However, you should be aware that for CI build slaves in particular, CMake can be a real bottleneck.
For instance, when doing a clean re-build of LLVM with a warm CCache, CMake takes roughly 50% of the total build time!
So I decided to build LLVM 4.0.0 (and clang) on my 2011 Core i7 Lenovo W510 laptop and see if I can reproduce his findings.