Toolchain detection Windows SDK amd64

[Wolfgang Baron]

Hi,

I just worked around a bug in Qt Creator 2.6.0 concerning jom or nmake
not finding the compiler for the Windows SDK 7.1 amd64. This happens,
when you want to generate code for amd64 using the autodetected toolchains.

The underlying problem is, that the autodetections uses /amd64 for
initializing the MSVC compiler environment. This should be /x64 instead.

I have not found a way to change this in Qt Creator, so I use a text
editor to edit the file
.../AppData/Roaming/QtProject/qtcreator/toolchains.xml. Changing the
autodetected entry did not help me, as it was overwritten the next time
I started Qt Creator. So you have to clone the entry for amd64 Windows
SDK 7, quit Qt Creator, edit the new entry and start Qt Creator again.
Then you can use your new entry for setting up kits.

I have not found a bug report for this, but maybe I missed it. Has
anybody seen a bugreport or should I post one?

My working toolchain entry is:

<data>
<variable>ToolChain.11</variable>
<valuemap type="QVariantMap">
<value type="QString"
key="ProjectExplorer.MsvcToolChain.SupportedAbi">x86-windows-msvc2010-pe-64bit</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBat">C:/Program Files/Microsoft
SDKs/Windows/v7.1/bin/SetEnv.cmd</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBatArg">/x64</value>
<value type="bool"
key="ProjectExplorer.ToolChain.Autodetect">false</value>
<value type="QString"
key="ProjectExplorer.ToolChain.DisplayName">Windows SDK 7.1 x64</value>
<value type="QString"
key="ProjectExplorer.ToolChain.Id">ProjectExplorer.ToolChain.Msvc:{7afba206-0e0e-4e07-a623-2932c01e21f4}</value>
</valuemap>
</data>

Cheers,

Wolfgang

[Sergey Shambir]

Hello all,

First, thanks to Eric Verbuggen who did perfect clang-based code model
and continues research in git branch. However, as i heard, he also busy
in master branch and v4vm. I'm sure that community can help with clang
initiative, but individual programmers have no enough information about
branch status, problems or interesting tasks and even about any
brainstorm results. Can this gap be filled at qt-project wiki?

There are several questions which will be nice to clarify at wiki:
1) What libclang version is minimal requirement? Clang 3.2 will be
released only in december, but it already has nice API for accessing
doxygen comments and retrieving @brief comments for completion
proposals. Possible solution is macro with LLVM version:
LLVM_VERSION = $$system($$LLVM_CONFIG --version)
DEFINES += "LLVM_VERSION=$$LLVM_VERSION"
but i can't figure out how to convert float "3.1" (returned by
"llvm_config --version") into integer that can be compared by preprocessor.

2) libclang is well designed and documented so clang branch has many
"easy-hack" tasks that can be done by anyone - i mean testing on real
code and fixing small errors/regressions. It will be nice to have
easy-hacks list: missed features, regressions with problematic code and
test for things that already done.

3) What about live diagnostics displaying? Diagnostic message itself can
be associated with QTextBlock,//////// but should it underscore error
like native parser or add items to Issues pan like several other IDEs?

4) Clang is slow, so it's better to document any optimization idea at
qt-project wiki.
- Pch still not used; and there can be some problems with reading
previously generated *.pch - i've seen a few posts on stackoverflow and
failed to read generated pch myself.
- Higlighting can be done for visible area first, as Eric mentioned
once in this maillist
- When user starts typing characters sequence that can be identifier,
IDE can take document snapshot, ask completions at position before first
character and show proposals immediately after 1) they will be ready 2)
user will enter 2-3 characters. Seems XCode uses this trick.

5) Real optimizations can be done only in clang, but interesting
directions can be mentioned at wiki too
- Now QtCreator replaces dot with arrow for pointer types, but it
cannot be done through clang-c API without big overhead. Similar
features: replace dot with :: for namespaces/type names; show mixed
proposals for smart pointers
- Despite that incremental compilation of C++ is horrible challenge,
clang developers mentioned
<http://comments.gmane.org/gmane.comp.compilers.clang.devel/7634>:
"that's certainly a long-term goal"

[Erik Verbruggen]

Post by Sergey Shambir
Hello all,
First, thanks to Eric Verbuggen who did perfect clang-based code model and continues research in git branch. However, as i heard, he also busy in master branch and v4vm. I'm sure that community can help with clang initiative, but individual programmers have no enough information about branch status, problems or interesting tasks and even about any brainstorm results. Can this gap be filled at qt-project wiki?

Good idea! I'll try to do that today. Sneak-peek replies below.

