pass VERSION to cmake when building port

[autoantwort]

This is a frequently requested feature. With this one can use the ${PORT_VERSION} variable inside portfile.cmake to get the currents port version.

[vicroms]

What's the purpose of having port version available in portfile.cmake? It should be irrelevant in all internal port logic.

[Neumann-A]

It should be irrelevant in all internal port logic.

Maybe you should grep through all portfile.cmake files for the string VERSION

[autoantwort]

For example https://github.com/microsoft/vcpkg/blob/86cab7438f79f6b0f60fc83f421993534ad333ee/ports/libbson/portfile.cmake#L22-L24

or things like
https://github.com/microsoft/vcpkg/blob/master/ports/webview2/portfile.cmake#L5-L18

There are hundreds of other examples where the port version is repeated in the portfile.cmake

[BillyONeal]

It should be irrelevant in all internal port logic.

Maybe you should grep through all portfile.cmake files for the string VERSION

Generally speaking, someone asking to make a change needs to motivate making the change, not expect readers to do archeology to figure it out. The original statement says "frequently requested feature" without enumerating any such request, and neither I (nor apparently Victor) have seen such a request before.

For example https://github.com/microsoft/vcpkg/blob/86cab7438f79f6b0f60fc83f421993534ad333ee/ports/libbson/portfile.cmake#L22-L24

Hmm, this is extracting "version", not "port version"? Oh...

There are hundreds of other examples where the port version is repeated in the portfile.cmake

I'm not sure I agree with attempting to replace all such occurrences with an injected variable though; in fact I see people frequently do things like

• make a variable named version
• form a URI expanding that variable

or similar which I'm not personally a big fan of. It makes it easier to miss SHA updates, and can produce URIs that aren't what upstream is looking for for whatever their new version is. But this is a personal opinion, not a team policy, so I've not made CR comments about it either way.

For a 'should we do this' statement, I'm neutral. It is indeed something that people are doing, but they're often doing so in service of a pattern of which I'm not a huge fan.

As for the detail of this particular implementation:

• There should be e2e tests added for version, version-string, version-date, and version-semver that make use of this. I'm 99% sure the change is correct but I would be a lot happier with tests that prove it.
• I think we need to bikeshed the name a bit because port version already has another meaning. How about one of these:
  • VCPKG_BUILDING_VERSION
  • VERSION (note that we already have PORT so there's precedent for no prefix)
  • VCPKG_JSON_VERSION (somewhat of a misnomer if the port uses a CONTROL file but close enough for me)
  • VCPKG_JSON_VERSION / VCPKG_JSON_VERSION_DATE / VCPKG_JSON_VERSION_SEMVER / VCPKG_JSON_VERSION_STRING (Included for completeness 😄 )
• We should make sure that we have intentional answers as to whether this variable means anything to vcpkg create (or other things that call ports.cmake).

[Neumann-A]

archaeology: microsoft/vcpkg#17908
This has been requested before vcpkg.json was around ..... today we could simply implement a script function via string(JSON) to read the version string.
In general it is to avoid version mismatches between manifest and portfile.

it easier to miss SHA updates,

move SHA into manifest? (I would like that since portfile changes are for simple ports often not necessary.)

[Osyotr]

move SHA into manifest

I wonder if it's possible to fetch file hash from github. That would make simple ports even more simple!

[BillyONeal]

move SHA into manifest? (I would like that since portfile changes are for simple ports often not necessary.)

We certainly would like to move vcpkg_from_Xxx things into some form of declaration in the manifest instead so that we can offer better download batching and features like

I wonder if it's possible to fetch file hash from github. That would make simple ports even more simple!

... but that hasn't made it above the cut line yet :(

[dg0yt]

I wonder if it's possible to fetch file hash from github. That would make simple ports even more simple!

This only makes sense for the maintainer who does the port update. The user must be able to operate in disconnected mode, with pre-fetched asset.

[autoantwort]

move SHA into manifest? (I would like that since portfile changes are for simple ports often not necessary.)

We certainly would like to move vcpkg_from_Xxx things into some form of declaration in the manifest instead so that we can offer better download batching and features like

I wonder if it's possible to fetch file hash from github. That would make simple ports even more simple!

... but that hasn't made it above the cut line yet :(

What about microsoft/vcpkg#24199 (comment)? I would implement it, but feedback would be nice.

[Neumann-A]

I would implement it, but feedback would be nice.

I would rather like to see the options rfc being implemented ;) But be aware that downloads can also carry patch dependencies i.e. a download of a patch can be used by another download

[vicroms]

@ras0219 @dan-shaw @JavierMatosD @BillyONeal @valeriaconde @vicroms

The team has voted and we prefer this be renamed to just VERSION.

We think this won't cause issues with any ports that use VERSION as a variable since they will be resetting it already.

[BillyONeal]

What about microsoft/vcpkg#24199 (comment)? I would implement it, but feedback would be nice.

I'm not convinced the ask there is possible. We already have scripts that try to update stuff that get run occasionally (to my understanding), but most of the cleanup steps enumerated there aren't automated because we aren't sure how to do that. Making things more declarative would of course make that easier.

[BillyONeal]

• There should be e2e tests added for version, version-string, version-date, and version-semver that make use of this. I'm 99% sure the change is correct but I would be a lot happier with tests that prove it.

Done.

• I think we need to bikeshed the name a bit because port version already has another meaning.

Done.

• We should make sure that we have intentional answers as to whether this variable means anything to vcpkg create (or other things that call ports.cmake).

The other thing ports.cmake does is "create" and I think leaving version unset there is fine.

LGTM