Qt Creator 4.8.0正式发布

我们很高兴地宣布Qt Creator 4.8.0正式发布了！

编程语言支持

我们添加了对语言服务器协议（LSP）的实验性支持，这为Qt Creator增加了对多种编程语言的基本支持。

Language Server Protocol support in Qt Creator 4.8

语言服务器协议是连接编辑器或IDE和某种编程语言之间的标准化的桥梁。它让编辑器和IDE可以轻松支持某种编程语言：只要该语言能提供一个使用该协议的服务端程序。任何实现了该协议客户端的编辑器都能获得该编程语言的代码自动完成、代码跳转和代码诊断等功能。当然从另一个角度来说：实现了编程语言协议客户端的编辑器会自动获得多种编程语言的基本支持。现在已经有许多编程语言的语言服务器的实现。您可以在官方LSP网站和社区网站上找到这些实现的清单以及它们的状态。

要在Qt Creator中设置语言服务器，首先需要在“帮助”>“关于插件”（在macOS上是“Qt Creator”>“关于插件”）中启用“LanguageClient”插件。然后打开“选项”>“Language Client”选项，添加语言服务器的可执行文件，并指定要使用该语言服务器打开的MIME类型或glob模式，以及服务器需要在命令行上传递的所有参数。

Qt Creator目前支持代码补全，语法高亮，符号定义跳转以及集成来自语言服务器的诊断信息。代码高亮是通过通用高亮器（highlighter）完成的，因为语言服务器协议不提供这个。

对C++的支持

我们将Clang code model更新到LLVM 7.0。我们还为auto关键字实现了Follow Symbol，选中的函数现在可以自动补全提示可用的重载。您可以使用新的“构建”> “Generate Compilation Database”，将代码模型中关于您项目的信息作为编译数据库（compilation database）导出。

还有几个新的实验性插件：

编译数据库项目（Compilation Database Projects）

启用CompilationDatabaseProjectManager插件后，您可以在Qt Creator中将编译数据库作为项目打开。编译数据库基本上是一个文件列表和用于编译它们的编译器标志。一些构建系统和工具能够生成此类数据库以供其他工具使用。这可以替代使用Generic Project，因为它可以更好地提供编译器标志的相关信息以及代码模型的include路径。

基于Clang Format的缩进

通过LibFormat进行自动缩进，这是Clang Format使用的后端。启用ClangFormat插件就可以试用。

Cppcheck诊断

将工具Cppcheck生成的诊断集成到编辑器中。启用Cppcheck插件来试用。

调试

Qt Creator 4.8支持同时运行多个调试器。调试模式下的调试工具栏多了一个弹出菜单，您可以在其中切换正在运行的调试器实例并切换调试器的“预设”视图，这样会启动新的调试器。每个正在运行的调试器实例还维护自己的一组视图（Locals，Watches，Stack等）及其布局。

获取Qt Creator 4.8.0

开源版本可在Qt下载页面上找到，您可以在Qt Account Portal上找到商业许可的软件包。Qt Creator 4.8.0也可通过在线安装程序中的更新获得。请在我们的bug tracker中发布问题。您也可以在chat.freenode.net上的#qt-creator和Qt Creator邮件列表上的IRC上找到我们。

Don't forget to share this post!

Subscribe to Our Blog

Stay up to date with the latest marketing, sales and service tips and news.

I want the latest in...

Email*

Country*

M ↓ Markdown

Kai Mast

0 points

92 months ago

Why not CMake, Meson, or automake? There are so many build systems out there already.

Jake Petroules

0 points

92 months ago

Two reasons: existing build tools don't meet our needs, and we can bring innovation and productivity enhancements to an area that sees relatively little innovation because of doubtful outlooks like this. There's also many aspects to build tool development that may not be evident to the average developer, unless you're also a build tool developer.

The build tools you mentioned are actually rather low-level tools (meaning they only provide the bare minimum) whereas Qbs is a much higher-level tool which provides richer functionality.

I'd suggest reading the comments from the last blog post to get an idea of the why: http://www.qt.io/blog/2017/..., to avoid repeating the same answers again and again.

