Vcpkg: Install x64 packages as default instead of x86

[jasjuang]

I believe nowadays most computers are 64 bit. Is it possible to install x64 libraries by default?

For example:
vcpkg.exe install gflags

This now install gflags_x86-windows, can we change it so it install gflags_x64-windows?

[KindDragon]

You can set system environment variable VCPKG_DEFAULT_TRIPLET=x64-windows

[jasjuang]

Thanks, it works for me

[MikeGitb]

I'm still thinking that x64 should be the default.

[jasjuang]

@MikeGitb I agree x64 should be the default.
@Voskrese Go to control panel -> system -> environment variables to make it permanent

[kklouzal]

I second the notion that x64 needs to be default. At the very least put the information on how to do it in the readme.md

P.S.
I can't thank you guys enough for developing this package.

[VioletGiraffe]

Can't install x64 via vcpkg arguments? Only environment variables? Terribly inconvenient.
Don't want to seem rude or ungrateful, it's great we've finally got a C++ package manager.

[ras0219-msft]

You can definitely choose x64 through command line arguments!

vcpkg install zlib:x64-windows
vcpkg install zlib openssl --triplet x64-windows

This thread is discussing how to make it the default.

[VioletGiraffe]

@ras0219-msft: Now I understand my mistake, thanks a lot (and sorry).

[Xis-Ytneves]

how is anyone to know about the environment variable without stumbling across this page?

[rangershs]

maybe some users still use x86 machine..

[Rogtesh]

Im new to this, how to make this defaults in Win10 Environment Variables? I dont want to mess it up and not sure where i put it. Ive added stuff to path before just never added something like this: "VCPKG_DEFAULT_TRIPLET=x64-windows" to Environment Variables. Im only building in x64 i dont have any x86 compilers and such installed from what i know so it would be nice to have this set as default so i dont need to guess the package name with x64 in it.

[drescherjm]

https://www.architectryan.com/2018/08/31/how-to-change-environment-variables-on-windows-10/

or

https://superuser.com/questions/949560/how-do-i-set-system-environment-variables-in-windows-10

[Const-me]

64-bit builds should definitely be the default. Here’s why: https://store.steampowered.com/hwsurvey/

As you see from the data, 99% of Windows users are running a 64-bit OS.

[MikeGitb]

@ras0219-msft: VS2019 uses x64 as a default for "open folder" and so does cmake, so why hasn't vcpkg caught up (or has it)? The longer it takes, the harder it becomes to make such a change.

[BullyWiiPlaza]

The default is still 32-bit. Any plans on re-opening this issue or making another issue to request the change in defaults? We almost always need 64-bit these days so it should be the default.

[danilogr]

I am new to vcpkg; so, I just spent an hour waiting for boost and opencv to build... Imagine how "happy" I was to find out that everything was x86 ....

Please, if you don't want to make it default to x64, at least give us a heads up the first time we try to install something:

Despite modern practices, vcpkg still installs x86 packages by default. If you are planning on using x64, here are your options....

[olafurw]

At least put it as a part of your bootstrap flow. Ask the question what default you want or print out a help message about this.

This was not a nice thing to discover an hour after installing and setting up a project.

[elgonzo]

Yeah, it's kinda funny. We are writing the year 2020, and vcpkg still defaults to 32-bit builds.

Looks like Microsoft is secretly mourning the bygone era of Windows XP/NT ;-P

[GerwazyMiod]

Well there are worse problems that world is experiencing now, but I've just wasted 30 minutes wondering why my msbuild project can't see vcpkg includes.
Dear vcpkg devs - your project is awesome, but please change the defaults. I know C++ has a big history of choosing defaults the other way around (const? noexcept?), don't be like that. :)

[Greyze]

Add me to the list. My first time ever using vcpkg where I installed 'cereal', a header only library. The guide makes it sound wonderfully easy, even the terminal on setup states:

All MSBuild C++ projects can now #include any installed libraries.
Linking will be handled automatically.
Installing new libraries will make them instantly available.

Of course when I loaded Visual Studio to use it, it didn't work at all -_-
After googling for a while I found this page and saw that it defaulted to an x86 folder.
It's an amazing tool really. But considering x64 is basically the standard these days that should either be the default, or you should add at least one extra sentence to the readme saying "To use x64 libraries, append to the command --triplet x64-windows"

[MikeGitb]

Given the last response is over two years old, I wonder if the maintainers actually see new messages in this thread or if it's just a > /dev/null to write here

[BullyWiiPlaza]

@MikeGitb: They're on Windows so all replies in this issue are redirected to > NUL :)

[linquize]