Post by Sergey Shambir
LLVM_VERSION = $$system($$LLVM_CONFIG --version)
DEFINES += "LLVM_VERSION=$$LLVM_VERSION"
but i can't figure out how to convert float "3.1" (returned by "llvm_config --version") into integer that can be compared by preprocessor.

There are now also a libclang (interface) version macros that you can use (CINDEX_VERSION_MAJOR / _MINOR).

Post by Sergey Shambir
2) libclang is well designed and documented so clang branch has many "easy-hack" tasks that can be done by anyone - i mean testing on real code and fixing small errors/regressions. It will be nice to have easy-hacks list: missed features, regressions with problematic code and test for things that already done.

Yup. Anything not in the code or wired up is not done. Exception is indexing, on which I'm hacking away.

Post by Sergey Shambir
3) What about live diagnostics displaying? Diagnostic message itself can be associated with QTextBlock, but should it underscore error like native parser or add items to Issues pan like several other IDEs?

Yes, it tries to do that, but the range conversion is "a bit" buggy. Feel free to fix it :)

Post by Sergey Shambir
4) Clang is slow, so it's better to document any optimization idea at qt-project wiki.
- Pch still not used; and there can be some problems with reading previously generated *.pch - i've seen a few posts on stackoverflow and failed to read generated pch myself.

Long story short: I'll put in the option to use a pch with libclang back in later.

Post by Sergey Shambir
- Higlighting can be done for visible area first, as Eric mentioned once in this maillist

Slightly tricky because of the way highlighting is handled in the text editor (because of performance).

Post by Sergey Shambir
- When user starts typing characters sequence that can be identifier, IDE can take document snapshot, ask completions at position before first character and show proposals immediately after 1) they will be ready 2) user will enter 2-3 characters. Seems XCode uses this trick.

Interestring.. I'll take another look at Xcode.

Post by Sergey Shambir
5) Real optimizations can be done only in clang, but interesting directions can be mentioned at wiki too
- Now QtCreator replaces dot with arrow for pointer types, but it cannot be done through clang-c API without big overhead. Similar features: replace dot with :: for namespaces/type names; show mixed proposals for smart pointers

I had a patch to do the access-operator hinting in libclang, but it's kinda very stale. I might revive that in the near future.

Post by Sergey Shambir
- Despite that incremental compilation of C++ is horrible challenge, clang developers mentioned: „that's certainly a long-term goal“

Yes, I'm aware of that.

-- Erik.

[Erik Verbruggen]

Post by Erik Verbruggen

Post by Sergey Shambir
Hello all,
First, thanks to Eric Verbuggen who did perfect clang-based code model and continues research in git branch. However, as i heard, he also busy in master branch and v4vm. I'm sure that community can help with clang initiative, but individual programmers have no enough information about branch status, problems or interesting tasks and even about any brainstorm results. Can this gap be filled at qt-project wiki?

Good idea! I'll try to do that today. Sneak-peek replies below.

I did a quick brain dump on http://qt-project.org/wiki/wip-clang-todo-items

-- Erik.

[Peter Kümmel]

Post by Wolfgang Baron
Hi,
I just worked around a bug in Qt Creator 2.6.0 concerning jom or nmake
not finding the compiler for the Windows SDK 7.1 amd64. This happens,
when you want to generate code for amd64 using the autodetected toolchains.
The underlying problem is, that the autodetections uses /amd64 for
initializing the MSVC compiler environment. This should be /x64 instead.

/amd64 and /x86 are the same, have a look at vcvarsall.bat:

if /i %1 == amd64 goto amd64
if /i %1 == x64 goto amd64

I assume your real problem is different.

Post by Wolfgang Baron
I have not found a way to change this in Qt Creator, so I use a text
editor to edit the file
.../AppData/Roaming/QtProject/qtcreator/toolchains.xml. Changing the
autodetected entry did not help me, as it was overwritten the next time
I started Qt Creator. So you have to clone the entry for amd64 Windows
SDK 7, quit Qt Creator, edit the new entry and start Qt Creator again.
Then you can use your new entry for setting up kits.
I have not found a bug report for this, but maybe I missed it. Has
anybody seen a bugreport or should I post one?
<data>
<variable>ToolChain.11</variable>
<valuemap type="QVariantMap">
<value type="QString"
key="ProjectExplorer.MsvcToolChain.SupportedAbi">x86-windows-msvc2010-pe-64bit</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBat">C:/Program Files/Microsoft
SDKs/Windows/v7.1/bin/SetEnv.cmd</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBatArg">/x64</value>
<value type="bool"
key="ProjectExplorer.ToolChain.Autodetect">false</value>
<value type="QString"
key="ProjectExplorer.ToolChain.DisplayName">Windows SDK 7.1 x64</value>
<value type="QString"
key="ProjectExplorer.ToolChain.Id">ProjectExplorer.ToolChain.Msvc:{7afba206-0e0e-4e07-a623-2932c01e21f4}</value>
</valuemap>
</data>
Cheers,
Wolfgang
_______________________________________________
Qt-creator mailing list
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Wolfgang Baron]

Hi,

Post by Peter Kümmel
if /i %1 == amd64 goto amd64
if /i %1 == x64 goto amd64
I assume your real problem is different.

No. The fix would not work then, right? In your answer, you are
referring to vcvarsall.bat, which is used for the compiler called
"Microsoft Visual C++ Compiler 10.0 (amd64)". I am talking about the
Windows SDK version called "Microsoft Windows SDK for Windows 7
(7.1.7600.0.30514) (amd64)", as quoted in my fixed entry for toolchains.xml:

<valuemap type="QVariantMap">
<value type="QString"
key="ProjectExplorer.MsvcToolChain.SupportedAbi">x86-windows-msvc2010-pe-64bit</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBat">C:/Program Files/Microsoft
SDKs/Windows/v7.1/bin/SetEnv.cmd</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBatArg">/x64</value>
<value type="bool"
key="ProjectExplorer.ToolChain.Autodetect">false</value>
<value type="QString"
key="ProjectExplorer.ToolChain.DisplayName">Windows SDK 7.1 x64</value>
<value type="QString"
key="ProjectExplorer.ToolChain.Id">ProjectExplorer.ToolChain.Msvc:{7afba206-0e0e-4e07-a623-2932c01e21f4}</value>
</valuemap>

The Windows SDK version of the compiler uses setenv.cmd, which only
knows about x64, not amd64.

I proposed a workaround for a bug in the autodetection. I browsed a
little in the buglists, but did not find an exact match. Before I open a
new Bug, I wanted to know, whether this applies to a bug, which has
already been published. Anyone?

Cheers,

Wolfgang

[Peter Kümmel]

Post by Wolfgang Baron
Hi,

Post by Peter Kümmel
if /i %1 == amd64 goto amd64
if /i %1 == x64 goto amd64
I assume your real problem is different.

No. The fix would not work then, right? In your answer, you are
referring to vcvarsall.bat, which is used for the compiler called
"Microsoft Visual C++ Compiler 10.0 (amd64)". I am talking about the
Windows SDK version called "Microsoft Windows SDK for Windows 7
<valuemap type="QVariantMap">
<value type="QString"
key="ProjectExplorer.MsvcToolChain.SupportedAbi">x86-windows-msvc2010-pe-64bit</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBat">C:/Program Files/Microsoft
SDKs/Windows/v7.1/bin/SetEnv.cmd</value>
<value type="QString"
key="ProjectExplorer.MsvcToolChain.VarsBatArg">/x64</value>
<value type="bool"
key="ProjectExplorer.ToolChain.Autodetect">false</value>
<value type="QString"
key="ProjectExplorer.ToolChain.DisplayName">Windows SDK 7.1 x64</value>
<value type="QString"
key="ProjectExplorer.ToolChain.Id">ProjectExplorer.ToolChain.Msvc:{7afba206-0e0e-4e07-a623-2932c01e21f4}</value>
</valuemap>
The Windows SDK version of the compiler uses setenv.cmd, which only
knows about x64, not amd64.

Does your compiler dialog also list "Microsoft Visual C++ Compiler 10.0 (amd64)?
Then you could use this compiler (or x86_amd64 when you are on a 32bit Windows).
setenv.cmd only maps to these compilers.
Maybe the Windows SDK entries for the compilers are superfluously. Could you check
how many cl.exe versions are on your system?

Post by Wolfgang Baron
I proposed a workaround for a bug in the autodetection. I browsed a
little in the buglists, but did not find an exact match. Before I open a
new Bug, I wanted to know, whether this applies to a bug, which has
already been published. Anyone?

If you can't find a existing report file a new one. There will be some cleanup in 2.7.

I've fixed the autodetection code, could you check if this version works:
https://github.com/syntheticpp/qt-creator/downloads

Peter

[Wolfgang Baron]

Hi,

Post by Peter Kümmel
https://github.com/syntheticpp/qt-creator/downloads

Yes, it works beatifully, the setenv.cmd is now called with /x64, as it
has to be. Thanks for the quick fix!

Cheers,

Wolfgang Baron

[Wolfgang Baron]

Hi,

Post by Peter Kümmel
https://github.com/syntheticpp/qt-creator/downloads

Yes, it works beatifully, the setenv.cmd is now called with /x64, as it
has to be. Thanks for the quick fix!

Cheers,

Wolfgang Baron