Open Folder project - how to build 64bit version

I am trying to add a task to build my "open folder" project in Visual Studio 2022.
The documentation is about this is quite lacking and I can't figure out how to run my build command with build environment set to x64 architecture and MSVC2017 toolset. So far I didn't even get 64bit version of latest 2022 toolset running, it keeps setting 32bit toolset (and yes, I have 64bit version installed, it works when I use command line prompt directly).
I have following task in my tasks.vs.json:
{
"version": "0.2.1",
"tasks": [
{
"inheritEnvironments": [ "msvc_x64" ],
"taskLabel": "DEBUG - QMake",
"appliesTo": "/",
"type": "launch","command": "${env.QT_64_BIT_PATH}\\bin\\qmake.exe", "args": [ "CONFIG+=debug", "-recursive", "${workspaceRoot}\\All.pro" ], "env": { "VSCMD_DEBUG": "20", "VSCMD_START_DIR": "${workspaceRoot}\\..\\bin_debug_win64_msvc" }, "workingDirectory": "${workspaceRoot}\\..\\bin_debug_win64_msvc" }
}
The VS command line tools are run before the command, I can see the debug output of vscmd. But the host/target is being set to x86 no matter what. I have tried to manually add things like VSCMD_ARG_HOST_ARCH/VSCMD_ARG_TGT_ARCH to environment, but it gets overwritten. I can see in debug output that the vscmd is ran without any argument and thus picking x86 as default. What do I have to set in tasks.vs.json to make it pass "-x64" and "-vcvars_ver=14.29" arguments to the tools init script?
JaroslavSmid-6071 avatar image
0 Votes" 0
JaroslavSmid-6071 answered • 0 secs ago
I am using Qt, but I am not using qmake to generate Visual Studio project file. Instead I am using the "Open Folder" project feature of Visual Studio and I want to set it up so that I can build the project using qmake+jom from Visual Studio, without going through generation of VS project files by qmake. Those cannot be modified and converted back, plus we do some specifics in our qmake project files which cannot be translated correctly to project generated for visual studio.
Anyway, the question should be treated as independent of my build system. How do I, in general, set up the task in tasks.vs.json to run the specified command with environment set for building 64bit applications, how do I make Visual Studio to call vcvarsall.bat (which is called automatically before running the command) with "-x64" and "-vcvars_ver=14.29", and not just with no argument at all (note that I do not want to modify original bat file to force it there).
I am sorry that qmake is not supported currently. You can go to Qt forum for support.
I don't think you understand my issue, I will try to clarify.
There is a "Open a local folder" available in Visual Studio (see screenshot https://imgur.com/QIMDE9O and documentation https://learn.microsoft.com/en-us/cpp/build/open-folder-projects-cpp?view=msvc-170).
This opens a folder as some kind of generic project.
This allows me to specify custom C++ configurations, custom build commands and launch settings, ...
My issue is that if I setup the build tasks in tasks.vs.json, vsvarsall.bat is ran automatically (or something similar) before the configured build command, to setup build environment. But this is 32bit build environment and I cannot figure out how to make visual studio to setup 64bit environment, before it launches my custom build command, so that qmake can actually see 64bit tools and not the 32bit. There is no issue with Qt itlself, but with how Visual Studio launches the build command.
Did you try using
qmake
instead ofqmake.exe
? It shows 64bit for me when I usingcl
instead ofcl.exe
.It seems to me that you are doing it different way, than what I am trying to do.
You seem to run qmake and generate standard Visual Studio project, and then compiling that project in Visual Studio.
But I am using "open folder" project and I want to run qmake from there as a tool (and nmake after that), so I can build the application without generating VS project files.
I can just set "notepad.exe" as well as the command and give you debug output of vcvarsall.bat, which is clearly ran before the command, if I configure it there. I can see that x86 architecture is set there.
See here: https://pastebin.com/QP8j9BCB
That is debug output of how visual studio initializes the environment before it runs any command that you define in tasks.vs.json.
These two are important:
If I attempt to set these in "env" list in tasks.vs.json to x64, they are overwritten anyway.
Lines
Say that visual studio is running the batch files with no arguments, thus x86 is picked up.
What I did was follow the tutorial Open Folder and use MSVC as the compiler
"command": "XXX\\cl.exe"
. It can build for x64. Currently, qmake related issues are not supported. You can go to other forum for support.It is not a qmake issue, please stop sending me to Qt forums.
I even tried with notepad. I put notepad.exe as a command and I posted here a debug output clearly showing that MSVC is setting up 32bit build environment for "notepad.exe" command ...
If I set "cl" as the command, the output is "Microsoft (R) C/C++ Optimizing Compiler Version 19.30.30709 for x86"
I have no idea how you made it run x64 version (without giving full path to the compiler), and that is what is purpose of this question. What am I missing in that tasks.vs.json so that Visual Studio sets up 64bit build environment and not the 32bit one. (cl must be resolved as 64bit when looking through PATH by other tools, and so do other build tools).
This in tasks.vs.json:
Causes the environment to be set to x86->x64 crosscompiler for a while, but then it gets overwritten by subsequent call to vcdevcmd.bat by visual studio, reseting it to x86 again (which I can notice in debug output when setting VSCMD_DEBUG to 20.
See here: https://pastebin.com/Yfui9Bg2
The "preinit" part shows that inheritEnvironments has set environment variables to match x86->x64 cross-compiler environment
But the "postinit" part shows environments for x86, because it overwrote everything that "inheritEnvironments" has caused to be set.
This is the default path of cl.exe for your reference:
"command": "C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.30.30705/bin/Hostx64/x64/cl.exe",
Since I am not allowed to use qmake, I can't give suggestion on how to modify qmake.
But then you are really NOT using the environment setup by Visual Studio and directly using absolute path to build command. This is not helpful, because no tool will find this command (be it qmake, or some other random custom tool).
Visual Studio needs to be told somehow to setup PATH correctly to put C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.30.30705/bin/Hostx64/x64/ into PATH and other directories to other different environment variables (INCLUDES, LIBS, ...), (and not by manually setting all of them in tasks.vs.json in "envVars").
What Visual Studio is doing is that it doing equivalent of running "command line toolset" without any arguments before launching a command configured in the json file. (as described here https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170 running with no arguments = 32bit x86 native toolset). What I need it to do is to do equivalent of passing "-x64" argument to the toolset. But there seems to be no way to do this, or I can't just figure out how.
I don't know if this is applicable to Qt, but the docs at open-folder-projects-cpp indicate that CppProperties.json can be used to set the x64 environment.
This works correctly for me for code editing, intellisense, etc, but it has no effect on build environment. I have figured it out while ago, how to do what I need and marked it as answer. Thank you.
Sign in to comment
1 answer
Sort by: Most helpful
I did some more digging and I think I finally figured it out: https://pastebin.com/JnAFFrhg
Setting up "customLaunchCommand" seems to suppress default behavior of running command line tools by visual studio and I can point it to VS tools bat file and using "customLaunchCommandArgs" I can pass required arguments to it. I will then end up with correct x64 native compiller.
Thank you for your time and answers that eventually led me to figuring this out.
Sign in to comment
Activity