vcpkg install Auto update sha512

[autoantwort]

Add an option so that sha512 hashes are automatically updated when they are wrong.

When being a port maintainer updating the hashes can be one of the most annoying and time consuming parts.

Depends on microsoft/vcpkg#19679

[strega-nil-ms]

Also, this is an awesome idea and I'd love to see it be further worked on. This is such a nice feature for our users.

[strega-nil-ms]

nits :)

[BillyONeal]

The maintainers looked at this in person today and have the following feedback:

• We agree that updating SHAs is painful and would like to improve that experience.
• Long term, we would like the things that have SHAs to be declared in some form of .json file next to portfile.cmake so that SHAs can be updated without needing to pass through arbitrary build systems and/or wrappers. Note that this can't be vcpkg.json because we want people to be able to check those in to their own repos and they can't name their own SHAs (hopefully :) )
• In the meantime we would accept an intermediate solution like this but would like to see the "transportation" for the SHA go through some known file name in buildtrees rather than stdout mixed with other arbitrary build system output. (Compare to vcpkg_abi_info.txt)

[autoantwort]

In the meantime we would accept an intermediate solution like this but would like to see the "transportation" for the SHA go through some known file name in buildtrees rather than stdout mixed with other arbitrary build system output. (Compare to vcpkg_abi_info.txt)

I first also planned to do that. But I have not found a way to get a stacktrace in cmake except with message(WARNING ...). Why do I need a stacktrace? Because I want to get the location from where the function was called to replace the SHA there. Then I don't have to go through over 2000 files to search for a string for each SHA and I don't have the problem that it does not work for the SHA 0. I can not simply replace a 0 in a file and even not SHA 0 because there can be multiple occurrences of SHA 0.

[BillyONeal]

I first also planned to do that. But I have not found a way to get a stacktrace in cmake except with message(WARNING ...). Why do I need a stacktrace? Because I want to get the location from where the function was called to replace the SHA there. Then I don't have to go through over 2000 files to search for a string for each SHA and I don't have the problem that it does not work for the SHA 0. I can not simply replace a 0 in a file and even not SHA 0 because there can be multiple occurrences of SHA 0.

It was my impression that this was intended to update SHAs, not for authoring new ports; and for an update plain grepping the old SHA and replacing it with the new one should work.

It's a risky business attempting to machine parse output that was never intended for machine consumption as the tools in question don't treat it as contractual. CMake stack traces certainly qualify as "never intended for machine consumption" as far as I know.

[Neumann-A]

CMake stack traces certainly qualify as "never intended for machine consumption" as far as I know.

ask the meson guys ;)
you can run vcpkg with --x-cmake-args=--trace(-expand) --x-cmake-args=--trace-format=json-v1 combine with --trace-source= or --trace-redirect= however you want.

[autoantwort]

It was my impression that this was intended to update SHAs, not for authoring new ports;

When I create a new port I also have to update SHAs, so this was definitive a target use case.

and for an update plain grepping the old SHA and replacing it with the new one should work.

Not always. For example when I create a new port, I normally just copy an existing port and rename stuff. If I then run vcpkg with --x-auto-update-sha512-hashes and do simply grepping, it would replace the wrong SHAs.

It's a risky business attempting to machine parse output that was never intended for machine consumption as the tools in question don't treat it as contractual. CMake stack traces certainly qualify as "never intended for machine consumption" as far as I know.

Probably true, but this is only a convenience feature under an experimental flag. So if it would break one day that would be not the end of the world. (I personally don't expect that and even if I expect that it should be possible to change the parsing code without a big effort)

[wrobelda]

@BillyONeal @autoantwort any chances of this being eventually merged? It helps tremendously when collectively updating the KF5 frameworks.

[BillyONeal]

@BillyONeal @autoantwort any chances of this being eventually merged? It helps tremendously when collectively updating the KF5 frameworks.

I think the concern about relying contractually on something that doesn't appear to be a contractual thing remains.

[autoantwort]

@BillyONeal When I use a separate file should the hash mismatch message still displayed? I think we should remove the message then to avoid confusion.

[BillyONeal]

@BillyONeal When I use a separate file should the hash mismatch message still displayed? I think we should remove the message then to avoid confusion.

I don't have any opinion on this one.

[wrobelda]

Is this still planned for inclusion? It saves tremendous amount of time when mass-updating ports, like I do for KF5 frameworks.

[BillyONeal]

Is this still planned for inclusion? It saves tremendous amount of time when mass-updating ports, like I do for KF5 frameworks.

I believe the status on this is that we would still love the feature but are still concerned about (1) reading intended-for-humans output in a way that makes it machine-contractual, and (2) arbitrarily interspersing that output in stdout. Or are those concerns addressed now?

[BillyONeal]

@markle11m @valeriaconde @ras0219-msft @vicroms @dan-shaw @JavierMatosD and I discussed this again today and affirmed that we aren't comfortable building commands that mutate the sources based on non-machine-readable output such as the CMake stack trace.

@ras0219-msft observes that you can build similar behavior outside of vcpkg by inspecting our standard out since these messages are printed there.

Please feel free to reopen or start a new PR should CMake add a contractually machine readable way to get what is needed here.

(We aren't making a statement that in the future that that is the only issue; for example grepping in the source file of the portfile in the first place is a bit concerning.)

[BillyONeal]

https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html#codemodel-version-2-backtrace-graph

Possible machine readable way to get to the SHA location...

[autoantwort]

My goal now would be to directly put the downloads directives in the vcpkg.json or a new file next to it.