Vcpkg: Builds should build both 64 bit and 32 bit on default

[ssylvan]

I mean, really, if there's going to be a single triplet by default it should be 64 bit these days, but it's really more convenient if it just builds both by default so that I can use either target and not have to manually go through and figure out which packages have the wrong architecture and fix them when I need them (e.g. imagine you need 10 packages, and half of them are 64 bit and the other 32 bit.. now neither target architecture for your app will work without 5 manual steps).

So IMO, at least for desktop platforms 32 and 64 bit should build by default when installing a package with no triplet specified.

[degski]

If you define an environment variable for your system and set it to the "correct" value, you'll get what you want every time, without specifying the triplet set VCPKG_DEFAULT_TRIPLET=x64-windows-static, f.e..

I'm not saying there are no other related issues, but this is not one of them. If you don't know how to do the above, go here.

[ssylvan]

I think you misunderstand my point. I know I can set the defaults, and I can pass a triplet manually if I want to change it. That's not the problem.

I'm saying it doesn't make sense to build only one of the two main targets for windows by default when most visual studio projects will normally have to be able to build for both. When I say "vckpg install foo", why would it only install _one_ of the two target platforms most visual studio projects would need to actually use it?

If I specify no triplet, it should build both x86 and x64, and if I only want one, then I should have to opt in to this behavior. This follows the principle of least surprise, because it means you won't end up wanting to use the library in a project and only _then_ discover that one of the two targets won't build. After all, when you create a project in visual studio it'll normally create both x86 and x64 configurations and it's as easy as changing a drop-down to switch between them. Vcpkg shouldn't break that workflow.

[degski]

Yes, I missed your point. Now I do get your point, I, and I suspect many more people, simply disagree with your point of building both. I do agree with "... if there's going to be a single triplet by default it should be 64 bit these days ...", though.

[ssylvan]

My argument is that tools should avoid surprising people as much as possible. And given that VS gives you both x86 and x64 by default, so should vcpkg.

[degski]

I think also there "... if there's going to be a single triplet by default it should be 64 bit these days ..." should apply. I use (my) template projects in VS, they've all got the 32-bit stripped out, so VS does what I want (for me).

[ssylvan]

I mean, if you're making custom template projects, you'd presumably also set the default "triplet set" (or whatever it would be called) to match.

I'm annoyed that as a user I install visual studio and vcpkg and by default things aren't working out of the box. I have to do all this manual busy work for the default VS behavior to play nicely with vcpkg. IMO this "out of the box" experience should be made to work without surprises, and if people want to customize their experience (as you have) they can opt in to it.

[degski]

I mean, if you're making custom template projects, you'd presumably also set the default "triplet set" (or whatever it would be called) to match.

Yeah, and use Clang instead, x64 and /MT and /Z7 and the include/lib paths to tbb/mkl. I.o.w., if I have to do those every time by hand (starting from a default project) I'm going nuts anyway. A bit more promotion (by MS) of the project templates could help many people.

[degski]

As you see, I'm not happy either, why not have clang as a supported compiler as well, f.e.? If you are new to C++, using clang will give you a huge head-start and avoids a lot of abusive language.

[carmangary]

Just my two cents: I don't want to build x86 and x64. I only need x86. Therefore I am opposed to both building both and defaulting to x64. Just wanted to throw this out there since the original poster does not speak for me.

[degski]

@carmangary

I think you're right to say you don't want default x86 and x64 as well, it just shows it's not possible to have a best solution, I just want x64. The OP just wants to make us both happy.

[arthur-tacca]

Perhaps the simplest solution is to never infer the triplet i.e. there is no default. If the triplet isn't specified (with package:triplet notation, or with the --triplet switch, or with the environment variable) just show an error message with a list of possibilities.

[jasjuang]

I agree with 64 bit should be the default these days. I don't agree with building both 32 bit and 64 bit by default. It will take forever to compile.

[KindDragon]

