Request to implement auto-bootstrapping, iff required

[degski]

Following the addition of VCPKG_ENV_PASSTHROUGH, the build of Boost failed.

Pulling and re-bootstrapping fixes the issue. But vcpkg should have auto-bootstrapping, as soon as a change is merged that requires bootstrapping, vcpkg should just simply rebuild itself before launching into the process [bound to fail].

Until issue #3023 gets implemented, this is particularly annoying, since quite a number of issues are actually resolved just by pulling and bootstrapping.

[OlafvdSpek]

Is pulling necessary? As everything is in one repo a port can't be newer than vcpkg.

[degski]

@OlafvdSpek Well, probably not, what I mean is simply, get the latest repo and bootstrap, iff required.

Basically any change to the vcpkg source code should trigger a bootstrap.

The way I see it, is to hash the source files and store the hash locally. Then, before doing anything, hash the files again, compare to the stored value, iff different bootstrap, store the new value and carry on, iff the same, just carry on.

[heydojo]

This has nothing to do with bootstrapping and to put it more simply appears to involve the update process.
It would appear that the update process now requires some sort of "rebuild the vcpkg binary and/or core files" switch under certain update conditions. As exposed by the failed boost build.

Although, I'd argue that if you are not rebasing a fresh when pulling an update (due to how easy it is to do so in a separate folder) until vcpkg stabilises (it is still very new and is very fast moving) then you should probably focus more on the code you are writing along with creating a viable and realistic update strategy for your project and try to instead focus less on updating vcpkg simply because you randomly "felt" like it IMO. The choice however, is ultimately yours to do as you wish.

[degski]

@heydojo

"rebuild the vcpkg binary and/or core files"

That's what I mean with bootstrapping, it involves running bootstrap-vcpkg.bat, hence the name.

Although, I'd argue that if you are not rebasing a fresh when pulling an update (due to how easy it is to do so in a separate folder) until vcpkg stabilises ...

It will never stabilize ... per definition.

then you should probably focus more on the code you are writing along with creating a viable and realistic update strategy for your project and try to instead focus less on updating vcpkg simply because you randomly "felt" like it IMO.

I do, but I do want the latest fixes in the libraries, pulling those will also pull the updates to the vcpkg-code itself, then there is a need to rebuild. There are other cases like f.e. when I moved from VS2017 to VS2019, where vcpkg wouldn't work unless you update [and bootstrap].

[cbezault]

Hey guys, that was actually a mistake on my part that the build failed without more helpful output.
I should have updated the VERSION.txt file along with my ENV_PASSTHROUGH PR.

Currently when vcpkg detects a change in the VERSION.txt file we let the user know that you should probably re-bootstrap. It wouldn't be too hard to detect a change in VERSION.txt and automatically re-bootstrap when an environment variable is set or you pass a certain flag to vcpkg.

[degski]

@cbezault Naughty, naughty. What I was more thinking of is hashing the relevant source files and re-bootstrap on change. I guess with like a simple CRC32/64 [no need for sophistication] this could be 'almost' unnoticeable and then nothing can be forgotten.

I don't mind having a look/stab at it.

[OlafvdSpek]

How's progress on this one?