Zack

0 points

92 months ago

When does the development of QBS started?

Jake Petroules

0 points

92 months ago

Development of Qbs began around 2011-2012.

tr3w

0 points

92 months ago

Sometimes I wonder if people also asked the CMake guys: "Why not automake?"

It's also funny to list meson: it's actually younger than QBS.

Kai Mast

0 points

92 months ago

But people actually use Meson.

Ernst Winthrop

0 points

92 months ago

So the people who use Qbs don't exist because you say so. Right...

Ronnie

0 points

92 months ago

Now that the world (including Microsoft) seems to have settled on CMake, I'm not sure if there's a place for yet another buildsystem. I'll grant that Qbs deserves a fair trial and I'll evaluate it in due time, but I strongly believe that for it to be any successful it needs to be decoupled from Qt and get its own website, community and so on (like Kitware did for CMake). Are there any plans in this direction? Otherwise, Qbs will always be "... oh yes that thing that comes with Qt" (like Qt Creator now is).

Jake Petroules

0 points

92 months ago

The "world" settling on CMake is debatable - Microsoft supports it but it has by no means displaced or replaced MSBuild in their official tools, same goes for CMake remaining secondary to Gradle in the Android world, and it's non-existent in the Apple world save for the Swift project, which probably only chose it because of LLVM). On Linux... yes, it's probably effectively standard, but that's not the only platform we have to care about.

You're completely right that decoupling Qbs from Qt will be a major factor in its adoption and success, which is why we've designed it from the ground up to be toolkit and programming language agnostic.

As far as its own website, this is something we've talked about and is on my personal agenda to address in some way but we don't currently have any official plans or timeline on that.

To be honest, I think it would be quite difficult to build a separate community from the Qt Project if we were interested in doing that, since that's not something you can just "do". It has to grow organically to a certain extent, and trying to maintain a separate set of technical infrastructure from codereview.qt-project.org and bugreports.qt.io is probably not worth it (at least as it seems right now). Consider other examples in the industry - the Apache Software Foundation was born out of the original Apache HTTP Server project, and grew to support a large number of other projects as well, none of which have a "stigma" of attachment to httpd. Remember, qmake always was directly and heavily tied to Qt. It's not particularly useful for non-Qt or non-C++ projects. Qbs on the other hand is starting from a completely different path and outlook. I think it's fine for Qbs to live under the umbrella of the Qt Project, and there's no reason a sub-community couldn't exist and grow within that framework.

But its own website and logo? Definitely!

Jean-Michaël Celerier

0 points

92 months ago

> The "world" settling on CMake is debatable – Microsoft supports it but it has by no means displaced or replaced MSBuild in their official tools, same goes for CMake remaining secondary to Gradle in the Android world, and it's non-existent in the Apple world save for the Swift project, which probably only chose it because of LLVM). On Linux… yes, it's probably effectively standard, but that's not the only platform we have to care about.

You are saying that this is debatable but this is already more than any other single cross-platform build system.

JetBrains did a survey and CMake came out in front of makefiles in usage: https://www.jetbrains.com/r... at more than 1/3rd of developer marketshare.

Likewise for MS : https://blogs.msdn.microsof...
" In our developer surveys, we have seen CMake constantly grow in usage year over year since 2012, surpassing in 2015 the make family (make/gmake/nmake) in terms of adoption."

Even boost is migrating!

What would it take for you to accept that yes, the world indeed settles on CMake ? 50 % of usage ? 70 ? 90 ? Nothing ever gets such a marketshare in infrastructrure tooling like but everything would be so much more simpler if new alternatives weren't added every two years instead of improve the existing ones.

Chris

0 points

92 months ago

The world had settled on gcc, then came clang....
The world had settled on apache, then came nginx...
The world had settled on MS Windows, then came Linux... (caugh, caugh, caugh....)
etc, ...

Thomas

0 points

92 months ago

For me, this sounds like the desperate search for arguments against innovation, just because the world seems to have committed to something. However, it's part of the human nature to constantly question things and develop new and better solutions. Good is good, but better carries it.