I think that Vcpkg simply has to have an easy way to build all the packages from one toolset for another toolset.

[MikeGitb]

As a note: For VS2019, cmake now defaults to the host platform bitness and so does VS2019 itself when creating a cmake project. Isn't it time that vcpkg made the same transition?

Not sure, why microsoft sticks to x86 so much. The longer you stick to outdated defaults, the more painful it will get when you change them.

Building both versions by default is - as was mentioned- a two sided thing, as it also doubles build times. And let's be honest: The defaults are mainly used by people that "quickly want to try something". Not for production development of a product used by thousands or millions of users.

[degski]

Not sure, why microsoft sticks to x86 so much.

Smaller memory footprint, smaller binaries, better cache locality [i.e. potentially faster, at least not slower] to name a few.

Then there are still users of Windows 10-32 bit [my wife f.e. she's got a 2011 laptop, with good cpu-speed [x64], but only 3GB of ram, in this case it's better for her to run 32-bit Windows], they would not be able to run the x64 software.

[janisozaur]

Can you back your claims regarding performance benefits with actual data? Do you also count in the likely loss of SSE, SSE2, which does not come standard with x86 and has to be explicitly enabled?

I can find plenty of evidence for x86-64 to provide better performance over x86 to be true, so please provide your tests.

[degski]

What's up? Prove what you say yourself.

and has to be explicitly enabled ...

? What did you expect?

[MikeGitb]

@degski:

they would not be able to run the x64 software.

No one is suggesting that microsoft should terminate x86 support (actually, I do think that the support for a 32 bit Desktop OS is a waste of resources, but that is another discussion). But there is a difference between suporting something and making it the default.

Even 9-10 years after x64 became widespread on the desktop market (and they are still unable to provide a 64 bit version of visual studio. The default target platform for non-cmake projects remains 32 bit to this day (at least they create a x86 and x64 target by default). Until very recent, 32 bit was also the default for Microsoft Office. Now they create a new product (vcpkg) and again, the settings default to legacy.

Then there are still users of Windows 10-32 bit [my wife f.e. she's got a 2011 laptop, with good cpu-speed [x64], but only 3GB of ram, in this case it's better for her to run 32-bit Windows],

There are still useres yes, but just because your system doesn't have more than 4GB ram doesn't mean that x32 bit os is the better choice. As I guess you are well aware, there is much more to this than the supported amount of physical memory (new instructions, more efficient ABI and different exception implementation, security mechanisms, more virtual address space). Some time ago, I did some tests with windows 10 in a 2GB VM. I don't remember the exact numbers, but there was not a significant difference in default memory consumption between the 32 bit and 64 bit version and what few benchmarks I ran also didn't show any particular tendency.

Just to throw in a random benchmark: http://www.iinuu.eu/en/it-guru/windows-7-32-vs-64-bit-performance-benchmark

Anyway, I now had my monthly rant about x86 vs x64 - back to my original point: Isn't it time to select the default tripplet based on the host platform?

[degski]

Anyway, I now had my monthly rant about x86 vs x64 - back to my original point: Isn't it time to select the default tripplet based on the host platform?

Why not [the rest of what you write I'll just leave it as it is]?

[MikeGitb]

? What did you expect?

I think the point was, that they are automatically used when compiling for x64 as they are a fixed part of that ISA.

[degski]

I think the point was, that they are automatically used when compiling for x64 as they are a fixed part of that ISA.

But why is that relevant or interesting? Pass the proper (for what you want) compiler flags and life is great! In any software project these are one-time decisions, much less interesting or cumbersome than actually writing and debugging the code. You are barking up a really small tree, it's all a waste of time [and energy].

[MikeGitb]

Does vcpkg set the correct flags? I've seen quite a bit of software, where benchmarks suggest that the developer did not set the same architectural flags for the x86 binary as for the x64 one.

That aside a) I didn't start the whole perf discussion b) as I said: Defaults are used when people want to quickly test something. Not for "Software Projects ".