Building something in Manifest mode

[johne53]

This morning I was reading a web page here about building a package in Manifest mode:-

https://learn.microsoft.com/en-gb/vcpkg/concepts/manifest-mode

From what I can tell, this allows me to build an earlier version of a port so I've been experimenting with glibmm and following the instructions for building in Manifest mode, which (initially) gave me this message:-

PS D:\vcpkg-stuff\gnu-windows\src\vcpkg\ports\glibmm> ../../vcpkg install
Detecting compiler hash for triplet x64-windows...
Compiler found: G:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe
The following packages will be built and installed:

• dirent:x64-windows@1.26
  gettext[core,tools]:x64-windows@0.22.5#4
• gettext-libintl:x64-windows@0.22.5#4
  glib:x64-windows@2.86.4
  libffi:x64-windows@3.5.2
  libiconv:x64-windows@1.18#3
  libsigcpp:x64-windows@3.6.0#2
  pcre:x64-windows@8.45#7
• pcre2[core,jit,platform-default-features]:x64-windows@10.47
• vcpkg-cmake:x64-windows@2024-04-23
• vcpkg-cmake-config:x64-windows@2024-05-23
• vcpkg-cmake-get-vars:x64-windows@2025-05-29
• vcpkg-make:x64-windows@2026-01-01
  vcpkg-tool-meson:x64-windows@1.9.0#3
  zlib:x64-windows@1.3.1

But although vcpkg did build all those packages, it didn't actually build glibmm (even though it told me it had finished successfully). Have I misunderstood something?

[johne53]

Something occurred to me overnight... when in Manifest mode, does it only update libraries which already exist? The list of libraries above would've already been installed by vcpkg but glibmm wasn't installed yet.

[johne53]

when in Manifest mode, does it only update libraries which already exist?

No, that doesn't seem to be the case either. Yesterday I'd asked the Manifest mode to install glibmm ver 2.74.0 (when glibmm wasn't already installed) and it didn't build glibmm at all. So today I went back to Classic mode and asked it to install the current version (2.80.1). Strangely enough the built DLLs were called glibmm-2.68-1.dll - although interrogating the DLLs in Windows reports that they're as expected at ver 2.80.1.

I then went back to Manifest mode and asked it to install glibmm ver 2.76.0. It uninstalled all the above packages and then re-installed the exact same packages! But the previous glibmm DLLs remained (i.e. glibmm itself didn't get built again) .

I guess I could be doing something wrong but all the other packages got built so I'm not sure why glibmm doesn't. Is Manifest mode still a work-in-progress? Or have I just been unfortunate and picked a package that doesn't work properly?

[johne53]

Should I be reporting this as an issue, rather than a discussion?

[Osyotr]

PS D:\vcpkg-stuff\gnu-windows\src\vcpkg\ports\glibmm> ../../vcpkg install

You are running vcpkg in the port dir. This will build only dependencies listed in that vcpkg.json.
You need to add glibmm to your manifest.

[johne53]

Thanks @Osyotr but is one of us misunderstanding something? I read the info from that link I pointed to (in my original post here) and it looked to me like I needed to navigate to the folder containing glibmm's vcpkg.json file:- i.e. D:\vcpkg-stuff\gnu-windows\src\vcpkg\ports\glibmm and then run vcpkg install but without any command line arguments.

Surely glibmm's vcpkg.json file already know sit needs to build glibmm (unless I'm misunderstanding??)

[Osyotr]

Surely glibmm's vcpkg.json file already know sit needs to build glibmm (unless I'm misunderstanding??)

No, it doesn't know that. It knows that it needs to build it's dependencies.
The thing that knows that glibmm needs to be built is your manifest.
https://learn.microsoft.com/en-gb/vcpkg/concepts/manifest-mode#manifest-files-in-projects

[johne53]

Okay I'll try that at the weekend if I get some time but let me check something....

If glibmm's vcpkg.json file looks like this:-

{
  "name": "glibmm",
  "version": "2.80.1",
  "port-version": 1,
  "description": "This is glibmm, a C++ API for parts of glib that are useful for C++.",
  "homepage": "https://www.gtkmm.org.",
  "license": "LGPL-2.1-or-later",
  "supports": "!uwp & !xbox",
  "dependencies": [
    "gettext",
    "glib",
    "libffi",
    "libiconv",
    "libsigcpp",
    "pcre",
    {
      "name": "vcpkg-tool-meson",
      "host": true
    },
    "zlib"
  ]
}

and in my version I change it to look like this:-

{
  "name": "glibmm",
  "version": "2.76.0" "<--- I've changed this line"
  "port-version": 1,
  "description": "This is glibmm, a C++ API for parts of glib that are useful for C++.",
  "homepage": "https://www.gtkmm.org.",
  "license": "LGPL-2.1-or-later",
  "supports": "!uwp & !xbox",
  "dependencies": [
    "glibmm", "<--- and I've also added this line"
    "gettext",
    "glib",
    "libffi",
    "libiconv",
    "libsigcpp",
    "pcre",
    {
      "name": "vcpkg-tool-meson",
      "host": true
    },
    "zlib"
  ]
}

am I right in assuming that should work now? (up to now I've been under the impression that vcpkg.json IS the manifest file!)

[Osyotr]

up to now I've been under the impression that vcpkg.json IS the manifest file

vcpkg.json is the manifest file. But there are two kinds of manifests: port manifests and project manifests.

am I right in assuming that should work now?

Anything other than "dependencies" and "features" is ignored in project manifest, so your changes don't do anything.
If your goal is to use older version of glibmm, then you should be reading this instead: https://learn.microsoft.com/en-gb/vcpkg/consume/lock-package-versions

[johne53]

That's great - I'll give that a try at the weekend. Just one more question...

That article says I need to create various files in an empty folder which I assume should be a subfolder of some other folder. But which should be the parent folder?

[johne53]

Sadly that tutorial doesn't work :-(

I followed those instruction down to the point where I needed to run this command from a command line:-

cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=%VCPKG_ROOT%/scripts/buildsystems/vcpkg.cmake

And Cmake gave me the following error:-

CMake Error at D:/vcpkg-stuff/gnu-windows/src/vcpkg/downloads/tools/cmake-3.31.10-windows/cmake-3.31.10-windows-x86_64/share/cmake-3.31/Modules/CMakeDetermineSystem.cmake:152 (message):
  Could not find toolchain file: %VCPKG_ROOT%/scripts/buildsystems/vcpkg

%VCPKG_ROOT%/scripts/buildsystems doesn't contain a subfolder called vcpkg but it does contain a file called vcpkg.cmake

So I tried creating the relevant subfolder and copying vcpkg.cmake into it but it gives me exactly the same error :-(

Do I maybe need to build a CMake toolchain using vcpkg?

[johne53]

Apologies - in the page that @Osyotr pointed to I'd missed a line saying that before running cmake -B build -S etc I'd need to change %VCPKG_ROOT% and enter the actual path on my system (which for my system is D:\vcpkg-stuff\gnu-windows\src\vcpkg)

So I've now corrected that, tried the cmake -B build -S etc stuff again and I'm not seeing the error now!

[Edit...] And woohoo! I've actually got a bit further now! It's building all the dependencies okay but when it come to building glibmm ver 2.76.0 it gives me this error:-

Downloading https://ftp.gnome.org/pub/GNOME/sources/glibmm/2.76/glibmm-2.76.0.tar.xz -> glibmm-2.76.0.tar.xz
glibmm-2.76.0.tar.xz.11124.part: error: download from https://ftp.gnome.org/pub/GNOME/sources/glibmm/2.76/glibmm-2.76.0.tar.xz had an unexpected hash
note: Expected: 6f9ee91212077f3712a5ba99507479b5c99d021670e6bf298afc7239fafed8a40b3b17bfae96d9a7fa7fb199c3994b81b433c8275afe89839229a1fe20ba791e
note: Actual  : be49599f5eb8eb5a1cef015cdb37af2564fcd1ea845aa4344804ca5f0f61468949711e25cefebb93219e1be37128ebfdd2a816324e752ac4395b4b87c072fc78

@Osyotr - please let me know if you've any ideas.

[Edit2...] Following the example in your link, my vcpkg.json file is quite simple and looks like this:-

{
  "dependencies": [ "gettext", "glib", "libffi", "libiconv", "libsigcpp", "pcre", "zlib", "glibmm" ]
}

Should I have maybe specified a homepage ?

[johne53]

Oops, I'd totally forgotten about bootstrap.bat :-(

BTW at the moment I don't have any goal in mind. I'm just experimenting to find out what's possible and what isn't, so I'll give all that some thought and experiment again tomorrow.

[Edit...] Oh, one more thing... if pangomm also needed to build an earlier version, is it possible to have 2 x builtin_baseline statements or does that complicate things?

[Osyotr]

There can be only one builtin baseline. You can have multiple registries pointing to the same repo but with different baselines for different ports.
https://learn.microsoft.com/en-gb/vcpkg/consume/boost-versions#2---use-a-baseline-to-override-boost-packages

[johne53]

Groan... sorry to ask yet another question.

I followed that last link you gave and about halfway down the page it gives an example of how to obtain the various baselines for boost. I'm building glibmm here so I assumed I'd need to modify the given command to this:

git log "--format=%H %cd %s" --date=short --left-only -- versions/g-/glibmm.json

but when I issue that command (in Powershell) it gives me this response:-

WARNING: terminal is not fully functional
Press RETURN to continue

Have I mis-typed something? I issued the command from vcpkg's root directory.

Edit...] FWIW I've Just tried from a normal Windows Command Prompt and that gives me the same response . So I simply typed git here (which lists the available options) and it looks like there isn't an option called format :-(

[johne53]

@Osyotr - I'm so sorry to keep taking up your time but if you're able to print out glibmm's baselines at your end, would you mind posting them here so I can at least see them?

[johne53]

Another bit of info which might be helpful is that if I modify that command slightly to this:-

git log "--format=%H %cd %s" --date=short --left-only -- ../versions/g-/glibmm.json

and I then navigate to vcpkg's .git folder and run it from there, I then see a different message:-

fatal: ../versions/g-/glibmm.json: '../versions/g-/glibmm.json' is outside repository at 'D:/vcpkg-stuff/gnu-windows/src/vcpkg/.git/.'

So maybe I'm just running it from the wrong folder?

[johne53]

I managed to find a tutorial that suggests an alternative way to obtain hashes (baselines ?) for the various ports but that doesn't work either:-

https://learn.microsoft.com/en-us/vcpkg/commands/hash

It relies on the user being able to find an archive file for the port whose name ends in .bz2 but it doesn't say how or where they can be obtained.

What's needed here is some kind of tool within vcpkg (maybe even just a batch file) which could print out this information simply and reliably. Is there anywhere where I could suggest that as a feature request?

[johne53]

Hi @Osyotr - I've discovered something this morning which might be significant:-

I followed that last link you gave and about halfway down the page it gives an example of how to obtain the various baselines for boost. I'm building glibmm here so I assumed I'd need to modify the given command to this:

git log "--format=%H %cd %s" --date=short --left-only -- versions/g-/glibmm.json

but when I issue that command (in Powershell) it gives me this response:-

WARNING: terminal is not fully functional
Press RETURN to continue

I've realised that if I change that command to this:-

git -P log -- versions/g-/glibmm.json

It does actually show me the contents of versions/g-/glibmm.json (but unfiltered of course). So I'd guess that either there's something wrong with those formatting options (in the original example) or maybe the layout of those .json files has changed since that article was originally written?

[Osyotr]

Probably an error in docs.
That command doesn't throw errors but doesn't print anything either. Dropping --left-only part seems to work.

git log "--format=%H %cd %s" --date=short --versions/g-/glibmm.json

I don't really run git locally to find the commit that I need to use as a baseline.
I open https://github.com/microsoft/vcpkg/commits/master/ports/glibmm and look for the latest commit that has the version I need. Then I use it as a value for the baseline for a registry that contains only this port (or a set of ports). Exactly as you did in another thread:

{
  "default-registry": {
    "kind": "git",
    "repository": "https://github.com/Microsoft/vcpkg",
    "baseline": "4b77da7fed37817f124936239197833469f1b9a8"
  },
  "registries": [
    {
      "kind": "git",
      "repository": "https://github.com/Microsoft/vcpkg",
      "baseline": "934a99dc13cabb330824ae1a5ab4a53a9acc5a49",
      "packages": [ "glibmm*", "giomm*" ]
    }
  ]
}

The vcpkg.json then should not contain builtin-baseline or any overrides as it's covered by vcpkg-configuration.json.

[johne53]

Thanks @Osyotr and you're exactly right - removing --left-only seems to work!

What's been confusing me here (probably something I've misunderstood) is the reference to "4b77da7fed37817f124936239197833469f1b9a8". Up to now I'd assumed that it was the builtin-baseline corresponding to glibmm but I'm starting to think I've been wrong in assuming that??

If I examine the various numbers in glibmm.json, the most recent value shows up as:- "35696bca8e0a38820678c1571a7bdfca61ef2a2a"

Hope that all makes sense...

[Osyotr]

4b77da7fed37817f124936239197833469f1b9a8 is literally a commit in this vcpkg repo (aka the public/official/curated registry) 4b77da7.
If you browse the repo at that point in time, you will find glibmm 2.80.1#1 https://github.com/microsoft/vcpkg/blob/4b77da7fed37817f124936239197833469f1b9a8/ports/glibmm/vcpkg.json
Therefore, if you use this commit as a baseline for a registry that has "packages": [ "glibmm*", "giomm*" ], you will have glibmm 2.80.1#1 installed (provided you didn't set any additional overrides in vcpkg.json).

[johne53]

I open https://github.com/microsoft/vcpkg/commits/master/ports/glibmm and look for the latest commit that has the version I need

Thanks @Osyotr and this raises something else that's been confusing me... if I display the available versions for glib I see this output (sorry for the length of this):-

Glib Available versions:
2.86.4
2.86.3
2.86.2#1
2.86.2
2.84.2#2
2.84.2#1
2.84.2
2.84.1
2.83.4
2.80.0#1
2.80.0
2.78.4#4
2.78.4#3
2.78.4#2
2.78.4#1
2.78.4
2.78.1
2.78.0
2.76.5
2.76.3#3
2.76.3#2
2.76.3#1
2.76.3
2.76.2
2.76.1#1
2.76.1
2.76.0#1
2.76.0
2.75.3
2.75.1
2.75.0
2.74.1
2.74.0
2.72.3#3
2.72.3#2
2.72.3#1
2.72.3
2.70.5#2
2.70.5#1
2.70.5
2.70.1#2
2.70.1#1
2.70.1
2.66.4#2
2.66.4#1
2.66.4
2.52.3#27
2.52.3#26
2.52.3#25
2.52.3#24
2.52.3#23
2.52.3-14-7
2.52.3-14-6
2.52.3-14-5
2.52.3-14-4
2.52.3-14-3
2.52.3-14-2
2.52.3-14-1
2.52.3-13-1
2.52.3-13
2.52.3-11
2.52.3-9
2.52.3-2
2.52.3-1
2.52.3
2.52.2
2.52.1
2.50.3

and sure enough if I visit the relevant page for glib it lists all the commits as far back as 2.50.3. But if I do the same thing for glibmm the entry list looks like this:-

Glibmm Available versions:
2.80.1#1
2.80.1
2.78.1
2.76.0#1
2.76.0
2.74.0
2.70.0#1
2.70.0
2.68.1#2
2.68.1#1
2.68.1
2.68.0
2.52.1#14
2.52.1#13
2.52.1#12
2.52.1-11
2.52.1-10
2.52.1-9
2.52.1-8
2.52.1-7
2.52.1

And yet when I visit the relevant page for glibmm it only shows me the commits as far as 2.74.0 (or are you seeing the full list at your end?)

[dg0yt]

PS D:\vcpkg-stuff\gnu-windows\src\vcpkg\ports\glibmm> ../../vcpkg install

This is not how to install glibmm in manifest mode. Manifest mode is for user projects, not for ports. In manifest mode, the top-level vcpkg.json (user project!) defines which dependencies to install, but it doesn't build the user project.

So author a vcpkg.json in your project, listing glibmm if this is a dependency, and then invoke the manifest-mode installation via command line or (cmake, msbuild) project integration.

[johne53]

Thanks @dg0yt, that's how I ended up doing it. And I built glib as a test (along with the various libraries it depends on). But I then decided to try building an unrelated port called boost - at which point the build told me it would delete all the glib stuff I'd already built. See my post #2 here:-

#50577

So AFAICT the only way to build unrelated ports is to treat them as if they're dependencies of some other port (i.e. to put everything into 1 x manifest). Or did I misunderstand something?

[dg0yt]

Works as intented.

The top-level project manifest lists direct dependencies, and optionally some transitive dependencies (for feature control). Everything which is not (or no longer) in the dependency tree ("unrelated port") is meant to be removed by vcpkg install.

Port directories are not working directories for end users. The manifests in port directories are not expected to be used as top-level install specifications. (There is at least one property which is treated different for top-level manifests.)