Jean-Michaël Celerier

0 points

92 months ago

Maybe I was not clear enough, but I am not at all against the QBS language itself. The language is nice even if in my personal opinion declarative build systems are only good for small projects which don't do too much code generation & special cases depending on the target platforms.

What fills me with despair is restarting from scratch where all the progress that was made in cross-platform compatibility in CMake is lost; all the "find" modules, all the platform agnostic ways to set flags such as link-time optimization, PCHs, etc. There have been loads and loads of discussions on the CMake list of introducing another language on top of the CMake software that would fix cmake-lang's quirks and a good enough proposal would certainly be envisaged for inclusion in CMake; a LUA proposal went quite far IIRC. But no, people have to start from scratch so that it scratches their own itches while contributing to an existing project could have had the exact same outcome in term of end-user experience, but with much less stuff to reinvent and greater compatibility with the existing ecosystem.

The other commenter takes the example of clang and GCC, but the first thing that clang did was copying most of GCC's flags and behaviour so that the transition would be seamless ; and even still, clang is far for replacing GCC due to the ginormous amount of work to do, especially in terms of supported architectures and raw performance with max optimizations.

Likewise, sure, use nginx for the quick stuff, until you need to use one of the thousands extensions that only apache has, for instance for GIS, etc. Yes, the "hands-on" experience is much better, but the overall ecosystem ends up being divided and now most people have to learn both Apache and nginx.

Jake Petroules

0 points

92 months ago

All of those who speak about "just" adding a new language frontend to CMake are not realizing that the front-end language is not the only issue. In fact, it's probably not even the most important one. Replacing CMake's language would not solve any of the inherent problems.

The CMake engine is fundamentally geared towards Makefile generation. Yes, I know there are other generators, but it was originally designed around Makefile generation and still retains the inherent limitations of Makefiles in its design philosophy. This has implications for both speed (and no, Ninja does not just let you wave a magic wand and see all of these problems fly away) and flexibility (there are certain constructs that make cannot express or makes very difficult to express).

I strongly believe that any build system that doesn't make some form of multiplexing and aggregation functionality available (like Qbs 1.9, Gradle, and Xcode) is inherently limited in terms of real-world usage with the platforms that are relevant to us today and therefore a non-starter. That's why virtually no one uses CMake for iOS or (full) Android projects. Yes, I know CMake supports Android, officially even, but only a small part of the process is handled by CMake, Gradle handles the vast majority because CMake just isn't capable.

I'm also not sure why you think declarative based build systems are only well suited for small projects or why code generation has anything to do with it. Code generation is one of Qbs's greatest strengths. We use this very extensively in the built-in modules. Can you give us an idea of what is a "small" and "large" project in your eyes? We're using Qbs to build Qt Creator, which is a pretty decently sized project, and are porting Qt to use it, which is quite sizable.

I also disagree with your counterargument to the previous commenter's statement "first there was gcc then came clang". Yes, Clang has not replaced GCC yet but it is quickly happening and it will continue to happen for the foreseeable future. Clang might not have replaced GCC yet but for all we know, Clang may take virtually all of its market share at some point in the medium-term.

The status quo does not get a free pass against innovation simply because it is the status quo. Good is good, but better carries it.

GreenWolf

0 points

92 months ago

Is it possible to create Android and iOS applications ?

Jake Petroules

0 points

92 months ago

It is. Ensuring good support for these platforms is a major goal of Qbs and was actually one of the primary driving reasons behind the two major features announced in this post.

In the future we will improve our documentation to talk specifically about how to target these platforms using Qbs and how to take advantage of the relevant features to their fullest extent (QBS-1183).

Markus

0 points

92 months ago

I am currently using qmake for everything, and quite many details of my qmake files come from the examples which are delivered with Qt. The major reason why I never tried cmake is because I don't have a corresponding set of cmake examples with Qt. Searching the currently delivered examples (Qt 5.9.1) there is not a single qbs files inside :-(

I would suggest to add qbs files (additionally to the existing qmake .pro files) to at least some of the example files, in order to demonstrate how a user can benefit from qbs.