I also think x64 should be the default.

But Microsoft is still shipping 32-bit binaries in many parts of Visual Studio, such as cmake, git, node, vswhere, nuget, ...
Also, vcpkg.exe is still 32-bit. It downloads many 32-bit tools, cmake, ninja, git, 7zip, powershell-core, perl, ...
ninja is an exception, because the official website offers 64-bit only.
When you create a C++ project (Windows console app) in Visual Studio 2019.5, the default platform is still x86.

[plq]

My impression is that in the Windows world the saying goes: "Use 32-bit mode unless you have a good reason to switch to 64-bit", hence everything defaults to 32-bit. When you think about it, it's not a wrong line of reasoning: 32-bit programs are smaller, more memory-efficient and sometimes faster by being more cache-friendly. So it's not about the market penetration of the 64-bit cpus or anything else. If you need to map >3gb of memory, or you need faster numerical operations, sure, switch to 64-bit. But otherwise, 32-bit is actually the better alternative. The 32-bit parts of the Windows OS are not going anywhere anytime soon anyway.

So the motto is: just use 32-bit unless you have reason not to. Hence this default. Right, microsofties?

[MikeGitb]

If you need to map >3gb of memory, or you need faster numerical operations, sure, switch to 64-bit. But otherwise, 32-bit is actually the better alternative. 

That would be true, if x86 and x64 would have the exact same ISA, ABI otherwise (I.e. like x32). But x86 on windows has several other disadvantages that have nothing to do with the size of the addressable memory (fewer registers, different calling convention, frame vs table based exceptions, even optimizer seems to work differently). Also, even if the additional memory itself isn't used, the bigger address space provides other opportunities (less fragmentation, various sanitizers, better address space randomization). Finally of course this division in the eco systems comes with secondary costs (more different architectures to test with, more storage space needed, compatibility issues).

In addition, you can reduce the size overhead significantly by simply using more efficient datastructures (std::list is almost always a bad choice on modern systems regardless of 32 vs 64 bit pointer size and for a std::vector, the overhead gets amortized over the elements in the vector).

Especially on the compatibility side of things life would be so much easier, if MS and in particular the msvc team embraced x64 instead of dragging their feet. And I think a much better motto would be to use x64 unless you have a very good reason (meaningful benchmarks) to do differently.

[plq]

So what I'm saying (that 32-bit programs tend to be smaller and more memory-efficient) is not true because ... there are less registers in the x86 instruction set, or the stack layout is different?? Seriously? I don't follow this line of reasoning at all, sorry mate.

Maybe I was misunderstood, though I don't see how, so I want to clarify: I wasn't arguing that x86 has the superior instruction set, or real programmers don't need sanitizers :) I just said the MS people seem to think that 32-bit is a good default and here are a couple of reasons why that might be. Defaults are defaults, they are not for people who, like yourself, care about the number of registers their target architecture has. They already offer a nice way to change it, so ... ?

With this said, if, for some reason, you can't permanently add the suggested environment variable, maybe you can use the following script after bootstrapping vcpkg:

vcpkg.bat:

@echo off
IF "%1"=="install" ( set TRIPLET=--triplet x64-windows ) ELSE ( set TRIPLET= )
vcpkg-x86.exe %* %TRIPLET%

Don't forget to rename vcpkg.exe to vcpkg-x86.exe for this to work.

[MikeGitb]

So what I'm saying (that 32-bit programs tend to be smaller and more memory-efficient) is not true because

I added the part I was responding to.

[aalmada]

Yesterday I used vcpkg for the first time. It still defaults to x86-windows...

[MikeGitb]

I really hate to be that guy, because I know the comparison is unfair, but still: Apple managed to first switcht to 64Bit only and now to ARM, before Microsoft manages to even consistently default to 64 bit.

[linquize]

Already stopped selling OEM 32-bit Windows.

[MikeGitb]

And I was glad to hear it, although that doesn't mean all that much as long no date for the end of support for existing installations (and retail versions) has been been anounced. But I'll stop commenting on this now. Microsofts general 32/64 policy is one of my trigger topics on which I could rant on for pages, but likely nothing the maintainers here can do anything about (assuming they even read this thread), so I don't want to derail any further from the concrete and actuable suggestion here:

Please, Please, make x64 the default for vcpkg packages on windows to be in line with the default behavior for CMake projects. The longer you wait with that change, the more people you will break when it happens.

[JPTIZ]

My suggestion would be: get the current system's default. Seems to be the most intuitive to me. You're in a x64 system? Defaults to x64. You're on a x86 system? Defaults to x86.

Maybe I should make this suggestion a new issue?