Skip to content

Conversation

@jlskuz
Copy link
Contributor

@jlskuz jlskuz commented Dec 20, 2025

Regarding CI this is an initial draft that rebuilds all dependencies all the time. For use in production caching should be added. There are two options for caching (see microsoft/vcpkg-tool#1662):

  1. Use GitHub Packages with NuGet, this method uses vcpkg's caching mechanism and preserves caching granularity per port. This is the method recommended by the vcpkg team.
  2. Use actions/cache in your workflow to cache the installed directory, this is not integrated with vcpkg but is the method endorsed by the GitHub Actions team. The downside of this method is that the whole installed tree gets cached as a single artifact, so single port updates invalidate all packages.

I tested both approaches in my fork successfully. Given that the NuGet approach is recommended, I tend to use it. However I as soon as I add code for it, it will flood the registry of the mltframework GitHub organization with packages, hence I want to hear your feedback beforehand. Any objections?

While vcpkg supports Linux, our main focus is on Windows (MSVC) for now. In this first step a minimal set of dependencies is added to be able to do a build of the framework with most modules disabled.
This makes it easier to run CMake with a fixed set of many options. It is also a preperations step for a vcpkg based CI job.
This is an inital draft that rebuilds all dependencies all the time. For use in production caching should be added (either via GitHub Action Cache or via GitHub Packages).
@jlskuz jlskuz requested a review from ddennedy December 20, 2025 21:28
@ddennedy
Copy link
Member

Take it out of draft if you want me to review it.

@jlskuz
Copy link
Contributor Author

jlskuz commented Dec 21, 2025

I don't need a full review yet, but like to get a "go" on using the approach that involves the package registry as it will be painful to clear/revert ones I started to use it.

@jlskuz jlskuz marked this pull request as ready for review December 21, 2025 12:06
@jlskuz
Copy link
Contributor Author

jlskuz commented Dec 21, 2025

I took it out of draft anyways now. I think 8 minutes build time without caching is acceptable as a stop gap solution and can be merged. Caching will become more important as soon as we enable heavier deps like Qt and FFmpeg.

{
"default-registry": {
"kind": "git",
"baseline": "cfcbdb245f1179a5a493890a0b69531d66969e62",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this commit ID get updated? Can it be a tag instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One has to update that manually once in a while.

As far as I can tell from the documentation and open feature requests (like this or this) only a long commit hash, but no tags are supported.

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.

3 participants