What about e.g. a qbs project file for "Same Game" which includes deployment to any supported target platform including Android, and a project file for "Qt notifier" ? I believe these two alone would not cost you too much time, and would give any Qt Android developer absolutely enough information to start using qbs!

Jake Petroules

0 points

92 months ago

This is in progress for all Qt examples. Unfortunately I can't give you any date by when we might be finished.

Uwe

0 points

92 months ago

Yes, like Markus I have to say that good examples or the use of qbs in the Qt examples or in Qt real world projects would be the key for me to start switching over from qmake to qbs. I would really like to do this :O)

Chris

0 points

92 months ago

Good job, can't wait to give it a try!

I think that people yelling "CMake, CMake, CMake" should give qbs a try, they will then understand how Qbs is way superior to CMake.

Have you plan to provide "helpers" for creating linux and windows installers? say based on QtIFW?

Jake Petroules

0 points

92 months ago

Thank you for your support!

We actually already do support building Windows installers - there are dedicated modules for:

Inno Setup - https://doc.qt.io/qbs/innos...
NSIS - https://doc.qt.io/qbs/nsis-...
WiX - https://doc.qt.io/qbs/wix-m...

Qt Installer Framework support will come in a future release and is being tracked here: https://bugreports.qt.io/br...

NoName

0 points

92 months ago

Why a new build system and not CMake? CMake is already a robust cross platform build system. Why do you want to reinvent the wheel?

Jake Petroules

0 points

92 months ago

Ironically, CMake has very little Android support despite the fact that Android Studio uses it by default for native code. CMake has little to no support for most features on Apple platforms other than compiling and linking C++ code, and only very basic support for bundles. You have to write long, complex toolchain files to target any cross-compile environment, even ones (like iOS and Android) which are quite well known and shouldn't require users to do that. Its language has a bizarre grammar that's difficult to read and reason about. You need to be a build expert to use it. Everyone who uses it uses it only because it's the status quo, and it's mostly hated or disliked. That's why not CMake.

There's absolutely nothing wrong with reinventing the wheel (in fact the literal wheel actually has been reinvented numerous times throughout human history for varying good reasons). It's about knowing when and how, and for Qbs... the time is right.

Jean-Michaël Celerier

0 points

92 months ago

> Ironically, CMake has very little Android support despite the fact that Android Studio uses it by default for native code. CMake has little to no support for most features on Apple platforms other than compiling and linking C++ code, and only very basic support for bundles. You have to write long, complex toolchain files to target any cross-compile environment, even ones (like iOS and Android) which are quite well known and shouldn't require users to do that.

And how much time would have it taken to just add the missing bits to CMake instead of doing a build system from scratch ?

> You have to write long, complex toolchain files to target any cross-compile environment, even ones (like iOS and Android) which are quite well known and shouldn't require users to do that.

https://cmake.org/cmake/hel...

if this is "long and complex" we seriously have other problems:

set(CMAKE_SYSTEM_NAME Android)  
set(CMAKE_SYSTEM_VERSION 21) # API level  
set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)  
set(CMAKE_ANDROID_NDK /path/to/android-ndk)  
set(CMAKE_ANDROID_STL_TYPE gnustl_static)

you have to be able to set this with QBS too at some point, else you will be limited in some way or another, be it performances, targeted devices, etc. Also Qt only supports android-clang in git while CMake had support for it for the last few versions.

Jake Petroules

0 points

92 months ago

> And how much time would have it taken to just add the missing bits to CMake instead of doing a build system from scratch ?

Well, once you run into architectural limitations like I mentioned in my other comment, you have to start from scratch anyways. I don't think extending CMake makes sense. It's not the kind of legacy you want to carry forward if you can help it. Take the Mac OS 9 to Mac OS X transition as an example. Sure, they could have extended Mac OS 9 and fixed all the problems, but it was much easier to go with a solid design foundation (Unix) and add backwards compatibility from there.

> https://cmake.org/cmake/hel... if this is "long and complex" we seriously have other problems:

And that's fairly new, and is a good step forward. However, what about compiling the Java code, generating AIDL files, assembling the APK, code signing, resource compilation, product flavors and multi-arch APKs etc, etc? CMake cannot do any of that, which is why it only has a very small role in the Android ecosystem and Gradle does most of the work. Qbs takes on all of the responsibility of both Gradle and CMake, and is therefore a much better choice for cross platform applications.

> Also Qt only supports android-clang in git while CMake had support for it for the last few versions.

Qt is a library, CMake is a build tool (unless you meant to say qmake?). The reason Qt and qmake only support Clang in Git is because Clang has had some issues with binary size preventing it from adopting it as the default configuration, so it hasn't been a priority. Same reason why Google hasn't completely removed GCC and libstdc++ from the NDK just yet. Once they do so, we'll probably switch over.

Richard

0 points

92 months ago

CMake is a mess of a build system with poor usability and an error-prone language. When not using it on a daily basis, you will likely forget everything very soon. Not so with Qbs. It uses a very elegant and easy-to-remember declarative DSL (QML) where users can focus on WHAT they want to build rather than HOW. That's really an innovation. Funny enough: Qbs made me understand how GNU Make is supposed to work.

nrw

0 points

92 months ago

First. I tried to activate precompiled headers and received error: Property 'precompiledHeader' is not declared. Qt Creator 4.4.0, Qbs 1.9.
Second. As i remember in "options->build and run->qbs" there used to be an opportunity to add new options. Now its impossible.

Jake Petroules

0 points

92 months ago

As mentioned in the post, precompiled headers are now activated by default. Just add the file tag "cpppchsrc" to your .pch file. See the cpp module documentation for more information.

Secondly, that option moved to "Options > Build & Run > Kits > [Kit] > Additional Qbs Profile Settings; the same functionality is still there, just in a different place.

N.A

0 points

92 months ago

Love to use Qbs in the future when it's mature. Seems that happens when Qt 6 is released and i don't know when it's going to happen. I think one fascinating feature of Qbs is it's syntax which is like QML. It's incredibly easy to read and remember.
Thank you for your good work.

Chris

0 points

92 months ago

Adding Qbs to yocto shouldn't be such a big issue. You "just" need to create a yocto "Qbs class", which is not a difficult job.
Having say that, Qbs is not yet used much around, so i would say that "need" will drive this.
Qbs is very "flexible", which is IMHO it's weakness too. There is no "One way" to use Qbs.

"The Qt Company" already contributes to yocto (meta-qt5, boot2qt, ...), so if Qt-6 switch to Qbs then expect a qbs base class from meta-qt6.

Anyway, being a bit negative here:
I have been complaining for years about yocto focusing on Qt3 and Qt4. Yes that's right, yocto's priority is about supporting the so-called "industry needs", outdated guys still developing with Qt3 in 2017, just because the 'biz' guys are brain-less short-sighted money-driven morons..... [1]

Getting a bit out-of-scope here, but The Qt Company has made some move (recently), and meta-qt5 has improved thanks to the Qt community/company . My guess (hope) is that meta-qt6 will be an even better "The Qt company"/"Linux foundation" collaboration.

My 2 cents.
Chris

[1] https://www.mail-archive.co...
Last commit to meta-qt3 was on 2016-08-29, a year ago!

Jake Petroules

0 points

92 months ago

> Qbs is very "flexible", which is IMHO it's weakness too. There is no "One way" to use Qbs.

Can you elaborate? I haven't seen this come up before and I'd argue that that supposed "problem" is far, far worse with CMake.

Mikael Kjaer

0 points

92 months ago

Any word on the status of a Yocto/OpenEmbedded integration for QBS. It is the only reason why I haven't moved my research projects over to QBS yet is that I would have to add support for QBS to Yocto myself, because otherwise QBS is superior to QMake already especially for crossplatform projects. It might just be me that hasn't quite understood how to do it, but I am guessing with the Embedded focus at the Qt Company this is at least something you're looking at down the road.

Jake Petroules

0 points

92 months ago

We've discussed this recently and plan to look into it at some point. The issue is being tracked in JIRA as QBS-1188.

Adrien Leravat

0 points

92 months ago

Thank you, keep the good work! Despite the relative lack of documentation and very limited IDE integration (yet), I like very much using Qbs in projects, it is quite refreshing. It offers huge possibilities while keeping things so simple, and I bet this will make a difference.

Christian Kandeler

0 points

92 months ago

IDE-wise, there is a bit of work to do in the wizards area. Otherwise, if you see shortcomings in the IDE integration, you might want to file a task at bugreports.qt.io.

nrw

0 points

92 months ago

Maybe I do not understand something, but now qbs does not allow you to create more than two precompiled headers in the same project and produces an error:
Output artifact '...gch' is to be produced from input artifacts 'file1' and 'file2', but the rule is not a multiplex rule.

Christian Kandeler

0 points

92 months ago

Do you mean in the same product? That has never been supported, though I suspect it would be doable now. Can you file a bug report?

Igor

0 points

92 months ago

I am trying to build dmg with a new mechanism, but have next error:
The process 'dmgbuild' could not be started: execve: No such file or directory.

Could anyone help me?

Jake Petroules

0 points

92 months ago

This is a known issue in Qt Creator 4.4.0. You can either use the command line version of Qbs, which doesn't have this issue, or wait for Qt Creator 4.4.1 when it will be fixed.

Please see https://bugreports.qt.io/br... for details and a workaround.

Igor

0 points

92 months ago

Thank you. It works.

But could you explain how can i embed "macdeployqt" tool into the product build process? Early i had next steps for this:

1) "$QBSEXE" build -d "$BUILDDIR" -f "$PROJECTPATH" -p "$BUILDPRODUCT" --jobs 4 profile:"$QTPROFILENAME" qbs.architecture:x8664 release
2) "$QTBINPATH/macdeployqt" "$BUILDDIR/release/install-root/$BUILD_PRODUCT.app" -dmg -qmldir="$SCRIPT_PATH/app/qml"

Jake Petroules

0 points

92 months ago

In the long term, we have no intention of allowing macdeployqt to be used as part of a Qbs build process, since Qbs will provide its own features that completely replace macdeployqt.

For the time being, you should be able to create a Rule that takes artifacts tagged "installable" as inputs and invokes macdeployqt on an app bundle that was installed using the Qbs installation mechanism.

Merc

0 points

92 months ago

Either QBS or its documentation is incomplete.
1. Does QBS support multi-core CPUs?
2. How to set specific EXE fields like product name and copyright string.
Thus I didn't bother.

Jake Petroules

0 points

92 months ago

Qbs absolutely supports multi-core processors, this is a fundamental part of its design and quite frankly of any build tool (I'm not sure of a build tool that doesn't support multi-core processors). That said, we'll add a note about it in our documentation.
You create a .rc file with the proper fields and add it to your product's files list, and Qbs will compile it into your EXE. In the future we'll look into providing a set of dedicated properties to allow you to use Qbs to generate .rc files with these fields automatically.

Magnus Andersson

0 points

92 months ago

Qbs looks like an interesting build system. A good build configuration language is a key feature, and I think that Qbs has that. Fast incremental builds is another key feature, and it seems to be in place as well. However, for large code bases remote execution and caching (that is, the possibility to build in a cluster and cache artifacts) become important. Are there any plans to add these features to Qbs?

Jake Petroules

0 points

92 months ago

This is something we've talked about internally but there are no concrete plans yet. In general though it should be possible to use Qbs with tools like distcc or icecream via the cpp.compilerWrapper property. Perhaps that's something we can add to the FAQ.

Magnus Andersson

0 points

92 months ago

I think that the support for remote execution and caching in Bazel, is why Bazel will have an edge over Qbs for non-Qt users with large code bases. But these are complex features which are not needed for smaller projects (most users?), so I see how Qbs will be able to thrive without them.

My company has a code base of ~10 000 .c files, and we build very large binaries. Is there any reason for us to choose Qbs over Bazel?

Commento

Qt Blog

Categories

Archives