Skip to content

Conversation

@bretbrownjr
Copy link
Member

  • Add a vcpkg.json configuration to enumerate a GoogleTest logical dependency in vcpkg.json
  • Add a vcpkg-configuration.json to select a known-good release of vcpkg dependencies for consistent reproduction of builds. This is effectively a lockfile in the form of a vcpkg commit SHA.

This will provide consistent, cross-platform development workflows when using vcpkg for managing dependencies (i.e., GoogleTest). This is an intermediate step towards bemanproject/infra#135, but this change does not fully package this project for vcpkg. That would require authoring a "portfile", either in this repo or (my preference) in the upstream vcpkg repo.

I'm going to leave this as a Draft until the following is true of this PR:

  • Wire up the newly supported workflow to CI. CI should fail if vcpkg JSON files are missing, empty, or otherwise not meeting requirements. This could provide a consistent vcpkg-based CI on all supported OSs if that's attractive.

  • Add documentation demonstrating the support for building against vcpkg dependencies.

@wusatosi
Copy link
Member

wusatosi commented Mar 6, 2025

This would overwrite bemanproject/infra#7 . We should close that one when this PR opens.

I have tried to implement CI testing for vcpkg, I can take on the CI part once I have some time. I remember there was a roadblock, I need to investigate that.

@wusatosi wusatosi self-assigned this Mar 6, 2025
@a4z
Copy link

a4z commented Mar 13, 2025

I guess you want the registry here on the project?

So you can have a project with a vcpkg-configuration.json in your that adds the bemanproject port

dummy example:

{
  "default-registry": {
    "kind": "builtin",
    "baseline": "5e5d0e1cd7785623065e77eff011afdeec1a3574"
  },
  "registries": [
    {
      "kind": "git",
      "baseline": "e9273e2613b55f3fef3d0cf57a4e98d60aa72b02",
      "repository": "https://github.com/bemanproject/vcpkg-ports",
      "packages": [ "task", "net", "execution" ]
    }
  ]
}

and adding / using packages just works.

This way, the Bemanproject can have 100% control over its packages without waiting for merges of vcpkg official.

And adding / updating something to the ports could be done in CI, when packages get a tag
This would also allow to have an archive of published libraries, so builds will not be broken over night , and once remove, people can easily move that to their own registry (or there will be an archive port)

@bretbrownjr bretbrownjr mentioned this pull request Mar 13, 2025
2 tasks
@bretbrownjr
Copy link
Member Author

Nice suggestion! I linked the suggestion from bemanproject/infra#135, which is tracking the work to fully package this repo for vcpkg (PRs welcome!).

I would like the scope for this PR to be actually pretty limited. I want a user to be able to build this project from the vcpkg registry. I think this is basically all we need, other than the CI enhancements that @wusatosi mentioned.

@wusatosi
Copy link
Member

@bretbrownjr can I commit directly on the PR for CI related changes?

@bretbrownjr
Copy link
Member Author

That's fine with me, yes.

@JeffGarland
Copy link
Member

Should we close given that @wusatosi is going to handle on a different PR?

@bretbrownjr
Copy link
Member Author

It could land separately. It's technically a different feature to get gtest from vcpkg compared to listing exemplar as available through vcpkg.

This PR is feature complete for what it aims to do. The main missing feature is a CI enhancement to ensure the feature continues to be supported. And, of course, any documentation enhancements that might be in order. Reviews on that point specifically are appreciated right away.

@bretbrownjr
Copy link
Member Author

@wusatosi is there any CI change we could move to this PR to unblock it?

@wusatosi
Copy link
Member

@wusatosi is there any CI change we could move to this PR to unblock it?

A setup would work.
I unfortunately am having covid, so I won't be able to work on this for about a week.

@bretbrownjr
Copy link
Member Author

@wusatosi I lost track of this one. It looks like GitHub Actions are happy. Should we rebase and merge?

@wusatosi
Copy link
Member

It looks like GitHub Actions are happy. Should we rebase and merge?

We have not added CI infrastructure to test for vcpkg :|

* Add a `vcpkg.json` configuration to enumerate a GoogleTest
  logical dependency in `vcpkg.json`
* Add a `vcpkg-configuration.json` to select a known-good release
  of vcpkg dependencies for consistent reproduction of builds.
  This is effectively a lockfile in the form of a vcpkg commit
  SHA.
@wusatosi
Copy link
Member

wusatosi commented Jun 1, 2025

Currently blocked by bemanproject/infra-containers#9

@camio
Copy link
Member

camio commented Oct 10, 2025

Closing out this PR since there hasn't been activity for 6 months. Feel free to reopen if there's interest in continuing it.

@camio camio closed this Oct 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants